Mozilla verspreidt patch voor exploit in pdf-viewer Firefox

Een kwetsbaarheid in Firefox's pdf-viewer zorgde voor een kritiek beveiligingslek in Mozilla's webbrowser. Het lek werd misbruikt via een advertentie op een Russische site. Het stuurde gevoelige informatie naar een server in Oekraïne. Mozilla heeft inmiddels een patch uitgebracht.

De kwetsbaarheid werd op vijf augustus opgemerkt, waarna Mozilla donderdag een beveiligingsupdate de deur uit deed. Voor de meeste gebruikers zal deze update automatisch zijn geïnstalleerd en prijkt het versienummer 39.0.3 nu op het 'Over Firefox'-schermpje. Ook de extended support release 38 heeft de update gekregen en telt nu 38.1.1.

De zero-day-kwetsbaarheid bestond uit het versturen van gevoelige informatie op de computer van de gebruiker naar een externe server in Oekraïne. Dit klinkt vrij logisch, maar de aanval was heel specifiek gericht op bestanden die veel door ontwikkelaars gebruikt worden. Dat laatste verbaasde Mozilla, omdat de site waar de exploit misbruikt werd, op het algemeen publiek gericht was. Het is niet bekend of de exploit ook op andere sites gebruikt is.

De exploit zocht op Windows specifiek naar subversion-, s3browser- en Filezilla-configuratiebestanden, .purple- en Psi+-accountinformatie en configuratiefiles van acht andere populaire ftp-clients. Op Linux zocht de exploit naar configuratiefiles als /etc/passwd en daarna in alle directory's of files van gebruikers die het kon binnenkomen, zoals .bash_history, .mysql_history, .pgsql_history, .ssh-configuratiebestanden en sleutels, configuratiebestanden voor remmina, Filezilla en Psi+ en verschillende tekstbestanden met 'pass' en 'access' in de naam. Mac-gebruikers waren geen doel bij de aanval, maar zouden niet immuun geweest zijn als iemand een andere payload had meegegeven met de exploit.

Laatste belangrijke eigenschap van de exploit is dat hij geen sporen achterlaat op de lokale machine. Gebruikers van Firefox op Windows of Linux krijgen daarom het advies de wachtwoorden en sleutels van bovengenoemde files aan te passen als zij een van de gekoppelde programma's gebruiken. Mensen die adblockers gebruiken, zijn mogelijk beschermd geweest, maar dat hangt af van de gebruikte filters.

Reacties (50)

[Verwijderd]

0-day reporter hier. De exploit was dus actief op een Engelstalige in Rusland gevestigde nieuwswebsite. Ik kan nog niet zeggen om welke nieuwswebsite het gaat omdat de exploit nog actief is. Ze zijn er in ieder geval van op de hoogte. Ik was niet op zoek naar een exploit maar kwam deze toevallig tegen omdat ik er zelf slachtoffer van werd. Wat alle alarmbellen deed afgaan was het feit dat er een 'file dialog' verscheen toen ik deze website bezocht met de vraag of ik een lokaal bestand wilde openen, in dit geval een van mijn public keys. Dit heb ik uiteraard direct geannulleerd. Ik heb toen de Firefox Developer Tools geopend om te kijken waar dit vandaan kwam. Daar zag ik in de web console een hele lijst aan bestanden die een script had geprobeerd te lezen. Ik ging er toen nog vanuit dat er niets daadwerkelijk was ingelezen. Ik vernieuwde de pagina om de netwerk requests in de gaten te kunnen houden. Daar zag ik tot mijn grote schrik mijn private and public keys voorbij komen in de POST payload van een van de requests naar een bepaald IP-adres (Oekraïens, niet dat van de nieuwswebsite). Ik gebruik deze als SSH keys dus ik heb deze toen overal zo snel mogelijk verwijderd. Ik ben vervolgens op zoek gegaan naar de exploit. Deze had ik vrij snel gevonden omdat deze via hetzelfde IP-adres werd opgehaald als het IP-adres waar de data naar werd verzonden. Ik heb dit script toen opgeslagen en geprobeerd te achterhalen wat het doet. Ik ben zelf geen security expert maar het was duidelijk dat het ging om een Same Origin Policy violation in PDF.js (gebruikt door Mozilla Firefox om in de browser PDF-bestanden de kunnen weergeven) waarbij toegang tot lokale bestanden wordt verkregen terwijl dit niet mogelijk zou moeten zijn. Ik heb toen een bug ticket op Bugzilla aangemaakt met alle informatie die ik had en het script bijgevoegd. Binnen 1 dag was het gepatcht.

