Stor säkerhetsbrist i Adobe Acrobat och Reader

[e-son]

http://www.idg.se/2.1085/1.213684/stor-sak...i-adobe-acrobat

Kanske dags att kasta ut Adobe Reader för gott ??

Här är några alternativ! Det finns fler för den som orkar söka!

http://www.pdf2exe.com/reader.html

http://www.foxitsoftware.com/pdf/rd_intro.php

http://blog.kowalczyk.info/software/sumatrapdf/index.html

http://www.cadkas.com/downengpdf5.php

[JoWa]

För drygt en halvtimme sedan postade jag ett inlägg i en tråd om detta: https://forums.comodo.com/feedbackcommentsa...t-t34921.0.html

Denna sårbarhet finns i ”alla” program. Se här om QuickTime Player 7.6: http://support.apple.com/kb/HT3403?viewlocale=sv_SE

Bättre att ha en skydd mot buffertöverskridning för hela systemet, än att vänta på uppdateringar som fixar säkerhetsbristerna, eller undvika program p.g.a. sådana brister.

[e-son]

För drygt en halvtimme sedan postade jag ett inlägg i en tråd om detta: https://forums.comodo.com/feedbackcommentsa...t-t34921.0.html

Denna sårbarhet finns i alla program. Se här om QuickTime Player 7.6: http://support.apple.com/kb/HT3403?viewlocale=sv_SE

Bättre att ha en skydd mot buffertöverskridning för hela systemet, än att vänta på uppdateringar som fixar säkerhetsbristerna, eller undvika program p.g.a. sådana brister.

Mjo... jag kan förstå om vissa företagsanvändare har fastnat i "Adobeträsket" och kanske inte klarar sig utan t.ex Acrobat, men för alla privatanvändare finns ingen som helst anledning att hålla fast vid Adobe Reader. Säkerhetshålen duggar tätt, datorn säckar nästan ihop av att öppna ett pdf-dokument... m.m, m.m! Släng ut sk*ten och använd någon lättviktare i stället, är mitt råd!

[L-L]

Såna här hål dyker ju upp hela tiden i alla möjliga program, och de utnyttjas förstås främst i ofta använda program såsom Adobe och IE. Vi kan inte förlita oss på patchar eller ens antivirussignaturer, vi behöver proaktivt bufferöverskridningsskydd! Men om jag nämner mitt klassiska exempel på ett sådant blir jag väl påhoppad av någon medlem här.

Men visst kan man också byta ut de mest utsatta programmen såsom Adobe Reader mot något annat. Min egen favorit är PDF-XChange Viewer (portablel): http://www.docu-track.com/home/prod_user/P...ols/pdfx_viewer

[Mickilina]

Även Adobe har vaknat upp, tydligen:

http://computersweden.idg.se/2.2683/1.2136...tm_medium=email

[Gäst al6]

Fattar inte riktigt, är det bara i Adobes produkter eller är det i något underliggande bibliotek typ Qt som felet ligger så det även finns i andra produkter?

Denna sårbarhet finns i ”alla” program. Se här om QuickTime Player 7.6

[Gäst al6]

I frustration sökte jag fram lite info om riktiga buffer overflows, nog den mest intressanta läsningen på länge.

http://mixter.void.ru/exploit.html

Som ni ser är det 100% programmering, vilket jag även sagt tidigare. Alla personer som anser sig vara "säkerhetsexperter" MÅSTE vara elitprogrammerare för att fylla ut sin titel, vilket tyvärr inte är ofta. Många "experter" är helt vanliga IT-konsluter som tyckte namnet klingade bra verkar det som.

