image

Mozilla beschermt Firefox tegen aanvallen via about:pagina's

maandag 14 oktober 2019, 09:57 door Redactie, 14 reacties

Mozilla heeft extra maatregelen genomen om Firefox-gebruikers te beschermen tegen injectieaanvallen via de about-pagina's van de browser en andere manieren. Firefox beschikt over verschillende "ingebouwde" pagina's waarmee gebruikers allerlei zaken kunnen instellen of bekijken.

Het gaat dan bijvoorbeeld om pagina's als about:addons, about:config en about:downloads voor respectievelijk het beheer van add-ons, het aanpassen van de browserconfiguratie en het weergeven van alle downloads. Deze about:pagina's zijn ook via html en JavaScript geïmplementeerd en zijn onderhevig aan hetzelfde beveiligingsmodel als normale webpagina's en daardoor niet immuun voor aanvallen waarbij er code in de browser wordt geïnjecteerd.

Als een aanvaller erin zou slagen om code op een about:pagina te injecteren zou de code binnen de beveiligingscontext van de browser worden uitgevoerd, waardoor de aanvaller willekeurige acties in naam van de gebruiker kan uitvoeren. Om gebruikers hier tegen te beschermen en een aanvullende beveiligingslaag aan Firefox toe te voegen heeft Mozilla voor alle 45 about:pagina's alle inline JavaScript-code naar losse bestanden verplaatst en alle inline event handlers herschreven. Een event handler is een routine die invoer verwerkt.

Door het herschrijven van de code kan er nu een Content Security Policy (CSP) worden toegepast waardoor geïnjecteerde JavaScriptcode niet wordt uitgevoerd. JavaScriptcode wordt nu alleen nog uitgevoerd uit een los bestand via een intern protocol. "Het niet toestaan van inline scripts in de about:pagina's verkleint het aanvalsoppervlak om willekeurige code uit te voeren en biedt daardoor een sterke eerste verdedigingslinie tegen injectieaanvallen", zegt Mozillas Christoph Kerschbaumer.

Verder heeft Mozilla maatregelen genomen om eval-achtige functies te verwijderen. Deze functie voert een willekeurige string uit in dezelfde beveiligingscontext als zichzelf. Hierdoor kan in runtime gegenereerde code of code in non-scriptlocaties worden uitgevoerd. Een nadeel is dat het volgens Mozilla ook een groot aanvalsoppervlak voor injectieaanvallen introduceert. Daarom raadt de browserontwikkelaar het gebruik ervan af. Zelf heeft Mozilla alle eval-achtige functies herschreven zodat de functie niet meer in system-privileged scriptcontexts worden uitgevoerd.

Reacties (14)
14-10-2019, 10:54 door Anoniem
Het blijft toch verbazen hoe ontzettend stuk en ronduit gevaarlijk het hele fenomeen "webbrowser" iedere keer weer blijkt te zijn. Ja, leuk dat mozilla nu wat aan dit ding doet. Maar ze hebben tegelijkertijd de mogelijkheid zelf geschapen. En dat zegt ook wat.
14-10-2019, 11:41 door Anoniem
Nu komt men met een CSP herschreven code in de browser,
goede actie van Mozilla bladeraar development.

Maar ....... hoeveel websites bestaan er niet zonder maar 1 enkele CSP implementatie?

Kijk maar eens op het kaartje hier https://www.immuniweb.com/websec/

De browser kan dan wel steeds veiliger worden, websites lopen nog heel wat achter,
waar het best security policy implementatie betreft.

Hier op de site, waarop ik deze posting schrijf, komen we ook niet verder dan een D-tje voor de header-security:
https://securityheaders.com/?q=security.nl&followRedirects=on

Ook de website van security.nl staat dus bloot aan bedreigingen (MiM aanvallen o.a.):
https://webscan.upguard.com/#/security.nl , waarvan akte.

Men kan zelf, als browser eindgebruiker, ook wel het een en ander doen,
o.a. door het (gedeeltelijk) blokkeren van JavaScript etc. via een extensie als uMatrix bijvoorbeeld.

Voor Mozilla was er vanouds Giorgio Maone's No Script.

Wel even kijken om een balans te vinden tussen de minimale toestemming
voor het goed functioneren van de website en het blokkeren van alle 3rd party scripts bijvoorbeeld.

Maar hiervoor is bij uMatrix echt geen "power user rocket science" nodig.

Overigens met JavaScript beveiliging blijft het een ongelijke strijd tussen beveiliger en aanvaller.
De beveiliger moet alles over de hele linie beveiligen,
de kwaadwillende hacker heeft vaak aan een enkel klein gaatje om doorheen te wurmen genoeg,
al is het na een honderste parameter, als dat niet uitgestest zou zijn.

