Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties
Bron: eWeek

De Britse veiligheidsonderzoeker David Kierznowski heeft manieren ontdekt om via pdf-bestanden in Adobe Reader of Adobe Professional 'aanvallen' uit te voeren op het lokale computersysteem. Volgens Kierznowski gaat het niet om bugs in de software van Adobe, maar om het op een creatieve manier uitbuiten van legitieme functionaliteit in pdf-bestanden. Om zijn beweringen kracht bij te zetten, heeft de Brit van twee van de negen gevonden backdoors voorbeelden online geplaatst. In het eerste voorbeeld is het pdf-document zodanig aangepast dat automatisch een bepaalde url wordt geopend. Dit zou bijvoorbeeld de url van een website kunnen zijn die geheel automatisch malware downloadt en installeert, zodat op eenvoudige wijze een systeem besmet kan worden met kwaadaardige software.

Het tweede door Kierznowski beschreven exempel beschrijft een manier om via Adobe Database Connectivity en webservicesupport in Adobe-software een overzicht te krijgen van en eventueel aanvallen uit te voeren op de op localhost aanwezige databases. Volgens de onderzoeker zouden er nog minstens zeven andere punten zijn waarop pdf-bestanden in combinatie met Adobe-software misbruikt zouden kunnen worden. Gezien het feit dat die programmatuur ook support aan boord heeft voor html-formulieren en toegang heeft tot het bestandssysteem zouden op korte termijn uitgebreidere backdoors kunnen verschijnen. Een woordvoerder van Adobe heeft laten weten dat Kierznowski's ontdekkingen onderzocht worden en dat waar nodig oplossingen zullen worden vrijgegeven.

Moderatie-faq Wijzig weergave

Reacties (36)

Dit is gewoon een strategische fout van Adobe.

Een PDF reader moet een documentje tonen, er moet geen mogelijkheid zijn om het filesystem te benaderen.

Als je die mogelijkheid geeft, tja, dan zijn PDF's straks even gevaarlijk als een EXE openen. En dat was nu niet de bedoeling van een PDF documentje!
Dat zeg jij wel zo, maar met bijvoorbeeld internet explorer of firefox kan je ook bij je file system komen. Neem de mogenlijkheid om attachments aan een mailtje toe te voegen. Het probleem is dat dit geheel automatisch kan. Dat zou natuurlijk niet mogen.
Volgens Kierznowski gaat het niet om bugs in de software van Adobe, maar om het op een creatieve manier uitbuiten van legitieme functionaliteit in pdf-bestanden.
Als het om legitieme functionaliteit gaat, in hoeverre hebben andere programma's hier dan last van? Ik kan me zo voorstellen dat die ook deze functionaliteit ondersteunen, en er dus ook last van hebben.
Inderdaad, in foxit kijk ik ook tegen de google site aan...
Proof of concept for example 1 can be found here.
Proof of concept for example 2 can be found here.

Ik gebruik overigens al een tijdje foxit reader, perfect alternatief als iemand deze zoekt.
als je de proof of concept pdf files in de firefox browser opent (met de adobe plugin) dan werken de backdoors niet :)

Melding:
"Formulier moet in het Acrobat-venster worden geopend (in tegenstelling tot de webbrowser) om dit formulier te kunnen verzenden"

dus iig voor backdoor 1 & 2 is er wel zeer grote nieuwsgierigheid van de gebruiker nodig :P
hoe vaak krijg je niet een factuurtje via pdf? of ergens een stukje software met een pdf-handleiding? of gewoon een e-bookje van een nieuwsserver?
@Adm. Spock:

Het heeft niets te maken met FireFox hoor, als je het onder IE opent werkt het precies hetzelfde ;)
Bij mij doet ie 't gewoon :? Er word een 2e scherm met de url http://www.google.com/owned weergegeven.
bij nadere bestudering blijk ik die functionaliteit uitgeschakeld te hebben :P

My bad :+
En deze opend de bestanden nog sneller ook!
Darkprince1234 anders lees je eens alle replies van Tweakers-bezoekers.

Gepost door dtech - zaterdag 16 september 2006 12:40
Inderdaad, in foxit kijk ik ook tegen de google site aan...

edit:

rofl mijn post overbodig. En dat terwijl Adm.Spock toegeeft dat hijzelf oorzaak is van het falen van de backdoor.
XplodingForce ook omlaag gemodereerd. Anti-Microsoft-Fanboys of Adobe-aanhangers?
;(
Ik moet nou niet echt zeggen dat ik dit een schokkende ontdekking kan noemen... In PostScript is al eens een webserver geschreven en een jaar of twee geleden hebben we met een vak op de uni al eens naar de mogelijkheden van PDF gekeken.

PDF is een krachtige taal en het feit dat je er kwaadaardige dingen mee kan doen is juist wl een bug in de readers want die hebben dan geen goede sandbox om de code in te draaien.
Weer een voorbeeld dat per definitie geen enkel stukje software is te vertrouwen.Wat linux al een tijdje heeft:een mandatory access controll mechanisme in de vorm van SELinux,AppArmor,etc..zou in meerdere bestrurings systemen geimplementeerd moeten worden.Zodat programmas alleen dat kunnen doen waarvoor ze geschreven zijn.Al het ongeoorloofde wordt gewoon stilletjes genegeerd.

De DAC (gewone file permissies) is allang achterhaald.Je geeft geen gebruiker rechten maar programmas (software) ,wat een hoop niet beseffen.
Heb je helemaal gelijk in. Maar Microsoft erkent dit ook en .NET is bedoeld als oplossing hiervoor. In .NET draaien applicaties, net als onder JAVA, in een 'Virtual Machine'. De virtual machine is dan verantwoordelijk voor de access control. Als je in een applicatie gebruik wilt maken van bijvoorbeeld het filesysteem of het netwerk, dan moet je permissie vragen aan de runtime (de virtual machine). De runtime geeft je dan al dan niet een permissie object terug, afhankelijk van de instellingen die de gebruiker of beheerder heeft gedaan. Met dit permissie object doe je een aanroep naar het filesysteem. De echte code die daadwerkelijk de file opent en inleest of wegschrijft is code die onderdeel is van de runtime zelf.

Het is dus niet zo dat Linux over een oplossing beschikt die ander systemen niet hebben. Alle JAVA en .NET applicaties draaien ook al in een beschermde omgeving.

Het probleem is dat wanneer je een applicatie draait in native code, code die is vertaald naar binaire code voor dat specifieke platform, bijv. x86 processoren, je de volledige controle weggeeft aan die applicatie. De applicatie heeft de processor in zijn macht en het is heel moeilijk om alle mogelijkheden tot misbruik dan uit te bannen.

Ik vermoed dan ook dat in de komende jaren we een beweging zien naar steeds minder native-code applicaties. De security problemen ermee zijn gewoon te groot. De applicaties, extensions en drivers die nog wel in native code uitkomen zullen dan waarschijnlijk allemaal verplicht moeten worden gecertificeerd en digitaal gesigneerd.
Hoewel de door jouw beschreven oplossing voor .NET en java programma's prima werkt is het niet vergelijkbaar met SELinux. Het verschil zit 'm in de plek waar het draait en de daaruit voortvloeiende toepasbaarheid.
Bij SELinux is namelijk elke applicatie onderhevig aan de permissies die gezet zijn op het systeem. Oude programma's kunnen dus ook prima werken zonder aanpassingen aan het programma zelf (Wellicht moet je er wel een policy voor schrijven, maar dat kun je zonder hulp van de fabrikant of orginele auteur).
Ik denk dus dat windows niet een vergelijkbaar iets kent, juist vanwege dit verschil
een soortgelijke functie zit ook in zonealarm, krijg je een pop up met de vraag of je een programma toegang wilt geven tot de kernel, probleem is alleen dat veel gebruikers wat te makkelijk op ja klikken en niet eerst controlleren wat voor programma dat is
It's not a bug, it's a feature.
Mensen weten tegenwoordig niet meer waar PDF vandaan komt. PDF is een vervolg op PostScript. PostScript is een programmeertaal om documenten mee te beschrijven. Let op, ik schreef programmeertaal, en dat bedoel ik ook letterlijk zo. PostScript is een volwaardige programmeertaal. Vroeger (en op goede printers nog altijd) stuurde je je printopdracht als een PostScript programma naar je printer. Daar werd het door de processor van de printer uitgevoerd, en het programmaatje bepaalde dan wat er geprint werd.
Een klassieke grap is het om een PS file te schrijven met een oneindige loop er in, die dan tot in de eeuwigheid blijft doorprinten.

PDF is dus een opvolger van PS. Maar het bevat nog steeds een volledige programmeertaal. Dat je met een volledige programmeertaal alles op een computer kan doen is niet echt nieuws.

De PDF programmeertaal heeft dezelfde rechten als de Adobe software die je gebruikt om de PDF file te bekijken. Als je PDF viewer bestanden van je HD kan lezen, dan kan een PDF file dat dus ook. Als je PDF viewer bestanden van inet kan halen, dan kan een PDF file dat dus ook.

De mannen van Adobe weten dat best, ze hebben het zelf zo bedacht. Ze proberen dus wel om de hele PDF programmeertaal in een afgesloten "zandbak" te laten draaien, waar de PDF files niet buiten kunnen komen.
Maar het luistert nogal nauw om zo'n beveiliging helemaal goed te krijgen, dus dat er wat sluipwegen zijn verbaasd me helemaal niks.
"It's not a bug, it's a feature"

Inderdaad, veel van deze dingen zijn al lang geweten. Ik heb zelf lang getwijfeld of ik dit voorbeeld in mijn boek over PDF zou opnemen:
http://itext.ugent.be/ite...sults/silent_printing.pdf
Niet direct op gaan klikken! Er zit een klein stukje JavaScript in dat de PDF onaangekondigd naar de default printer stuurt.
Is dat een security hazard? Misschien, want je zou een loop kunnen schrijven die de pagina eindeloos laat afprinten. Anderzijds zijn er heel veel mensen die naar een dergelijke feature vragen. Vandaar: toch maar zo'n voorbeeldje voorzien.
Merk op dat er tooltjes bestaan om 'Launch actions' te verwijderen uit PDFs. Bvb http://itext.ugent.be/lib...oveLaunchApplication.java
Een aantal bedrijven gebruiken dit tooltje om alle PDFs die binnenkomen (via mail, via HTTP) te ontdoen van alle acties die een EXE of een ander potentieel gevaar kunnen betekenen.
Die printers hebben vaak ook een berg geheugen en zijn networked,en men vergeet vaak aan de veiligheid te denken.Denk aan een programmaatje als highjetter waarmee je direct het cache kan beschrijven of uitlezen etc.
Bij beide voorbeelden krijg ik een javascriptwaarschuwing maar google.com opent wel in een Adobe Acrobat Reader-venster.

Mogelijk heb ik javascript deactief gezet in de instellingen omdat ik alleen zo statisch mogelijke PDF-bestanden geopend wil zien.
Ik zie al voor me dat een uitgever die zijn bladen in PDF aanbied automatisch zijn homepage met aanbiedingen laat zien en dan is dit nog vriendelijk bedoeld.
Tijd voor een andere PDF reader tot er meer bekend is over een update van Adobe.
Tja alles is te misbruiken en PDF ook want we wilde toch zo'n handige link functionaliteit. HTML mail is dus ook gevaarlijk mail met links is gevaarlijk. Oh vervelend internet is is gewoon een groot potentieel gevaar. Laten we gewoon de bron aanpakken en de mogelijkheid van schadeverhaal, zodat niemand het nog doet. Utopie misschien maar als een spammer, hacker etc gewoon kaal geplukt wordt en een paar jaar mag brommen dan is het in ieder geval niet meer zo lucratief om te doen.
Welke nedelander heeft tralies voor zijn ramen? Ik hoef alleen maar een steen door de ruit te gooien en je spullen mee te nemen. Schandalig die aannemers.
Vind het een beetje dwaas zo: urls openen die dan naar een 'kwaadardige site' linken. Dat kan je ook doen door bijvoorbeeld in een Word-document zo gezegd een link te steken naar een moppen site (ik zeg maar wat) :? Of zie ik het niet breed genoeg?
Dan moet je nog zelf klikken, hiermee gebeurd het automatisch. Afhankelijk van eventuele kwetsbaarheden van de browser die je gebruikt is een PDF-bestand openen (waarvan je voor het openen nog niet weet of er iets mee aan de hand is) genoeg om automagisch malware op je PC te krijgen.
Hij opent vanzelf, en als dat heel snel gaat, dus het venster opent, zichzelf gelijk sluit, en de focus terug naar Adobe reader zet, weet jij niet dat er een of ander virus op je PC is gezet.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True