Naast de volledige lijst van bestanden in de user directory (dus niet de inhoud van de bestanden) wordt de inhoud van de volgende bestanden verzonden:

Linux:
/etc/passwd
/etc/hosts
/etc/hostname
/etc/issue
.bash_history
.mysql_history
.pgsql_history
.ssh/known_hosts
.ssh/authorized_keys*
.ssh/id_*sa*
.remmina/*.remmina
.remmina/*.pref
.config/filezilla/*.xml
.filezilla/*.xml
*pass*.txt
*access*.txt
*.sh
.config/psi+/profiles/default/accounts.xml

Windows (in de mappen AppData/Roaming en Application Data van de gebruiker):
Subversion: config, servers, auth/svn.simple/*, auth/svn.simple/*.*
SmartFTP: Client 2.0/Favorites/Quick Connect/*.xml
Psi+: profiles/default/accounts.xml
Notepad++: plugins/config/NppFTP/NppFTP.xml
.purple: accounts.xml
s3browser: *.xml, *.settings
FileZilla: filezilla.xml, sitemanager.xml, recentservers.xml
FTP Explorer: profiles.xml
FTPRush: RushSite.xml
FTPGetter: servers.xml
FTP Now: sites.xml
FTPInfo: ServerList.cfg, ServerList.xml
GHISLER: wcx_ftp.ini
Ipswitch: WS_FTP/Sites/ws_ftp.ini
VanDyke: Config/Sessions/*.ini

Hieruit valt af te leiden dat de aanval waarschijnlijk gericht is op developers in dit specifieke geval, maar de exploit kan ook ingezet worden om andere bestanden op te halen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 11:24]

[Glodenox]

Bedankt voor de lijst aan bestanden! Gelukkig gebruik ik geen een van die applicaties, dus ik loop geen risico (hoewel deze bug mogelijk ook al door anderen gebruikt werd natuurlijk...).

Eigenlijk was de exploit dus knullig geschreven. Anders zou je nooit een file dialog gekregen hebben waardoor het opviel dat er iets aan het gebeuren was. Dat is dan nog een geluk geweest + jij hebt meteen goed gehandeld. Als deze door meer mensen gekend was had dit zeer fout kunnen aflopen.

Vraagje: werd dit script echt in een met PDF.js geopende PDF uitgevoerd of ging het over het deel waarin PDF.js nog werd ingeladen? Dat is me nog niet volledig duidelijk.

[Verwijderd]

Graag gedaan.

Eigenlijk was de exploit dus knullig geschreven. Anders zou je nooit een file dialog gekregen hebben waardoor het opviel dat er iets aan het gebeuren was. Dat is dan nog een geluk geweest + jij hebt meteen goed gehandeld. Als deze door meer mensen gekend was had dit zeer fout kunnen aflopen.

Ik heb nog wat zitten spelen met de exploit en ik zie nu dat de enige reden dat ik een file dialog te zien kreeg is dat de public key de .pub extensie had. Het lijkt er op dat je standaard een file dialog te zien krijgt als Firefox een mimetype kan vinden voor de bestandsextensie, in dit geval werd de .pub extensie geassocieerd met application/vnd.ms-publisher waardoor ik een file dialog te zien kreeg. Mimetypes worden in Firefox bepaald door de ExternalHelperAppService. Hier heeft eigenlijk niet Firefox maar mijn OS mij eigenlijk gered door het mimetype te bepalen. Als er geen mimetype bekend was voor de .pub extensie bij mijn OS dan had ik er niets van gemerkt. Probeer maar eens een bestand met je browser te openen met en zonder bekend mimetype. In het eerste geval krijg je een file dialog, in het tweede geval wordt de inhoud van het bestand door de browser weergegeven.

Ik zie nu ook dat mijn private keys waren versleuteld met een passphrase dus daar had de aanvaller waarschijnlijk ook niet veel aan. Achteraf gezien was het dus misschien niet nodig om nieuwe paren te genereren maar better safe than sorry.

Vraagje: werd dit script echt in een met PDF.js geopende PDF uitgevoerd of ging het over het deel waarin PDF.js nog werd ingeladen? Dat is me nog niet volledig duidelijk.

Playpreview is inderdaad de overlay die je te zien krijgt met de vraag of je een plugin wilt activeren. In dit geval werd het volgens mij nog als 'hack' door Firefox gebruikt om met PDF.js PDF-bestanden in embed tags te kunnen laden. Met de exploit was het mogelijk om hier scripts in te injecteren waarbij het mogelijk was om de same origin policy te omzeilen. Het gaat dus niet om scripts in de PDF-bestanden.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 11:24]

[Douweegbertje]

Tja ik ben van mening dat niet perse dev's specifiek getarget worden, al snap ik wel waarom men dat gelijkt denkt. Ze pakken gewoon de common bestanden waar passwords in staan, dat is gewoon één van de makkelijkste manieren om daadwerkelijke data te verkrijgen. Ik kan mij voorstellen dat de meeste FTP clients in het lijstje óók flaws hebben waardoor de passwords eruit gehaald kunnen worden, vandaar die redelijk specifieke lijst. Sowieso was volgens mij FilleZilla per definitie al in plaintext.
Maar in elk geval, stel je hebt toegang tot een PC, al dan niet dat je bestanden kan stelen. Er zijn niet zo heel veel zinvolle opties. Cookie data verloopt en is meestal puur voor de huidige sessie dus tegen de tijd dat je de data hebt en hebt verwerkt is dat wellicht al weer nutteloos. Niet te spreken nog over alle mogelijkheden die tegenwoordig gebruikt worden om misbruik tegen te gaan.

Dus ja, als je dan eventueel passwords kan krijgen van websites, root van servers en ga zo maar door, heb je heel snel en effectief winst gemaakt. Gaat het dan specifiek om dev'ers? Mah.. met pass.txt en access.txt richting ze al per definitie iedereen. Hoe vaak het wel niet voorkomt dat mensen hun wachtwoorden zo opslaan.. Als ze iets slimmer waren geweest hadden ze het ook nog per taal erin gezet.

[Verwijderd]

Misschien heb je wel gelijk. Als je een exploit hebt waarmee je alleen bestanden kunt lezen (en niet schrijven of op een andere manier slachtoffers infecteren) dan is het vrij logisch dat je op zoek gaat naar keys/wachtwoorden die je vervolgens kunt gebruiken om toegang tot computers te verkrijgen die je wel kunt infecteren.

[Patriot]

Dus ja, als je dan eventueel passwords kan krijgen van websites, root van servers en ga zo maar door, heb je heel snel en effectief winst gemaakt. Gaat het dan specifiek om dev'ers? Mah.. met pass.txt en access.txt richting ze al per definitie iedereen. Hoe vaak het wel niet voorkomt dat mensen hun wachtwoorden zo opslaan.. Als ze iets slimmer waren geweest hadden ze het ook nog per taal erin gezet.

Toch lijkt het me een beetje onderdeel van een tweetrapsraket. Eerst infiltreer je zoveel mogelijk FTP-servers, in stap twee infecteer je deze websites met zero-day malware die de PC van de bezoeker infiltreert.

In die eerste stap richt je je toch vooral op de beheerders/ontwikkelaars van die websites.

[Cyb]

Ik zie WinSCP niet in het lijstje staan, je zou verwachten dat de hackers die ook zouden pakken.

[locke960]

Tja, hier werd dus allom voor gewaarschuwd toen Mozilla met het idee kwam een PDF reader in te bouwen. Dit is waarom het een slecht idee is allerlei niet essentiele funktionalitiet aan een browser toe te voegen en, nog erger, standaard aan te zetten. Dit is niet de eerste keer dat zoiets gebeurt met Firefox, en het gaat ook de laatste keer niet zijn.
Jammer, dit is een direkt gevolg van slechte beleidsbeslissingen. 20 jaar geleden maakte Microsoft ook regelmatig van dit soort twijfelachtige beslissingen en ze moeten er nog steeds voor bloeden. (wij ook trouwens)

[Reactie gewijzigd door locke960 op 24 juli 2024 11:24]

[kozue]

Slechte beslissing? Als ik mag kiezen tussen een Mozilla pdf reader die netjes onderhouden wordt en waar bugs snel in worden gefixed of die troep van Adobe, die lekken lekker een paar maanden laat wachten of uberhaupt nooit fixt (flash en acrobat zijn nog steeds zo lek als een mandje) heb ik liever die eerste...

[Glodenox]

Goh, de fout lijkt me eerder dat men gekozen heeft om de JavaScript container waarin pdf.js draait rechten te geven op het lokaal systeem. De enige rechten dat de container dient te hebben is de datastream van de website lezen of misschien de toegang om het gevraagde bestand lokaal te kunnen uitlezen.

Gezien het wijd verspreide gebruik van PDF op het internet lijkt het me sterk om te zeggen dat dit out-of-the-box ondersteunen een slechte keuze is. Hetzelfde zou je dan ook kunnen zeggen over Flash in Google Chrome. Dat je tegen de toevoeging van Firefox Services bent kan ik nog enigszins begrijpen, maar dit lijkt me toch echt iets anders.

[cornedor]

Als de rechten idd het zelfde zijn kan dit zelfs een veiligere situatie opleveren. In het geval dat er een exploit wordt gevonden met het gebruik van dezelfde rechten is dit een probleem in de browser, niet in de PDF reader, omdat de PDF reader van Firefox volledig in JavaScript is geschreven (je zou dit ook in chrome kunnen draaien of op je website embedden), daardoor is er maar 1 onderdeel dat goed gechecked moet worden ipv naast de browser je externe PDF reader, het is ook vaak zat voorgekomen dat er een exploit zat in Acrobat Reader.

[MrFax]

Je wilt niet weten hoeveel lekken Adobe Reader heeft gehad de afgelopen jaren. Als je dat bekijkt is de Mozilla PDF reader zo slecht nog niet.

[Room42]

Inderdaad, en die werd dan ook nog eens vaak niet geupdate, terwijl hij ook automatisch geladen werd voor PDF's, embedded in de browser. Dat zette ik ook altijd uit, trouwens. Ik gebruik SumatraPDF.

[Verwijderd]

Voor iedereen die de ingebouwde pdf-viewer wil uitschakelen:

Ga naar about:config en verander pdfjs.disabled naar True.

[bbob]

Of een goede adblocker gebruiken zoals het artikel stelt.

Hoe meer je leest over exploits hoe meer je leest dat ze via advertentienetwerken verspreid worden. Een goede adblocker is niet alleen zinvol om advertenties to blokkeren maar dus ook exploits via die netwerken.

[Pruttelpot]

Precies! En die meldingen van Tweakers enzo dan maar gewoon negeren



<sub>Je blokkeert onze banners

Hoi! We zien dat je waarschijnlijk AdBlock, Ghostery, NoScript of andere software gebruikt die onze banners ontregelt. Dat vinden we jammer, hiermee ontneem je Tweakers in essentie inkomsten die we hard nodig hebben. Help ons door Tweakers te whitelisten of beleef Tweakers bannervrij en word abonnee! Lees hier meer over ons verdienmodel.</sub>

[bbob]

Klopt jammer voor hun advertentie-inkomsten maar feit is dat malware steeds meer via advertentienetwerken zijn weg kan vinden.
Aangezien er schijnbaar te weinig controle is in die netwerken of er geen scans plaatsvinden is een adblocker ook zinvol als een soort malware bescherming.

[David Mulder]

Super makkelijke oplossing dan toch: gebruik gewoon sites die geen advertenties gebruiken voor hun inkomnsten. Je hoeft dan nog steeds niet een adblocker te gebruiken en over de ruggen van andere jouw content binnen te halen '-_-.

[bbob]

En nog een persoon die bepaald wat en hoe een ander het moet doen en dan ook nog met termen als over de ruggen van anderen komen. Trest hoor.

Ik draai het om, kan tweakers of anders site die met advertenties werkt mij 100% garanderen dat ik via hun site geen malware binnenkrijg ? Als ze dat kunnen kan ik de blocker uitzetten.

Als is dan toch malware binnenkrijg compenseren die sites mij dan. Ik betaal hun immer door naar advertenties te kijken c.q er op te drukken. Als betalende klant heb ik rechten.

De realiteit is dat er niet gekeken wordt naar malware via advertenties. Toon je dus advertenties dan moet je je als site bewust zijn dat je je kijkers malware kan presenteren. Dat is een keuze die je neemt met het tonen van advertenties via een netwerk.

[David Mulder]

Hoezo is het trienst om te stellen dat het over de ruggen van anderen is? Dat is toch letterlijk hoe het is? Anderen moeten vanwege mensen die zo nodig advertenties blokeren meer advertenties zien dan hun eigen 'portie'. Dat is toch gewoon ronduit asociaal. Natuurlijk is er een risico dat er malware via advertentie netwerken word verspreid, en dat is gewoon een deel van het risico door via advertenties te betalen voor je content. Daarom ook dat ik ondanks de tracking liever een adsense oplossing op een site zet dan een eigen oplossing die mogelijk op een dag misbruikt zou kunnen worden. En ja, mogelijk is het risico van malware het niet waard, maar gebruik dan die sites gewoon niet als je dat echt meent.

[bbob]

Het is niet triest het is marktwerking, vraag en aanbod.
Adblockers zijn een feit en neem je dat niet mee in je bedrijfsmodel, doe je dan niet ben je dom Je zal er rekening mee moeten houden dat mensen jou site bezoeken met een adblocker. Als je daar niet van kan rondkomen, pech voor jou dan moet je creatiever zijn met hoe je wel geld kan verdienen. Kun je dat niet zal een ander het voor jou doen. Zo werkt het gewoon tegenwoordig en al jaren. dit is ook in de offline markt zo, doe je als winkel niet je best en doet een ander het beter verlies je. Vrij markt noemt men dat.

Een adblocker is een recht dat je hebt en is een keuze die je zelf maakt. Met profiteren heeft dat niets te maken, dat maak jij er van.

Het is zelf triest dat je stelt dat je het risico maar moet nemen om malware via advertenties te krijgen. Leuk als jou computer misbruikt wordt via malware van zeg tweakers of andere site.

[Patriot]

Een adblocker is een recht dat je hebt en is een keuze die je zelf maakt. Met profiteren heeft dat niets te maken, dat maak jij er van.

Een adblocker is een recht? Waar is dat volgens jou vastgelegd dan?

Het is zelf triest dat je stelt dat je het risico maar moet nemen om malware via advertenties te krijgen. Leuk als jou computer misbruikt wordt via malware van zeg tweakers of andere site.

Niks triest aan. Als je gebruik maakt van het web dan loop je het risico om malware op je PC te krijgen. Waar dat precies vandaan komt maakt wat dat betreft niet veel uit. Het staat je vrij om advertenties niet te laden, maar het staat anderen vrij om dat asociaal te vinden of om je toegang tot hun overige content te weigeren.

[bbob]

Lijkt me een zinloze discussie met jou.

Het is jou recht mijn recht ieder recht om software op zijn of haar pc te zetten. Als die software een adblocker is is dat een recht dat je hebt. Ik draai het om waar staat ergens dat het verboden is ?

Kijk je gaat nu een stap verder, toegang weigeren tot content. Die vorm hebben we nog niet gehad. Als je een adblocker hebt en je geen content krijgt is dat wederom een recht van de website dat zo te doen. Ook dat is een model waar je voor kan kiezen en wat al gebeurt.

Je moet dan zelf afwegen of je de adblocker aan of uit wil zetten.

weet je wat echt asociaal is. Websites die gebruik maken van advertentienetwerken waar malware door verspreid kan worden. Die sites kiezen er bewust voor zelf geen controle te heben over advertenties en geven hun bezoekers dus doelbewust een risico malware te krijgen.

[Patriot]

Lijkt me een zinloze discussie met jou.

Het is jou recht mijn recht ieder recht om software op zijn of haar pc te zetten. Als die software een adblocker is is dat een recht dat je hebt. Ik draai het om waar staat ergens dat het verboden is ?

Ik reageerde zo omdat je een hele losse definitie van het woord 'recht' gebruikt. Meestal zijn rechten (zoals we ze bijvoorbeeld uit de grondwet kennen) belangrijke zaken, die overduidelijk moreel goed zijn en de moeite waard zijn om te verdedigen (voor de moreel relativisten onder ons: in onze culturele context).

De definitie van het woord 'recht' die jij hanteert is tamelijk nutteloos, omdat het alleen aangeeft dat iets niet expliciet verboden is.

Het mogen gebruiken van een adblocker een recht noemen komt dus over als een poging om die handeling veel meer waarde te geven dan het verdient.

Kijk je gaat nu een stap verder, toegang weigeren tot content. Die vorm hebben we nog niet gehad. Als je een adblocker hebt en je geen content krijgt is dat wederom een recht van de website dat zo te doen. Ook dat is een model waar je voor kan kiezen en wat al gebeurt.

Wat is dit nu weer? Een beheerder van een website mag volgens jou dus wel mensen actief weigeren omdat ze een adblocker gebruiken, maar als hij dat doet omdat hij het gebruik van een adblocker asociaal vind en stelt dat ze hun heil ergens anders mogen zoeken dan is het opeens triest?

Heb je enig idee hoe tegenstrijdig je bezig bent nu?

weet je wat echt asociaal is. Websites die gebruik maken van advertentienetwerken waar malware door verspreid kan worden.

In tegenstelling tot de advertentienetwerken waar geen malware door verspreid kan worden? Die bestaat niet. Er is geen redelijk alternatief voor die advertentienetwerken, het is alomtegenwoordig en het toegevoegde risico is nihil. Er is dus niks asociaals aan.

Die sites kiezen er bewust voor zelf geen controle te heben over advertenties en geven hun bezoekers dus doelbewust een risico malware te krijgen.

Iedereen die een website beheert geeft zijn bezoekers een doelbewust risico om malware te krijgen. Het is totaal niet inherent aan het gebruiken van een extern advertentienetwerk.

Als kers op de taart wil ik nog even opmerken dat een adblocker in het geval van het artikel niet eens geholpen zou hebben.

[Pruttelpot]

Ghehehe. Geinige discussie dit.

Kijk, ik sta vrij om advertenties te blokkeren en sites staan vrij om bezoekers die advertenties blokkeren bijvoorbeeld naar disney.com door te sturen.

Ik heb een hekel aan ads en dus blokkeer ik ze. Dat ik daarmee inkomsten voor bv tweakers ontneem is vervelend voor ze en het staat ze dan ook geheel vrij om maatregelen te nemen (zoals een redirect naar disney.com).

Zolang dat echter niet het geval is, en de site sneller en beter werkt met een adblocker; zie ik geen enkele reden om de adblocker uit te schakelen. Hoe vervelend het ook is voor de inkomsten van (bv) tweakers.

Het blijft een keuze van de eindgebruiker en er is niemand die mij kan verplichten de adblocker uit te schakelen. Ne als dat niemand tweakers kan verplichten een redirect naar disney.com in te schakelen; ook dat is een keuze.

[Reactie gewijzigd door Pruttelpot op 24 juli 2024 11:24]

[Patriot]

Oh, maar ik heb persoonlijk ook geen enorm probleem met het gebruiken van een Adblocker hoor. Ik snap het echter wel als andere mensen het nét wel erg genoeg vinden om het asociaal te noemen.

Ik reageerde vooral op bbob1970 omdat hij zo raar deed over het feit dat sommige mensen het asociaal vinden om er een te gebruiken. Alsof het feit dat mensen vinden dat je er geen gebruik van mag maken je in je rechten aantast.

Verder mag iedereen wat mij betreft een Adblocker gebruiken hoor. Ik accepteer (nagenoeg) geen flash en cookies, en via mijn hosts-file worden alle requests naar bepaalde tracking-domeinen geblokkeerd. Daar zitten ook genoeg advertentienetwerken bij. Dat komt dus effectief op nagenoeg hetzelfde neer als een adblocker.

[Verwijderd]

Neem dan tenminste een abonnement.

[bbob]

Grappig mensen die denken te kunnen bepalen wat een ander moet doen.

[Verwijderd]

Ik gebruikte een adblocker en het heeft niet geholpen. Noscript zou wel geholpen hebben maar daar breek je weer een hoop websites mee. Het script werd niet geladen via een adnetwerk maar een iframe werd geinjecteerd op alle pagina's. Dit betekent dat waarschijnlijk de nieuwswebsite zelf geinfecteerd was.

[Verwijderd]

ga het meteen instellen

[Maurits van Baerle]

Kennelijk is de patch dus binnen twee dagen na ontdekking al naar iedereen uitgerold, bovendien nog via een applicatie die standaard automatisch update. Ik denk dat er weinig third-party PDF readers zijn die zo snel en zo effectief zullen en kunnen reageren.

[GeoBeo]

Inderdaad, nog even los van het feit dat alle PDF viewers van alle browers IMO echt verschrikkelijke draken van programma's zijn. Ze zijn rule #1 van interface design vergeten: consistency.

[Douweegbertje]

Poe sterke taal allemaal. In principe valt het allemaal redelijk mee. Ten eerste heeft menig gebruiker een PDF viewer in zijn browser zitten, daarbij is dat ook nog eens uit te schakelen. Je handen afhouden van functionaliteiten die zeer omarmt wordt omdat je dan potentieel meer opties geeft tot exploits is pas een slechte beleidsbeslissing.
Wellicht is het ook een deel hoe je het zelf ervaart. Gezien dat je alles nog met een 'K' schrijft in plaats van de huidige spelling ('C' dus) ben je iets ouder en zul je inderdaad anders tegen zaken aan kijken. Iets met verandering en dergelijke.

[Verwijderd]

Poe sterke taal allemaal. In principe valt het allemaal redelijk mee. Ten eerste heeft menig gebruiker een PDF viewer in zijn browser zitten, daarbij is dat ook nog eens uit te schakelen.

Je vergeet dat je een tweaker bent. Het gros van de mensen vindt alles best, als ze hun informatie maar kunnen benaderen. En op aanraden van iemand die enigzins technisch is hebben ze ook een virusscanner draaien. Vaak zonder hem ooit bijgewerkt te hebben trouwens, en een goede kans op de 90-dagen versie van Norton of McAfee die bij de computer geleverd werd.
Dus een heel groot deel van de computers is vatbaar.

[Douweegbertje]

Ja, maar net zoals alle overige PDF functionaliteiten die in browsers gezet worden. Dan kun je beter een standaard 'plugin' hebben die ook zo automagisch geupdate kan worden.
Juist omdat het gebruikers zijn, is het stiekem wel één van de meest solide oplossingen, immers willen ze allemaal PDF's hebben. Users zijn gek op PDF's.

[Reactie gewijzigd door Douweegbertje op 24 juli 2024 11:24]

[Alex3]

Ik heb een pesthekel aan PDF's. Waarom moet het allemaal gepagineerd worden als je het toch niet afdrukt? Dat is alleen maar hinderlijk bij het bekijken. Ik geef de voorkeur aan webpagina's En als ik dan toch iets afdruk bepaal ik liever zelf hoeveel er op een pagina gaat.

[angelina]

Blijkbaar zit het probleem in het pdf.js project, zie hier de changes.

Wat ik niet begrijp is, de reader is geheel in JavaScript is geschreven. Hoe kan het dan bij de Windows files? Zit het lek dan niet in de JS engine?

[Reactie gewijzigd door angelina op 24 juli 2024 11:24]

[Glodenox]

De PDF viewer is inderdaad in JavaScript geschreven, maar blijkbaar kon er een exploit geschreven worden die in de PlayPreview (het scherm dat je krijgt alvorens je de PDF opent) wordt uitgevoerd. Mijn vermoeden is dat PlayPreview in zekere mate ook HTML is, maar op een ander beveiligingsniveau draait. Als je daar dan JavaScript in kan draaien, kan je inderdaad leuke dingen doen. De verwijdering van PlayPreview lijkt me dan om eerlijk te zijn een zeer brute manier om het probleem op te lossen.

Maar nogmaals: dat is maar een vermoeden. Ik heb hier de tijd niet om me te verdiepen in de code.

[Maurits van Baerle]

Wat is die PlayPreview dan precies? Als ik op een PDF klik opent hij volgens mij direct de PDF. Of zie ik iets over het hoofd?

[Glodenox]

Ik *vermoed* dat je de PlayPreview krijgt als je een plug-in gebruikt om PDF's weer te geven, maar je eerst nog eens klikken op het element op de plug-in te activeren. Zoals het activeren van Flash op een website waar je dit nog niet automatisch laat uitvoeren.
Het zou wel betekenen dat iemand die PDF.js gebruikt en geen andere PDF plug-in heeft ingesteld staan veilig zou zijn. Maar dit is nog niet helemaal duidelijk voor mij en mogelijk sla ik de bal hier volledig mis.

[Verwijderd]

PDF.js draait in een sandbox en heeft meer rechten dan een normale webpagina, in pdf kun je ook weer scripten, etc. Sommige pdf documenten "doen het niet" als je ze niet met meer rechten kunt renderen. Deze rechten kunnen blijkbaar niet beperkt worden, dus moet pdf.js ze zelf afschermen en alleen toelaten waar nodig. Daar is het blijkbaar deze keer tekort geschoten.

[Glodenox]

Ook interessant in het bronartikel is dat er geen willekeurige code kon mee worden uitgevoerd. De exploit kon enkel via JavaScript bepaalde acties uitvoeren die normaal niet mogelijk zouden zijn (de code kon dus draaien zoals de code van pdf.js in Firefox kan draaien):

The vulnerability does not enable the execution of arbitrary code but the exploit was able to inject a JavaScript payload into the local file context. This allowed it to search for and upload potentially sensitive local files.

Wel vreemd dat het in een advertentie zat. Betekent dit dat het zelfs niet nodig was om een PDF te openen maar dat er onrechtstreeks misbruik kon gemaakt worden van die interne plug-in? Er wordt door Mozilla aangeraden om bij de opgelijste applicaties nieuwe wachtwoorden in te stellen, wat misschien geen slecht idee is aangezien je een PDF ook gewoon kan openen in een kleine iframe en zo onopgemerkt data kan opsturen.

[Verwijderd]

Dat is precies wat er gebeurde. De 'pdf' werd geopend in een iframe. Doordat de Same Origin Policy kon worden omzeild konden lokale bestanden worden gelezen.

[--Andre--]

Misschien was die "advertentie" wel een embedded pdf bestand?

[TheRealProcyon]

.bash_history is een file geen directory

[Twilkie]

Dat staat er toch ook niet?

[TheRealProcyon]

Eerder wel