Maar ja als beveiliger moet je we wat te doen houden, toch?
De schoorsteen moet roken bij ons en er moeten oliebollen op tafel komen.

luntrus
14-10-2019, 12:26 door MathFox - Bijgewerkt: 14-10-2019, 12:53
Door Anoniem: Het blijft toch verbazen hoe ontzettend stuk en ronduit gevaarlijk het hele fenomeen "webbrowser" iedere keer weer blijkt te zijn. Ja, leuk dat mozilla nu wat aan dit ding doet. Maar ze hebben tegelijkertijd de mogelijkheid zelf geschapen. En dat zegt ook wat.
De oorspronkelijke HTML was best veilig, totdat iemand bij Netscape JavaScript aan de browser toevoegde, waarmee het mogelijk werd om untrusted code op de computer van de bezoeker van een website uit te voeren. Daarna volgde een race met Flash, ActiveX en een hoop andere zut om browsen nog onveiliger te maken.
Ik geef Netscape de schuld.
14-10-2019, 13:35 door Anoniem
Willekeurige code op een random website als /js/all.js
Met sources als: inner.HTML, e.parent, name, sessinStorage, location.pathname, offset.top
en sinks als: href=, "data", var value, scr, leveren als kwetsbaarheid mogelijk DOM-XSS gevaar op,
een mogelijke aanvaller heeft aan een klein code-gaatje genoeg om zijn slag te slaan.

Veiligheid moet van twee kanten komen op de browser, maar ook op de webpagina/webserver,
daar schort nogal wat aan.

luntrus
14-10-2019, 13:51 door MathFox
Door Anoniem:
Veiligheid moet van twee kanten komen op de browser, maar ook op de webpagina/webserver,
daar schort nogal wat aan.
Waarom zou een webpaginabouwer zich zorgen maken over de privacy en veiligheid van zijn bezoekers? Advertentieinkomsten zijn veel belangrijker!
14-10-2019, 14:59 door Anoniem
@MathFox,

Dat heb je volgens mij toch vooral als ironische opmerking bedoeld.

Ik weet uit de wereld der opleidingen dat er te weinig aandacht voor is.
JavaScript dat doe je in het eerste jaar maar op eigen houtje.

Kregen die tweede jaars ook nog eens op de HBO een jaar security les uit het verkeerde txt-boek.
Ik stond erbij als proctor en ik keek ernaar.
Trouwens, het wordt je ook niet in dank afgenomen, als je er iets van zegt.

Dat de schoornsteen voor hen, de staarten met een apple, moet blijven branden
en ze weinig tijd krijgen voor het nalopen van de veiligheid op hun ontwerpen is bekend.
Mwah, gecompileerde code heeft natuurlijk de voorkeur boven de alternatieven.

Ook dat de eigenaars van de websites, die overigens nergens verstand van hoeven te hebben,
veiligheid als een "last resort issue" beschouwen en er liever geen geld aan spenderen,
is ook bekend. Dus liever een gelikte site dan een veilige.

Daarom zo weinig best practices, zo weinig geimplementeerde header security, geen DNSSEC, etc. etc.

Mozilla en Chrome developers kunnen doen wat ze willen,
aan de andere kant, die van de website developers, moet men ook eens het licht gaan zien.

Niet te snel overigens en niet al te grondig graag, want jij, MathFox en ondergetekende,
houden ook graag wat te doen over. Maar daar zit ik niet zo over in.

luntrus
14-10-2019, 15:55 door MathFox
Sarcasme luntrus, sarcasme.

Ik zie teveel onveilige praktijken bij de bouwers van websites... Wat te denken van (Javascript) bibliotheken die zonder controle van andere websites gehaald worden. Perfecte aanvalsbron om creditcard gegevens mee te stelen!
Ik ben blij dat webbrowsers een sandbox hebben en dat Debian de webbrowser weer in AppArmor draait.

Met websitebouwers ben ik de ironie ver voorbij.
14-10-2019, 16:32 door Anoniem
@ MathFox,

Goed, dan zitten we denk ik helemaal op dezelfde golflengte. ;)
Wat je noemt, het veredelde knip- en plakwerk, hetwelk een groot risico voor ieders veiligheid kan inhouden.

Denk ook eens in dit verband aan "verlaten" code en wat je daarmee voor risico's kan lopen.
Plus ga.js van google-analytics zonder toegevoegde security op de website.
Heb je daar bijvoorbeeld een werkende exploit, dan ben je gelijk criminele spekkoper, hoor.

