Veiligheidslek in Macromedia Shockwave

Macromedia's overbekende Shockwave plug-in blijkt een zogenaamde buffer overflow bug te bevatten. Door misbruik van deze bug te maken moet het mogelijk zijn om browsers te laten crashen, of zelfs een executable op te starten. Macromedia zelf beweert dat op 90% van alle browsers de plugin geïnstalleerd is, wat dus in theorie 90% van het web als onveilig verklaart:

Impact of risk:

The buffer overflow can be used to execute arbitrary code stored in the SWF file. "Bad" arbitrary code causes the plugin to crash the browser. "Good" arbitrary code can execute a program on the browser's computer. This can be used to propogate a virus, worm, or do other harmful tasks.

It is possible to write a single SWF file that contains platform-specific overflow/opcodes for multiple systems (Solaris, Linux, Windows, Irix, etc.).

Worst case:

I'll leave this for you to decide. I believe a multi-platform (Windows/Unix) self-modifying virus is possible. ("Self-modifying" would be hard part.)

Met dank aan Belgarion voor de tip. Lees het complete artikel hier.

Reacties (34)

[Verwijderd]

Oke, jongens even over die buffer overflow.

Het klopt dat het geheugen van een process (waarin een programma draait) beschermd wordt door het OS (ja, zelfs door W95). Maar het wordt ALLEEN beschermd tegen andere processen, en natuurlijk niet tegen zichzelf. Een process mag lezen/schrijven in zijn EIGEN gebied, maar niet dat van een ander.

Voor een "datum" veld bijvoorbeeld wordt niet een apart memory blok gealloceerd, maar wordt meestal een stukje STACK of HEAP gebruikt, die deel uit maken van het DATA gedeelte van het programma. Het process zelf kan dus niet alleen in dit veld schrijven, maar in (megabytes) er omheen.

Een "overflow" gebeurt als je een buffertje van n bytes allokeert, bijvoorbeeld in C met:

char buffer[10];

en er vervolgens teveel in schrijft:

strcpy(buffer, "deze tekst is veel te lang!");

Omdat zo'n strcpy niet weet hoe groot je buffer is, wordt die string er domweg in gepropt, en overschrijft het geheugen dat volgt. Dus als je nog een variable hebt die volgt op die buffer, dan wordt de waarde die daarin staat dus overschreven. Meestal heeft dat een crash van het programma tot gevolg.

Het uitvoeren van "arbitraire" code werkt als volgt.
1. Je moet weten op wat voor plek het geheugen gealloceerd wordt. Met een debugger kun je dat achterhalen.
2. Maak je eigen invalid blokje, en zorg dat bijvoorbeeld de "return" pointer (meestal moeilijk omdat die een LAGER geheugenadres heeft) of een functie pointer die wordt aangeroepen overschreven wordt met JOUW waarde.
3. Zorg dat die naar code wijst in jouw nieuwe blokje. Gewone "intel" machinecode zal werken op ALLE OSsen, nog even achterhalen welk OS actief is, en dan de juiste (?) acties ondernemen.

Tegen zo'n overflow kan een OS je meestal niet beschermen.

Als je toch aan het programmeren bent, als je ipv
char buffer[10];
gebruikt:
char* buffer = (char*)GlobalAlloc(GMEM_FIXED, 10);

dan krijg je een mooie Access Violation error als je die strcpy uitvoert met voldoende karakters. Maar dit is veeeeeeeel trager (orde 1000x) dan de eerste versie.

[Squee]

3. Zorg dat die naar code wijst in jouw nieuwe blokje. Gewone "intel" machinecode zal werken op ALLE OSsen, nog even achterhalen welk OS actief is, en dan de juiste (?) acties ondernemen.

Dat hoeft natuurlijk niet. Een Sun, SGI, IBM, Alpha... enzovoorts, kunnen natuurlijk niets met "intel" machinecode als er geen x86 compatible processor in zit! Zo zie je bijvoorbeeld bij Solaris exploits altijd een versie voor i386 en voor Sparc staan, omdat deze processor architecturen gewoon verschillend zijn!

[RRX]

Ik snap trouwens niet waarom macromedia dit bekend maakt, het is toch veel slimmer om gewoon bij iedereen automatisch een ShockwavePluginUpdate onopgemerkt te installeren, nu zet je alleen maar van die hackers en scriptkiddies aan het denken, lijkt me geen goede zaak

[silvershadow449]

Als je het artikel gelezen had, dan wist je dat niet macromedia maar een gast, Neal Krawetz genaamd, deze bug ontdekt heeft en gepubliceerd heeft.

Overigens is dit al een oude bug. Hij is vorig jaar in july ontdekt. Macromedia heeft dit dus kennelijk met opzet niet publiekelijk bekend gemaakt. Verontrustend dat Macromedia na 6 maanden nog steeds geen patch hiervoor gereleased heeft.

[Plux]

Volgens mij is het niet 90% van het web dat onveilig is, maar 90% van de webgebruikers die onveilig bezig zijn. En alleen die sites die gebruik maken van de shockwave-plugin zouden onveilig _kunnen_ zijn. Maar je moet maar weten dat shockwave deze bug bevat, volgens mij weinig reden om je zorgen te maken.

[Verwijderd]

Weten WE nu niet dat die bug erin zit?

[TheGhostInc]

