Proof-of-concept-code cpu-specifiek virus gepubliceerd

Securityonderzoekers bij Symantec hebben een nieuw proof-of-concept-virus ontdekt dat zich specifiek richt op AMD-processors in plaats van bepaalde besturingssystemen. De malware is beschikbaar in twee versies: w32.bound en w64.bound voor respectievelijk 32- en 64-bit Windows-systemen. Het gaat nu nog om proof-of-concept-code, maar de mogelijkheid bestaat dat het virus wordt uitgebreid zodat het op meer verschillende hardware-architecturen en OS'en zal kunnen werken. Een probleem daarbij is echter dat iedere processorfamilie zijn eigen variant op opcode spreekt om met de hardware te communiceren. Vooralsnog gaat het om een Windows-virus, maar de mogelijkheid bestaat dat dit in de toekomst wordt uitgebreid zodat ook *nix-achtigen ermee bediend kunnen worden.

Als het virus eenmaal geactiveerd is, wat onder meer kan plaatsvinden door een besmette executable te starten, gaat het zich hechten aan andere uitvoerbare bestanden in Windows. Vervolgens wordt geprobeerd om toegang te krijgen tot de hardware en de processor, waarbij eventuele softwarematige beveiligingen omzeild worden. Hierbij hoeft niet gebruikgemaakt te worden van lekken in Windows, aangezien er ook op gewone wijze toegang verkregen kan worden tot de hardware. Als dat eenmaal gelukt is, is het in theorie mogelijk om van alles te doen met de computer, zoals het verwijderen van data van een harde schijf of het leegmaken van het BIOS.

Reacties (51)

[EaS]

dat zich specifiek richt op AMD-processors in plaats van bepaalde besturingssystemen

Onzin, lees ook deze thread @ aces.

Er wordt door Symantec helemaal geen vermelding gemaakt over AMD processoren, maar over "W64.Bounds is a virus that infects 64-bit Windows executable files"

Die gast die schrijft voor VNUnet heeft waarschijnlijk gelezen "Systems Affected: Windows 64-bit (AMD64)". AMD64? Dan moeten het wel AMD processoren zijn.

Zie ook W64.BoundsRisk Level 1: Very Low en W64.Bounds - New 64 bit EXE virus infector.

Niets geen processor specifiek virus dus.

[Quacka]

in dat geval mag VNU en Tweakers (maar dat is natuurlijk ook van VNU) zich rot schamen.
Of gaan melden dat het gesponsord wordt door Intel.

[Verwijderd]

Uit het originele artikel:

But you would not use this technique if you wanted to get a pandemic. You would not use this technique unless it was for a very targeted attack or an academic attack

Er staat zelfs in het artikel dat het gewoon een hobbybob projectje is om te bewijzen dat dit kan. Het is ook helemaal niet nieuw, Chernobyl wordt er ook in genoemd, en er wordt genoemd dat dit type virus zeldzaam is omdat je er bar weinig doelen mee treffen kan. Als je het interview leest staat daar iets heel anders dan in de beschrijving van die knakker van VNUnet. Die bouwt me daar een ophef, om echt helemaal níéts.

Ik hoop dat de schrijver van het originele artikel gauw een echte baan vind ipv te schrijven voor een technisch blad want daar is ie wel voor gediskwalificeerd.

[d3vlin]

In dat geval zou het dus enkel gaan om een virus dat enkel een computer met 32- of 64-bit cpu kan besmetten (voor elk cpu type een apart virus)?

[cavey]

Een probleem daarbij is echter dat iedere processorfamilie zijn eigen variant op opcode spreekt

Kuch, probleem?

Intel en AMD praten toch allebei met de x86 instructieset? Wat een strict omschreven aantal instructies heeft, ook wel bekend onder de naam "opcode" ... met een hoeveelheid operands, afhankelijk van het gebruik danwel de toepassing van de opcode?

Hoe de hel kan een CPU pratende in het dialect genaamd x86 een verschillende hoeveelheid opcodes hebben?

(ff alle SSE, SSE2, SSE3, 3Dnow, NX-bit, 64bit extensies daargelaten)... sommige zijn geimplementeerd, in het geval van de diverse uitbreidingen op de default x86 set, maar hallo, als de ene CPU-familie een opcode ondersteund, en de andere CPU-familie ook (Intel vs. AMD), dan is er toch geen variatie in de opcode?

