PDF-hack afvikler programkode uden hjælp fra sårbarheder
Sikkerhedshuller i Adobe Reader er inden for de seneste år blevet de it-kriminelles foretrukne mål, men selv uden sikkerhedshuller i softwaren kan PDF-filer være farlige at åbne.
Sikkerhedseksperten Didier Stevens demonstrerer på sin blog, hvordan kreativ brug af PDF-sproget gør det muligt at få flere PDF-læsere til at køre et program, som er skjult i PDF-filen.
Adobe Reader klarer sig faktisk marginalt bedre i denne sammenhæng end én af de alternative PDF-læsere, Foxit Reader. I Adobe Reader får brugeren en dialogboks med en advarsel, som det ifølge Didier Stevens dog er muligt at spoofe en del af indholdet af. På den måde kan angriberen forsøge at narre brugeren til at ignorere advarslen.
I Foxit Reader bliver programmet imidlertid afviklet uden advarsel, så brugeren får ikke en chance for at opdage problemet, før det er for sent.
Ifølge Didier Stevens skal hans hack dog tilpasses, før programmet faktisk kommer til at køre fra Foxit Reader, men det skyldes angiveligt forskelle i implementeringen af PDF-sproget snarere end at Foxit Reader skulle være sikker.
I andre PDF-læsere som PDF-Xchange og Sumatra til Windows-platformen virker det hack, som Didier Stevens har frigivet en demonstration af, ikke uden yderligere tilpasning.
Kommentarer (10)
Hej Ove,
Er PDF efterhånden på vej mod en tidlig død, pga. fejl og exploits?
Exploitet er jo ikke i PDF selv men i PDF-læsere.
-
0 -
0
Giver det mening at sige, at et program gør noget utilsigtet uden at der er tale om en sårbarhed? Er det beskrevne ikke netop et eksempel på en sårbarhed?
-
0
-
0
Det er vel standarden der foreskriver at programmet skal opføre sig på den måde. Så er det ikke en sårbarhed i programmet, men i standarden, og så hedder det ikke sårbarhed mere men 'broken by design'...
Som Didier siger: 'I’m not exploiting a vulnerability, just being creative with the PDF language specs'
-
0
-
0
Det er korrekt, men det medvirker jo til at ødelægge ryet for PDF dokumenter, hvis folk ikke tør åbne dem.
Hvad nu, når der kommer en virus som forgifter alle ens lokale pdf dokumenter med en fejl som gør, at læsere vil eksekvere kode så snart dokumenterne åbnes. Så sender man en af sine forgiftede PDFer videre, og denne eksekverer så noget kode, som forgifter alle modtagerens PDF dokumenter. And on it goes.. Så er der der ikke meget troværdighed tilbage. PDF lider i forvejen nok under alle de fejl der er i Adobes læser.
Og siden det ikke umiddelbart er en sårbarhed, men en feature, så er det jo lidt problematisk når det er i selve dokumentstandarded fejlen ligger.
-
0
-
0
Jesper Lund Stocholm, 31. marts 2010 09:11
Exploitet er jo ikke i PDF selv men i PDF-læsere.
Hvornår laver Adobe en PDF-læser, der kun kan læse PDF filer?
-
0
-
0
PDF-koden bruger jo "/OpenAction " som nok aldrig burde være opfundet til PDF.
... og det burde som minimum være muligt globalt at slå det fra i en PDF-viewer, hvis funktionen overhovedet er blevet implementeret.
Sikkerhedshul er det vel kun hvis man kan manipulere med pop-up-teksten, eller pdf-vieweren undlader at advare inden den udfører ekstern kode.
I øvrigt på eksterne-links-siden er der link til en blog hvor der er en simpel calc.pdf der også virker med linux + mac (kalder så hhv. xcalc eller Calculator.app).
Evince og xpdf i linux ser ikke ud til at udføre noget (sikkert ikke implementeret).
Acroread, også i linux, udfører filen, men kun efter at man i pop-up har godkendt at ville udføre filen. Jeg kan dog ikke finde et global sted i acroread for at slå funktionen helt fra.
-
0
-
0
Hej Lean,
Det er vel standarden der foreskriver at programmet skal opføre sig på den måde.
Det er bestemt ikke nødvendigvis tilfældet. Applikationsspecifik opførsel er som oftest udeladt i dokumentformat-specifikationer. At sårbarheden virker på tværs af flere applikationer synes jeg indikerer, at det netop er et område, der ikke er dækket af specifikationen.
Så er det ikke en sårbarhed i programmet, men i standarden, og så hedder det ikke sårbarhed mere men 'broken by design'...
Det er jeg ikke enig med dig i. Dit argument svarer til, at klandre ODF for at være "usikkert" [0] fordi OOo tillader afvikling af makroer uden brugerens accept (det gør den ikke, skal jeg huske at sige - det er blot et eksempel).
"Launch actions" er definerede i afsnit "12.6.4.5 Launch Actions", og her er ingen guidance til, hvordan en givet applikation skal håndtere afvikling af programmer etc.
PS: det ser ud til, at man kan anvende URIs i disse actions som reference til placeringen af den indlejrede fil. Dette kunne evt være et endnu større problem end det her påpegede.
[0] s/ODF/OOXML, s/OOo/MicrosoftOffice, s/HTML/IE6 (afvikling af arbitrær kode)
-
0
-
0
PDF er, uanset standardisering, en abomination. Der er tilføjet et hav af underlige features, der er tilskrevet og lavet om utallige gange. Det er måske nok ikke selve standarden sikkerhedshullerne befinder sig i, men det er da klart at chancen for sikkerhedshuller bliver meget større når man skal implementere sådan et rod.
-
0
-
0
men det er da klart at chancen for sikkerhedshuller bliver meget større når man skal implementere sådan et rod.
Hvis man nøjes med at implementere ISO 32000-1:2008?
-
0
-
0
Tilføj kommentar