Dit is net zoiets als dat je in Outlook met een scriptje automatisch een executable van je harddisk kunt starten, dan moet die executable er wel opstaan.

Dit is net zoals met zoveel 'bugs' er kan wel wat gebeuren, maar alleen als je precies die situatie hebt waarvan de maker uitgaat, terwijl dan computers ineens heel veel verschillen.

[Verwijderd]

Wat dacht je van CMD.EXE (of COMMAND.COM voor minder stabiel bedeelden)? Met CMD -c kun je ieder commando, zoals DEL /S \ uitvoeren...

[T.T.]

shocking news

[Verwijderd]

tja .SWF is gewoon een bestandje...
elk bestandje kan virussen bevatten..

bij NS.nl is ut nog best link want die gebruiken bij hun reisplanner een .EXE file...

maarja... de treinen rijden al bijna nooit dus die site heeft ook weinig nut

nu heeft macromedia wel een redem om een versie 6.0 uit te brengen met wat bug fixes

[Verwijderd]

Ik denk niet dat Macromedia gaat wachten tot versie 6 tot ze dit 'probleempje' gaan oplossen, een bugfixje binnen korte tijd zou wel op zijn plaats zijn, want als je een virusje naar 90% van de webgebruikers kan sturen zal Macromedia wel aardig geshockt zijn van de schadeclaims

[Verwijderd]

wat noem je wachten? Deze bug werd bekend in juli 2000, dus een half jaar geleden!

[mth]

Die reisplanner .EXE van de NS site draait op de server van de NS, daar is voor de bezoeker niets onveiligs aan.

[DeTeraarist]

Ik moest dus net een update voor Flash installeren van Macromedia. (Ik had Flash 5 al geinstalleerd)
Alleen weet ik niet of het probleem hier mee is opgelost, daar werd verder niets over gezegd.

[johanvdw]

Er is nog geen update voor het probleem.

Macromedia has been alerted to the problem, but has not yet responded, nor released a fix.

(van http://www.securitywatch.com/scripts/news/list. asp?AID=5277 )

[maffie]

Die gasten bij securitywatch hebben een wat uitgestelde milleniumprobleem aan hun datum te zien!! Want wat is 01/03/20001 ??

[Verwijderd]

Die maffe amerikanen willen de datum nog wel eens omdraaien....
Plotseling komt er dan weer een geldige datum naar voren.

[drice]

Kijk eens goed naar het aantallen nullen in 2001
juist er staan er drie

[metalant]

Buffer overflow bugs zijn waarschijnlijk de meest voorkomende bugs die er tegenwoordig ontdekt worden.

Weet iemand ook hoe ze ontstaan?

[BrammeS]

buffer overflow zegt het al! Als je alsmaar nieuwe vars aanmaakt zonderde oude te sluiten kan je geheugen/swap file volraken.

[Verwijderd]

heel simpelweg gezegd wordt zal een programma een stukje geheugen reserveren voor zichzelf. die ruimte is beperkt en wordt 'gecontroleerd' door het programma. Bij een buffer overflow wordt er meer data naar dat stukje geheugen toegeschreven dan mogelijk is, en zal die data (indien zoals nu niets is beveiligd) in een ander stukje geheugen gaan zitten. Dat stukje geheugen wordt niet bewaakt en zo kan je dus in die ruimte arbitrary code laten uitvoeren.

(toch?)

[BrammeS]

Okee thnx voor de verbetering

[Verwijderd]

Ik weet niet precies hoe het werkt, maar wat jij zegt klopt niet. Dat zou nl. betekenen dat het programma slecht met je geheugen om gaat. En dat is jammer maar niet schadelijk.

Paz was me al voor

[arnob]

Heel simpel voorbeeld is die Outlook Express overflow waar zo'n kabaal over was:
Als je zelf een mailtje structureer waar ipv de datum van het bericht een bytecode in staat dan zal OE die reeks rechtstreeks in het geheugen gooien. Aangezien er geen controle op de lengte is zal de bytestring andere dingen overschrijven. Als er een stukje code achterstaat ipv nog een stukje werkgeheugen dan verander je dus het programma!
Een heel gedoe dus. Zowieso zullen de meeste OSen programma's van elkaar gescheiden houden. Dus 'het geheugen' overschrijven kan niet.

[FireFly]

Je kan scripten in Shockwave, betekend dit dan ook niet dat je met kwaad opzet allerlei dingen kan doen ?
'k Wil nou niemand op ideën brengen hoor

[silvershadow449]

Of je nou kan scripten in Shockwave of niet, doet er in dit geval niet zoveel toe. Het gaat hier om een bufferoverflow die een hacker zou kunnen exploiteren.

De termen bufferoverflow en arbitrary code zeggen al genoeg over de ernst van deze bug. In het ergste geval zou een hacker hiermee root access kunnen verkrijgen. Kijk maar eens op naar de advisories van bijv. Red Hat...

[mr_a]

Toch niet echt onverwacht.... gegeven dat bug-vrije software een utopie is. ShockWave is natuurlijk ook iets dat onwijs in ontwikkeling is en daarnaast waarschijnlijk niet iets triviaals is, codetechnisch gezien. Afwachten op de volgende bug dus, als deze gepatchd is...

[Deddiekoel]

Een dag niet gepatched is een dag niet geleefd