Som vi kan läsa på sidan handlar det om att skriva över returneringsadressen som sparas på stacken när en funktion kallas, detta sker genom att man skickar in data till programmet som får programmet att skriva utanför en buffer (t ex skicka in för stora filer eller för långa texter), samt använder sig av en shell-funktion (t ex ShellExecute under Windows) för att kalla ett riktigt program med skadlig kod. JoWas sånt här memory firewall eller vad det heter fungerar så att den kollar så ingen returneringsadress ändras under körning, vilket är genialiskt. Dock verkar säkerhetshål inte vara så svåra att undvika om man är en kunnig programmerare; det räcker att använda så kallade "säkra" funktioner, vilket jag alltid gör. C++ har tex funktioner som itoa() som konverterar ett heltal till en ascii-sträng, vilket inte är en säker funktion då den inte kontrollerar storleken av destinationsbuffern och då kan skriva över den. Dock finns det en uppdaterad version _itoa_s() vilken tar emot storleken av destinationsbuffern och aldrig skriver utanför den. Visual Studio 2008 varnar dessutom programmeraren när man använder osäkra funktioner. Dessutom ska den utnyttjade processen köras som administratör för att vara ett intressant mål.

Så efter att jag äntligen fått lite riktig fakta om säkerhetshål i form av buffer overflow är jag helt lugn; jag har alltid använt säkra funktioner och jag använder Visual Studio som hjälper mig göra det säkert. Dessutom är det sällan jag gör saker som ska köras som admin och dessutom ta emot indata.

As for the programmer (you), it is a hard task to write secure programs, but it should be taken very serious. This is a specially large concern when writing servers, any type of security programs, or programs that are suid root, or designed to be run by root, any special accounts, or the system itself. Apply bounds checking (strn*, sn*, functions instead of sprintf etc.), prefer allocating buffers of a dynamic, input-dependent, size, be careful on for/while/etc. loops that gather data and stuff it into a buffer, and generally handle user input with very much care are the main principles I suggest.

[JoWa]

Fattar inte riktigt, är det bara i Adobes produkter eller är det i något underliggande bibliotek typ Qt som felet ligger så det även finns i andra produkter?

Det jag menade är att det inte är meningsfullt att peka ut ett program som sårbart, då denna säkerhetsbrist tycks dyka upp så snart man vänder på en sten, s.a.s., och istället för att i ”panik” byta ut det program som senaste larmet gäller, eller vara beroende av uppdateringar som rättar till bristerna, bör man se till att systemet är säkrat mot buffertöverskridning, oavsett var den dyker upp.

Dessa uppdateringar är som definitionsuppdateringar: de är bra då de kommer, men de kommer alltid för sent. Innan Adobe, Apple och övriga utvecklare har upptäckt och rättat till bristerna, har någon annan upptäckt och utnyttjat säkerhetshålen. Innan defintionerna har uppdaterats har en mängd datorer infekterats…

JoWas sånt här memory firewall eller vad det heter fungerar så att den kollar så ingen returneringsadress ändras under körning, vilket är genialiskt.

Varför är inte Windows genialiskt?

Intressant läsning f.ö.

[Gäst al6]

Ja gjorde en bild som visar hur lätt man kan fixa säkerhetshål i vissa fall, grön text är kommentarer. Som ni ser är Visual Studio där och varnar när man gör ett uppenbart säkerhetshål / buffer overflow. Antivirus och liknande skydd verkar inte ha något upp emot "returneringsadressskydd" (Memory Firewall), kanske blir en del av Windows i framtiden, då det fungerar utan definitionsuppdateringar.

[Gäst al6]

<svordom som bör accepteras av moderatorerna> va ballt!

Ja kompilerade mitt buffer overflow-exempel efter att ha installerat Memory Firewall från COMODO i hopp om att få en varning men utan resultat, men istället kommer det upp en ballong-ruta som säger att Windows har stängt programmet på grund av felaktig användning av systemminne

Data Execution Prevention verkar vara någon form av Memory Firewall och det fungerar ju uppenbarligen så jag tar nog och avinstallerar Memory Firewall igen Just nu kör jag Vista x64.

Redigerad Februari 24, 2009 av al6
Svordom bortredigerad

[JoWa]

Jävlar va ballt!!!

Ja kompilerade mitt buffer overflow-exempel efter att ha installerat Memory Firewall från COMODO i hopp om att få en varning men utan resultat, men istället kommer det upp en ballong-ruta som säger att Windows har stängt programmet på grund av felaktig användning av systemminne