Er is hooguit variatie in de onderliggende microcode, die voor de daadwerkelijke uitvoer zorgt van de opcode (tegenwoordig althans, vroeger was een opcode ook echt een direct hardware pad.. maar met de complexiteit van de huidige CPU's, heb je gewoon een zooi microcode dingen, die de achterliggende software zijn voor de opcodes zoals de buitenwereld ze ziet.. sounds complicated? )

Afijn....... op dit moment vind ik het maar een hoop FUD in de trant van "ZOMG! Een virus die helemaal low-level gaat en gebruik maakt van opcodes!". Willen ze beweren dat het virus op de oldschool manier is geschreven, 100% asm/machinetaal (aka... opcodes) en misbruik maakt van eventuele hardware bugs in de CPU's? En.... als het virus opstart, neemt het dan gewoon je hele CPU over, zodat heel je windows e.d. niet meer werkt? Ofwel, wordt dan het programma (aka virus) dan het enige draainde proces op de CPU?

Hoop vragen die zo bij me opkomen, om maar niet te spreken over een mogelijk ambigu gebruik van de term opcode, die echt niet variabel is binnen een bepaalde instructieset.

Dat het niet cross-platform is snap ik wel, daar een sparc een andere instructieset heeft (andere opcodes) dan een ia32 architectuur. Of Arm, Mips, PPC etc... Geen een enkel hardcoded assembler programma is cross-platform (tenzij ze het stuk software meerdere payloads bevat, afhankelijk van de cpu-architectuur).

Wup......

[Carpetsmoker]

http://www.freebsd.org/ -> "Based on BSD UNIX"

Ik acht de kans groot dat BSD Unix afstamt van Unix.

Unix history: http://www.levenez.com/unix/history.html

In dat schema kun je Mac OS/X terug vinden, en als ej dan alle lijntje terugvolgt kom je bij unix uit.

Ik ben het dan ook niet met je eens, ik ben van mening dat Mac OS/X wel degelijk een unix-based OS is.

Mac OS/X heeft een hoop userland tools van FreeBSD "geleend"

De korte, incomplete, versie:
In 1974 heeft AT&T, om Unix beter te maken, goedkoop licenties inclusief source verkocht aan een aantal universiteiten.
Een student aan de univertiseit van Berkley heeft een eigen "unix distributie" gemaakt, de Berkley Software Distribution, oftewel 1BSD, dat was in 1976.

Sindsdien heeft BSD ontwikkeling grotendeels losgestaan van Unix ontwikkeling, Unix is namenlijk niet gratis.

FreeBSD (en NetBSD) is gebaseerd op 386BSD, hetgeen is gebaseerd op 4.4BSD.

BSD is gebaseerd op Unix, maar natuurlijk geen Unix, net zoals met linux zijn er alijd mensen die gaan mierenneuken (Linux is geen OS, maar een kernel....)
Unix is, net zoals bv. pampers, inmiddels een verzamelnaam geworden.

Om dit virus te draaien moet je directe toegang tot de hardware hebben lijkt me, een hele berg besturingsystem laten dat standaard niet toe, en bij de rest kun je het instellen.

Klinkt allemaal weer als een hype....

[Verwijderd]

iedere processorfamilie zijn eigen variant op opcode spreekt

'Machinetaal' lijkt me een betere term dan 'opcode', opcode is immers geen taal.

...iedere processorfamilie zijn eigen (variant van) machinecode spreekt...

Een opcode is het deel van een instructie dat beschrijft wat er gedaan moet worden, de rest van de instructie bevat doorgaans data waar iets mee gedaan moet worden (bijvoorbeeld een adres of literal). Zoals je referentie in de Wikipedia ook aangeeft.

[eggieman]

Machinetaal is ook geen goede term.
Machinetaal bestaat uit opcode met 0 of meer operanden. Zo is:
10110000 01111011 machine code het betekent
MOV AL, 123 of te wel stop het getal 123 in register AL.
de opcode is 10110000 (mocht er iemand overvallen: ik vind het ook goed als je zegt day 10110 de opcode is en 000 verwijst naar register AL)

microcode zijn de stapjes die processor maakt van deze ene regel machinetaal. Voordeel van deze ministapjes zijn legio. Door kleinere stapjes kan de kloksnelheid omhoog, bijvoorbeeld. Chipbakkers die een x86 processor willen maken, zoals AMD en Intel ( en VIA ), proberen allemaal een processor te maken die met 10110000 01111011 het zelfde doet. De interne ministapjes kunnen heel anders zijn. Zo kun je
10110000 01111011 MOV AL, 123
10110100 01111011 MOV AH, 123
intern opvatten als 2 verschillende operaties met 1 operand ( 2 verschillende opcodes dus verschillende microcode) of als 1 functie met 2 operanden (dus een opcode korter dan 1 byte). Het eerste kost meer chipoppervlak, de tweede een verdere splitsing van de opcodes, dus meer druk op de prefetcher.
Intel en AMD zijn zeer voorzichtig in het naar buitenbrengen van info over de micro-ops. Een beter ontwerp van je micro-ops zorgt ervoor dat je processor harder wil lopen, zorgt ervoor dat micro-ops er op een efficientere manier gescheduled kunnen worden. En is dus een manier om je te onderscheiden van de ander.

[Verwijderd]

als ik 't dus goed begrijp is dit, indien niet snel opgelost, een gigantisch probleem...

maar dit virus slaat dus heel windows over en gaat direct met je hardware aan de slag? hoe moet ik me dat voorstellen (api? drivers?)

[FSVZ]

Een probleem daarbij is echter dat iedere processorfamilie zijn eigen variant op opcode spreekt om met de hardware te communiceren.

Dus het lijkt me dat een of andere zeer low-level 'taal' (machine-code) gebruikt zal worden. Mijn idee is dat de opcode vervalst wordt op een of andere manier. Maargoed, is maar een speculatie.

typo's

[miw]

Opcodes worden vaak niet direct door de hardware uitgevoerd, maar door zogenaamde microcode. In het aangehaalde artikel wordt dit onderscheid niet gemaakt, waardoor het tamelijk onduidelijk wordt. Kennelijk heeft men een virus ondekt dat microcode can aanpassen. De gewijzigde microcode is onzichtbaar voor de hogere niveau software (OS en andere executables).

[RedLizard]

Dat kan toch alleen vanuit ring 0 neem ik aan? Dan heb je dus sowieso root access nodig, en zie ik niet in wat hier zo bijzonder aan is. Ik kan ook wel een machine slopen als ik root access heb hoor, daar heb ik dit virus niet voor nodig.

[Verwijderd]

Zelfs root heeft geen ring 0 access. Alleen de core kernel heeft ring 0 access.

[masser120]

Mij lijkt de firmware dan logischer.
Dat kan je hardware dus mooi onbruikbaar maken

[_JGC_]

Als je als gebruiker met beperkte rechten werkt heeft dit virus geen kans, tenzij het via directX de hardware weet aan te spreken. Voor een beperkte gebruiker is DirectX de enige directe toegang naar hardware.

[s463042]

Dat wil niet zeggen dat je als gebruiker met beperkte rechten geen rechten hebt om onveilige opcodes te runnen. Daar wordt bij mijn weten niet op gecontroleerd.

[Verwijderd]

Als het virus eenmaal geactiveerd is, wat onder meer kan plaatsvinden door een besmette executable te starten,

*NIX werkt in tegenstelling tot windows niet met bestands extensies.Een programma moet je per definitie executable maken e.g: chmod +x <app>.
Dus als ineens om een of andere duistere reden om je root password gevraagt wordt zou dat toch een belletje moeten laten rinkelen of niet soms?

[6230lover]

Ik ben dan vooral benieuwd of dit dan ook gevolgen kan hebben op andere besturingssystemen. Zoals ik het hier lees maakt dat niet uit, of heb ik dit nou fout.

En waarschijnlijk zou dit dan ook het eerste virus voor macosx worden. Apple gebruikt dan wel intel hardware, maar dit virus kan je waarschijnlijk ook wel naar intel overzetten.

[s463042]

eerste virus voor macosx worden

Die (zie ook deze) was er al hoor.

[Verwijderd]

Heeft Mac OSX na 5 jaar nog maar 2 virussen?

En dan nog maar enkel proof of concepts?!!!

Switchen!!!!!

[PhoenixT]

De mac heeft al vaker virussen gehad hoor, al zijn het er niet heel veel.

[webfreakz.nl]

Leuk als zo'n ding ook nog eens verspreid gaat worden via de email en dan lekker je BIOS 'leeg flashen'. Internationale ramp.

[TD-er]

Dan is de verspreidingssnelheid afhankelijk van hoe lang mensen hun PC aan laten staan.
Na de reboot doet de PC het namelijk niet meer en kan dus het virus zich ook niet verder verspreiden.

Kortom ik denk niet dat ze heel erg vervelende dingen gaan doen, want dan verpreid het virus zich niet snel genoeg.

Maar goed, mocht je nog meer doom-scenario's willen...
- Password op de hdd controller zetten
- extra ruimte in diverse eeproms misbruiken om zich in te verbergen zodat je na een herinstall ineens weer besmet bent
- een virtuele machine starten die virussen of spam gaat versturen via het netwerk
- firmware van branders aanpassen (die gebruiken de meeste mensen niet dagelijks)
- spanningen van componenten aanpassen (CPU, geheugen etc) waardoor dingen na verloop van tijd doorfikken.
- keylogger installeren
- Boot-logo's aanpassen (hacked by... bladiebla)
- modems laten inbellen naar dure betaalnummers.

etc.

[JarnoD]

Kwestie van een "tijdbom". Eerst flink laten verspreiden en dan 120 dagen na tijdstip 0 allemaal tegelijk de BIOS leegflashen. Of een "BIOS leegflashdag" inbouwen zodat niemand meer kan booten op 14maart ofzo. Genoeg tijd om te verspreiden, genoeg mogelijkheid om schade aan te richten... Die truc is in de viruswereld al zo oud als de weg naar Kralingen.

[Verwijderd]

Oud nieuws.
Na het zogenaamde FDIV fiasco van intel heeft Intel er voor gekozen dat de microcode geupdated kan worden op de CPU.
Ik weet niet meer of dat sinds de Pentium || of Pentium /// is, maar in ieder geval weet ik dat er in de meeste linux distro's een service zit om de microcode te updaten met een bijgeleverde file.
Een paar jaar geleden was er nog zelfs een redelijk rel over, want het bleek vrij simpel te zijn om dus deze file met nieuwere microcode te "bewerken" zodat er onzin in kwam te staan.
Als je dan dus opnieuw opstartte werd de oude microcode overschreven en kon je de processor dus letterlijk weggooien want er was geen mogelijkheid meer om er nieuwe microcode in te krijgen.
Ondanks allerlei mooie praatjes van Intel was het met de P4 ook mogelijk.
Ik vraag me nu dus af of Intel daar nu weer van afgestapt is, en of dit ook mogelijk is met AMD.
Het is natuurlijk anders een koud kunstje een stukje software te schrijven wat onzin in de microcode rom van de processor schrijft.
Exit processor.
Magoed, ik vermoed dat het destijds ook met een proof of concept is gebleven omdat niemand zin had om het uit te testen.
Daar waren destijds de CPU's te duur voor.
Trouwens, transmeta heeft dus CPU's uitgebracht waar de komplete instructieset software matig geladen wordt.
Zo zou je met zo'n CPU ook bijvoorbeeld een PPC, MIPS of SPARC cpu kunnen emuleren.

[microchip]

Dit lijkt me heel sterk. Om de microcode in de processor aan te passen moet de processor op een soort CPLD (chip met programmeerbare logica) gebaseerd zijn. En voor zover ik weet, zit elk transistortje "hard" in het silicium gebakken.

[EnTT]

Zie bijvoorbeeld ook: http://kerneltrap.org/node/2678
Over het algemeen heb je als gebruiker niets te maken met deze microcodes en het updaten ervan, omdat een eventueel benodigde update al in het BIOS gebakken zit (zo vaak verschijnen die updates namelijk niet)

[stappel_]

de INTEL CPU heeft ook gewoon een stukje RAM/PROM in zich.
Daar komt dan een stukje microdecoder in te staan. Dit hebben ze gedaan naar de FDIV bug. Toen moesten ze nog alle CPU's vervangen. Nu kunnen ze gewoon een stukje software uitdelen aan iedereen en die fixed dan de bug in de CPU zelf.

(btw meestal doet de BIOS van je moederboard dit ook al met een BIOS update)

[d3vlin]

Het gaat dus feitelijk om een chip-level treat virus specifiek voor de opcode van AMD processoren, om van daaruit zeer lowlevel toegang te krijgen tot het systeem. Dat is dus niet heel anders dan het CIH/Chernobyl dat deed middels het flash-BIOS in 1998.

[TheCapK]

Je zou bijna Intel gaan verdenken van sponsoring van de schrijvers van dit virus!