Dan moet het ook nog eens een keer allemaal over een veilige webserver,
dus eentje zonder Poodle over TLS, zonder Goldendoodle, zonder Zombie Poodle, zonder Sleeping Poodle,
zonder Open SSLL padding Oracle flaw, zonder ROBOT, zonder Heartbleed, zonder Open SSL CSS flaw
om maar eens wat op te noemen.

luntrus
14-10-2019, 17:27 door Anoniem
Door MathFox: De oorspronkelijke HTML was best veilig, totdat iemand bij Netscape JavaScript aan de browser toevoegde,

Die persoon bij Netscape Corp. heette Brendan Eich.

https://en.wikipedia.org/wiki/Brendan_Eich
14-10-2019, 18:51 door Anoniem
Brendan Eich ontwierp JavaScript in slechts 10 dagen.
Hij stond tevens, veel later weer, ook nog aan de wieg van de Brave browser.

We kunnen de fiasco's rond JavaScript hem niet persoonlijk aanrekenen,
dat men toch vaak nalaat de code zeer nauwgezet op allerhande zwakheden door te spitten.
JavaScript was aanvankelijk nog niet klaar voor het gebruik naast HTML.
Dat heeft Eich ook ruiterlijk toegegeven. Of dat ooit nog goedkomt?

Er kan wel wat gedaan worden, doorspitten, scannen, linten, fuzzen.
Wie hebben er hier allemaal Retire.JS draaien in de browser?
Wie scannen er online met de scanner van de Noor, Erlend Oftedal, op af te voeren JQuery bibliotheken:
@ retire.insecurity.today/# ? Ook SNYK geeft JQuery library zwakheden aan.

Met JavaScript kan veel, maar je kunt er ook een spreekwoordelijke "wormendoos" mee openen.
Waar hele draden over zijn gevuld bij Stack Overflow.

Lees dit artikel maar eens:
https://www.zdnet.com/article/an-insecure-mess-how-flawed-javascript-is-turning-web-into-a-hackers-playground/

Toen men meer dan 133.000 websites had onderzocht,
bleek dat er op 37 percent daarvan tenminste zich 1 JavaScript bibliotheek bevond
met tenminste een bekende kwetsbaarheid.

luntrus
14-10-2019, 20:25 door Anoniem
Door MathFox: Ik zie teveel onveilige praktijken bij de bouwers van websites... Wat te denken van (Javascript) bibliotheken die zonder controle van andere websites gehaald worden.

user@host:~$ firejail --private firefox &

Met de --private optie wordt door de firejail sandbox een namaak "/root", en een lege huls als schijnbare "/home/user" directory, in een restrictief en tijdelijk tmpfs filesysteem aangemaakt. Dit werkt onder vrijwel alle Linux systemen.

Met JavaScript gefabriceerde payloads kunnen binnen zo'n firejail weinig uitrichten. Zodra de sandbox wordt afgesloten wordt het tmpfs, met alle eventuele wijzigingen en vreemde download bestanden daarin, weggegooid.

Ik ben blij dat webbrowsers een sandbox hebben en dat Debian de webbrowser weer in AppArmor draait.

Weet je dat zeker? Vreemd, want toen ik Debian 10 (stable) onlangs nog installeerde, moest ik eigenhandig een alsnog extra te installeren Firefox AppArmor profiel handmatig aanpassen in en enforce modus zetten. Dat kan aan mij liggen.
14-10-2019, 22:21 door Anoniem
18:51 door luntrus: Toen men meer dan 133.000 websites had onderzocht,
bleek dat er op 37 percent daarvan tenminste zich 1 JavaScript bibliotheek bevond
met tenminste een bekende kwetsbaarheid.

"Functionality first, security comes later."

Dat was met auto's en oliebollen ook al zo.
Duurde jaaaren en jaaaaren....
15-10-2019, 11:36 door Anoniem
Ik vermoed dat de nauwere samenwerking van Mozilla Foundation met de ontwikkelaars van Tor Browser hier achter steekt, want hiermee gaat een grote wens van die laatsten mee in vervulling. Als deze Content Security Policy voor de JavaScript functies onder de standaard Firefox about-pagina's goed wordt geimplementeerd dan wordt de namelijk veiligheid van beide typen browsers hiermee in één klap enorm mee verbeterd.
16-10-2019, 23:09 door Anoniem
Bedankt, dat je dit voor ons inzichtelijk hebt gemaakt, beste anoniem van 11:36.
CSP policy voorgesteld als added security door het Tor-browser development team binnen Mozilla.
Lijkt me een zeer aannemelijk scenario. Ik geloof je.

Er kan echter best nog wel een schepje bovenop.
Er blijft nog veel te doen tegen alle reguliere ondergravers van security "om den brode".
En diegenen, die het begrijpen, hebben vaak aan een half woord genoeg ;).

luntrus
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.