Detta var spännande! Men om du stänger av Dataexekveringsskyddet, får du då en Memory Firewall-varning? Jag menar, kan det handla om att Windows i detta fall hann före? Om det verkligen är så att CMF (och den uppdaterade version som ingår i CIS) missar att upptäcka den buffertöverskidning som ditt program orsakar, bör det rapporteras som en bugg, och helst skall Comodo få testa med ditt program.

Data Execution Prevention verkar vara någon form av Memory Firewall och det fungerar ju uppenbarligen så jag tar nog och avinstallerar Memory Firewall igen Just nu kör jag Vista x64.

Ja, se en jämförelse här: http://www.alltomxp.se/forum/index.php?s=&...ost&p=99746

[Gäst al6]

Fast när jag ska släppa programmet genom DEP får jag följande meddelande efter att ha testat länge:

<bild>

Dock tror jag inte det är en bugg i MF, kanske bara ignorerar det eftersom det bara är en ofarlig BO och inget allvarligt säkerhetshål. Dock fick jag lite info från tråden du skickade och man kan, enligt den, säga att säkerheten är ordnad såhär:

Minst säkert först: Windows Vista x86 (mjukvarubaserad DEP), Windows Vista x64 (hårdvarubaserad DEP som stoppar mycket mer), COMODO Memory Firewall.

Där har vi ju även svart på vitt ett bevis på att Vista x64 är säkrare än Vista x86, och att Windows faktiskt håller på att få ett rejält bra skydd mot virus inbyggt (DEP:en lär ju bli bättre i framtiden?).

[Gäst al6]

Skickar upp programmet så dom som vill kan testa.

[JoWa]

Skickar upp programmet så dom som vill kan testa.

Tack, men: ”Test.exe har stött på ett problem och måste avslutas.”

[Gäst al6]

Jo programmet kraschar ju eftersom jag skriver utanför buffern och då fackar programet, men om du trycker cancel eller väntar kommer du ju få upp en ballong-ruta som säger att det stängdes av DEP. Kör du x86 eller x64?

Edit: Windows XP Pro SP3 ser jag du har enligt signatur, har XP ens DEP? I så fall verkar det inte vara så alert precis

Nåja, jag läser här på wikipedia och det är väldigt ballt det hela, jag är knappast fullärd inom det här, och jag lär ju mig hela tiden. Inte allt jag skrivit i denna tråden är 100% sant ser jag nu, t ex så är jag inte helt säker på hur det här Memory Firewall fungerar men på ett ungefär då Man kan få lite info på wikipedia också, under buffer overflow ser man att det står samma sak där att man kan skriva över returneringsadressen.

Nåja, intressant ämne men man märker också att operativsystemen blir allt säkrare och säkrare

[JoWa]

Jo, det blir bättre:

DEP was introduced in Windows XP Service Pack 2 and is included in Windows XP Tablet PC Edition 2005, Windows Server 2003 Service Pack 1 and later,[1] Windows Vista, and Windows Server 2008. It is also included in beta versions of Windows 7

http://en.wikipedia.org/wiki/Data_Execution_Prevention

Men fortfarande stoppade inte Vista (x64?) BO Tester, då du testade: http://www.alltomxp.se/forum/index.php?s=&...ost&p=99641

Fick inga meddelanden alls då jag körde Test.exe, förrän det vill exekvera dwwin.exe.

[Gäst al6]

Jo, det blir bättre:

http://en.wikipedia.org/wiki/Data_Execution_Prevention

Men fortfarande stoppade inte Vista (x64?) BO Tester, då du testade: http://www.alltomxp.se/forum/index.php?s=&...ost&p=99641

Fick inga meddelanden alls då jag körde Test.exe, förrän det vill exekvera dwwin.exe.

Okej men då har du ju x86 vilket då är mindre säkert. Dock har du rätt i att jag failade på alla tester i det testet så uppenbarligen har DEP lite kvar att ta igen tills det är en riktig ersättare av Memory Firewall, det verkar dock vara rätt OK. Att programmet skulle köra dwwin.exe är väl en sidoeffekt av overflowen, så visst är det en BO

Okej men det var ju en intressant tråd det här, mycket ballt att Windows har rätt OK "Memory Firewall" som fungerar någorlunda ändå Tänk ändå vad extremt mycket säkrare Vista är än t ex Windows 98; UAC, DEP, Windows Firewall, Windows Defender. Man får väl hoppas på en framtid utan allt för avancerade virus.

[e-son]

Back to topic!

Lite "nya fakta" i målet... inkl. en inofficiell patch för att täppa igen hålet!

http://www.idg.se/2.1085/1.214003/pdf-bugg...d-sedan-januari

...fast rekommendationen att i första hand dumpa Adobes "cpu-knäckare" kvarstår!

[Gäst al6]

Vi är inte off-topic!

Vi har ju kommit fram till att DEP eller Memory Firewall kan vara till stor nytta när man kör kod som inte är säkert programmerad, vilket är exakt vad som är fallet i tråden, att använda dessa tekniker kan vara en lösning om man fortfarande vill köra Adobes produkter. Resten är ju prat om säkerhetshål i from av buffer overflows, vilket även det är vad tråden handlar om.

[e-son]

Vi är inte off-topic!

Vi har ju kommit fram till att DEP eller Memory Firewall kan vara till stor nytta när man kör kod som inte är säkert programmerad, vilket är exakt vad som är fallet i tråden, att använda dessa tekniker kan vara en lösning om man fortfarande vill köra Adobes produkter. Resten är ju prat om säkerhetshål i from av buffer overflows, vilket även det är vad tråden handlar om.

Eftersom jag skapade tråden och därmed satte topic, så vill jag bestämt förbehålla mig rätten att avgöra vad tråden handlar om! Nu har jag inte klagat på era inlägg eftersom jag inser att dom är högst relevanta, trots en viss avvikelse från den ursprungliga tanken att informera om ett specifikt säkerhetshål i ett specifikt program! Så fortsätt du gärna diskutera som tidigare!

[plun]

Eftersom jag skapade tråden och därmed satte topic, så vill jag bestämt förbehålla mig rätten att avgöra vad tråden handlar om! Nu har jag inte klagat på era inlägg eftersom jag inser att dom är högst relevanta, trots en viss avvikelse från den ursprungliga tanken att informera om ett specifikt säkerhetshål i ett specifikt program! Så fortsätt du gärna diskutera som tidigare!

Jo dags att "basha" Excel....

http://secunia.com/advisories/33954/

Adobe är ju så lätt att ge sig på.....

Sen kan man ju "barnsäkra" sin burk om man känner för det....

[JoWa]

Jo dags att "basha" Excel....

http://secunia.com/advisories/33954/

Adobe är ju så lätt att ge sig på.....

Sen kan man ju "barnsäkra" sin burk om man känner för det....

Mm, man får väl välja om man vill 1) undvika sårbara program, så snart en larmrapport publiceras, 2) sitta med ett sårbart system i väntan på uppdateringar, eller 3) se till att systemet är säkert, oavsett vilket program en attack riktar sig mot, och om det programmets säkerhetsbrist är känd eller inte.

Hoppas att Windows kommer att hantera buffertöverskridning bättre småningom.

[Gäst bäver]

Men visst kan man också byta ut de mest utsatta programmen såsom Adobe Reader mot något annat. Min egen favorit är PDF-XChange Viewer (portablel): http://www.docu-track.com/home/prod_user/P...ols/pdfx_viewer

Bra förslag!

Ett annat är Foxit Reader (finns även som portabel)...

http://filehippo.com/download_foxit/

Angående Foxit Reader...

Foxit Reader NOT subject to recent exploits to Adobe vulnerability

http://www.foxitsoftware.com/announcements/2009226SxiZ.html

[e-son]

Jag vet inte om det är samma sårbarhet som det tjatas om, eller om det är dags igen!

http://www.idg.se/2.1085/1.216394/allvarli...t-adobe-acrobat

[Gäst bäver]

Jag vet inte om det är samma sårbarhet som det tjatas om, eller om det är dags igen!

http://www.idg.se/2.1085/1.216394/allvarli...t-adobe-acrobat

Får intrycket av att det är ytterligare en ny sårbarhet...

Wednesday 4 March 2009

Quickpost: /JBIG2Decode Trigger Trio

http://blog.didierstevens.com/2009/03/04/q...e-trigger-trio/