'Intels HyperThreading vormt beveiligingsrisico' - update

Onafhankelijk onderzoeker Colin Percival heeft ontdekt dat het gebruik van HyperThreading-technologie op Intels Pentium- en Xeon-processors een beveiligingsrisico kan vormen. Met name serverbeheerders worden door hem aangeraden om de technologie onmiddellijk uit te schakelen. De complete technische details - inclusief de voorbeeldcode om aan te tonen dat HyperThreading inderdaad misbruikt kan worden - zullen later vandaag gepresenteerd worden op een conferentie voor BSD-ontwikkelaars. Mensen van FreeBSD, NetBSD en SCO Unix hebben op dit moment echter al bevestigd dat het probleem echt bestaat, en laten weten dat ze er binnenkort waarschuwingen over gaan rondsturen aan hun klanten. Makers van andere besturingssystemen hebben nog niet gereageerd.

Hoewel er op dit moment nog geen details zijn, lijkt de aard van het probleem te liggen in de scheiding tussen de twee gelijktijdig draaiende threads. Op een of andere manier zou de ene thread er achter kunnen komen waar de andere thread op dat moment mee bezig is, en op die manier kunnen volgens de ontdekker (gevoelige) gegevens zoals encryptiesleutels uit een thread ontfutseld worden, terwijl deze normaal door het operating systeem ontoegankelijk zouden worden gehouden. Met name voor systemen waarop meerdere gebruikers tegelijk werken vormt dat een risico. Het gaat volgens het beveiligingsteam van NetBSD om een complex probleem waar veel discussie over nodig zal zijn om met een goede oplossing te komen. Wel gelooft de organisatie dat er voor het grootste deel van de gebruikers adequate tijdelijke oplossingen zijn te bedenken.

Update: Inmiddels zijn de technische details bekendgemaakt, deze worden hier op Tweakers.net besproken.

Reacties (70)

[Krisp]

Dit zou dan ook betekenen dat dual core processors gevaar opleveren, omdat bij dat soort processoren ook 2 processen tegelijkertijd worden gedraaid. En evenzogoed bij dual processor systemen.

[garagaholic]

Niet perse, aangezien dat om totaal verschillende (hardwarematige) technieken draait. Hyperthreading is een logische 'simulatie' van een tweede core/processor, hier wordt dus softwarematig geregeld. Dualcore en dualprocessor systemen hebben twee fysieke cores, waardoor dit 'trucje' wellicht niet werkt.

[.oisyn]

Hyperthreading is geen software-iets. Het is effectief hetzelfde als een 2e core op dezelfde CPU, met het belangrijke verschil dat bij hyperthreading resources worden geshared. Er bestaan echter wel degelijk 2 verschillende contexts waar beide threads in draaien, en naar de buitenwereld toe wordt het ook gerapporteerd als een 2e cpu (afgezien van het feit dat natuurlijk wel degelijk queryable is of hyperthreading ondersteund wordt).

[Verwijderd]

Dit zou dan ook betekenen dat dual core processors gevaar opleveren, omdat bij dat soort processoren ook 2 processen tegelijkertijd worden gedraaid. En evenzogoed bij dual processor systemen.

Misschien zit het probleem niet in het draaien van meerdere processen maar in de manier waarop HTT dit doet.

Als je hetzelfde probleem bij meerdere processoren ook zou hebben zou het probleem al eerder ontdekt zijn (waarschijnlijk) en zou het ook nog worden aangeraden om de tweede cpu uit je systeem te trekken.

[PcDealer]

Ik denk dat omdat het hier om fysieke cores gaat, dit verhaal niet uitkomt en bovendien alleen in "multi-user environment".

Betekent dat meerdere gelijktijdige users ingelogd (disconnected), of alleen connected users?

Helaas is de website nog niet helemaal in detail getreden, dus blijft koffiedik kijken voor beide alinea's.

[TD-er]

Als je een klein beetje thuis bent in de materie is het niet zo moeilijk om in te zien waar het gevaar zit.
In een niet-multi-user omgeving kan die ene gebruiker al alle processen zien, bedienen etc. dus zijn er voor den kwaadwillenden gebruiker al mogelijkheden genoeg om erachter te komen wat er op de machine draait.
Op multiuser systemen gaat het dus om processen van verschillende gebruikers waarbij de ene gebruiker erachter wil komen wat de andere gebruiker doet.
Als het goed is zou dit dus door het OS afgeschermd moeten worden, maar in deze situatie is het blijkbaar mogelijk om in de processor met een 2e thread registers uit te lezen van de 1e thread.
Voor het OS zijn het 2 verschillende threads die op een verschillende CPU draaien en zou dit dus niet mogelijk moeten zijn, maar ze draaien op de zelfde core.

De kwaadwillende gebruiker hoeft dus niet ingelogged te zijn op het systeem, maar moet wel een eigen proces draaien wat die kwaadwillende thread dus start (denk aan een nohup of een cronjob)

Het lijkt mij nog steeds vrij lastig om die threads zo te schedulen dat je de juiste data uit de registers weet te halen, dus een echt groot gevaar zal het nog niet zijn, maar dat is een ander verhaal.

[It_was_me]

Waarom nu juist die data eruit proberen die je wilt hebben. Lijkt me dan handiger het proces constant te laten draaien, en achteraf te kijken wat je allemaal gevangen hebt...

[Verwijderd]

Lijkt me dan dus ook voor de hand liggen dat dit niet het probleem is: Het nieuwsitem spreekt immers van een reeel risico.

Ik denk idd ook dat het probleem ligt bij het spieken van 1 thread bij de andere, maar de details zijn me volkomen onduidelijk.

[TD-er]

Dan moet je wel weten wat je gevangen hebt, oftewel je moet dan ook loggen welke thread er draaide op het moment dat je die registers zat te lezen.
Het loggen van alle data gaat opvallen, want er gaat enorm veel data per sec door die registers.

[justice strike]

dual core en dual proc hebben dit probleem niet omdat de threads op fysiek andere cores draaien, het is voor een thread ook "onmogelijk" om bij gegevens van een andere thread te komen op deze manier.

het vervelende van hyperthreading is dat het op dezelfde core werkt en dus ook acces geeft tot alle resources van die core (althans ik denk dat daar het euvel ligt) en als er dan nog een andere thread op dezelfde core draait heb je dus ook acces tot die gegevens.

[n4m3l355]

het euvel zit niet in het shared resources maar daar waar de deling van de processes plaats vindt. er staan hier
http://www.intel.com/design/Pentium4/documentation.htm
bij mijn weten ergens schema's over hoe de daadwerkelijke scheiding plaats vindt en waar. afhankelijk van waar dit gebeurd is dit een gevaar echter ik denk dat ook voor multicore systemen dit een gevaar is die plaats kan vinden aangezien men de scheidingssysteem misbruikt. ik denk dat het dan ook interessant is om te weten waarom het bij specifiek dit geval voorkomt en bv niet multi processor systemen voorkomt.

[Chatslet]

Ja en nee....
Ik kan me herinneren dat er laatst een nieuwspost was waarin stond aan gegeven dat de dual core processoren van AMD een hyperthreading bit hadden om zo hyperthreading te kunnen emuleren op de 2 losse cores. Ik kan me goed voorstellen dat deze exploit daardoor ook op deze processoren zal gaan werken.

@dataghost: daar ben ik me van bewust ja. Is een dergelijke exploit dan geen software die van hyperthreading gebruikt maakt? Het is dus afwachten hoe volledig hyperthreading word ge emuleerd door AMD.

[DataGhost]

dat is om ervoor te zorgen dat software die van hyperthreading gebruik maakt ook gebruik maakt van de 2 cores die AMD in de cpu's stopt

[Verwijderd]

Hyperthreading is niet hetzelfde als multithreading systeem, anders zou dit ook voorkomen bij dual-setups.

[still_the_same]

Best handig dat vanmiddag de voorbeeldcode komt.. Kan iedereen beginnen met het schrijven van kwaadaardige code. Zou het niet handiger zijn om eea stil te houden tot de oplossing gevonden is? Of in iedergeval iets langer wachten met het vrijgeven van de voorbeeld code, zodat iedereen die het uit moet zetten ruim de tijd heeft om het uit te zetten.

[Verwijderd]

Stilhouden??

als je even op zijn website gaat kijken zie je dat hij er reeds in oktober 2004 achter gekomen is en sindsdien overleg pleegde met de betrokken partijen

zowel intel + OS makers.

en da thij vandaag aan de OSmakers een demonstratie gaat geven en tegelijk een paper gaat releasen op zijn website.

[erikdenv]

Als het al zolang speelt dan zou je toch verwachten dat Intel er inmiddels iets aan gedaan heeft, voor de nieuwe processoren dan uiteraard.

@Wouter Tinus
Dat is idd. nog niet vastgesteld. Ik zie Windows ook niet in het lijstje van slachtoffers staan. Zou een apart iets zijn, een algemene vulnerability en Microsoft ontsnapt eraan. Ben benieuwd naar het vervolg hiervan.

[Wouter Tinus]

Wie zegt dat het een hardwareprobleem is?

[Verwijderd]

Het voor zich houden van de voorbeeldcode zal er alleen maar voor zorgen dat het langer duurt voor er een oplossing is.

[kidde]

Dat is niet de strategie van NetBSD / FreeBSD.
Meer van andere niet nader te noemen OS'en.
Door het vrijgeven zal er in ieder geval meer vaart achter de oplossingen gezet worden.
BSD-ontwikkelaars richten zich namelijk doorgaans niet zo heel erg op klanttevredenheid (zoals Linux-dstro's dat wel weer doen), maar meer op onderzoek, en het verbeteren van dingen. Men hoeft niet echt gebruikers tevreden te houden (in ieder geval minder hoge prioriteit dan bij andere OS'en), dus komt men er gewoon mee.

[Verwijderd]

idd. en de linux community kan een andere kernel gaan gebruiken. Redelijk snel te implementeren. Tevens zorgvuldig met je netwerk toegang omgaan.. een aanrader:
http://www.oreilly.com/catalog/swarrior/

[Verwijderd]

Je gaat wel een beetje kort door de bocht met een andere kernel gebruiken. Ook al is het redelijk simpel te implementeren, ga je dit niet zomaar doen bij al je servers die 24/7 in de lucht moeten zijn. Stel dat het mis gaat, dan loop je veel meer schade op dan het eerst helemaal doortesten, en nog een keer testen. Als alles naar alle waarschijnlijkheid blijft werken, dan kun je gaan veranderen.

Het risico om gehacked te worden is m.i. een behoorlijk stuk kleiner dan dat er iets misgaat met even een kernel wijziging door te voeren.

[still_the_same]

Dus zorgen zij er dan onbedoeld "?" voor dat de hele wereld een probleem heeft.. Ze hadden er ook voor kunnen kiezen met Intel, virusscan leveranciers en os distributeurs te gaan overleggen en het pas de code bekend maken als het probleem opgelost is.

[4VAlien]

D'r is toch een makkelijke workaround, namelijk HT disablen in de BIOS of OS? Veel makkelijker kan een patch niet zijn. Dat je dan je HT mogelijkheid niet kan benutten is dan jammer, maar als je het een issue hebt dan heb je het er wel voor over lijkt me.

@still_the_same

Als er een software patch uitkomt en het zijn veel kritische systemen dan is het upgraden niet ineens wel makkelijk, dus je argument snijdt niet echt hout imho.

[still_the_same]

Even HT uitzetten.... Laten we hopen dat er geen bedrijven zijn die honderden servers hebben met die processors er in (die dan waarschijnlijk 24X7 up moeten zijn..)

@4VAlien
Meeste bedrijven gebruiken volgens mij centrale patch systemen, welke na goed testen uitgerold kunnen worden, maar dat neemt niet, dat zoals ik in mijn eerste post zij, ze best even kunnen wachten met het vrijgeven van de voorbeeld code.

[RwD]

Ach, misschien wel. Maar nu is het probleem wel sneller wereldkundig. Een beetje als de klopsleutel...

[it0]

Dit is inderdaad een vrij veel voorkomende gedachtengang.
En het standaard tegenargument is of je wilt weten of er een probleem is en wat het probleem is, Of wil je dat alleen de auteur van de soft/hardware en alle hackers het probleem weten.

Als jij het weet kan je er tenminste iets aan doen, zoals hier HT uitzetten.

[s463042]

In de security advisory van FreeBSD staat ook dit:

Use of this workaround is not recommended on "dual-core" systems, as this workaround will also disable one of the processor cores.

Het is dus niet mogelijk om hyperthreading te disablen op een dual core pentium/xeon?

[TD-er]

Met de genoemde patch is dat niet handig nee. Waarschijnlijk schakelt die patch de multi-processor-mogelijkheden van de kernel uit.
Voor het OS (de kernel dus) is een hyperthreading-CPU zichtbaar als 2 losse CPU's.
Het zou een oplossing zijn om hetzelfde in de kernel uit te voeren als wat je BIOS doet wanneer je de hyperthreading uitzet, maar ik vraag me af of dat mogelijk is wanneer de machine al geboot is. Zou namelijk wel een behoorlijk risico zijn wanneer je die mode buiten de BIOS om zou kunnen aanpassen.
Als je een goede kernel hebt zou geen enkel niet-kernel-proces naar de hardware mogen schrijven, dus een direct gevaar zal het niet zijn, maar toch is het IMHO link als je dat buiten de BIOS om zou kunnen aanpassen.

[Countess]

ik denk eigenlijk dat ze in freeBSD de hypertreading in de kernel bedoelen.
maar ik kan het mis hebben.

[c0deaddict]

Voor de meeste servers zal dit ook geen probleem zijn. Want om een "lek" zoals dit te kunnen benutten moet je als gebruiker/hacker programma's kunnen uitvoeren... Dus zo een ernstig lek is het nou ook alweer niet

@ RuL0R
Oke, het is mss toch wat serieuzer dan ik eerst d8. Maar wat is nu de kans dat je 'hack' thread tegelijk wordt uitgevoerd met een thread die bijvoorbeeld iets aan het encrypten is op bijvoorbeeld een Terminal Server ?
En als ik het goed gelezen heb kan je alleen data _uitlezen_ van een andere thread, dus niet data wijzigen. Dus wat dat betreft is dit een veel minder ernstig lek dan bijv. een buffer overflow...

[justice strike]

meeste lekken zijn van dien aard dat je door lekken programma's kunt uitvoeren op een server. Dus dat dit dus minder erg is omdat je een programma moet draaien is een beetje kort door de bocht.

en een veel groter probleem is zelfs terminal services. waar programma's op servers gedraait worden. Dat maakt dit probleem des de ernstiger.

[Sphere-]

Zelf bied ik shellhosting aan (mensen kunnen programma's uitvoeren op de server) en dat op een server waar ook gewone webhosting klanten op zitten. Helaas is dit voor ons dus wel een groot risico. Ik hoop dan ook op een softwarematige oplossing (als dat al eens mogelijk is). Even naar het datacenter rennen en HT uitzetten zit er voor ons niet in ivm de afstand naar het datacenter.

[Verwijderd]

Dan denk ik dat je idd een probleem hebt. Alhoewel dat je niet noodzakelijk naar de datacenter hoeft te lopen, je hebt immers shell access dus..als je linux draait zou je kunnen overwegen om de kernel te vervangen met eentje die geen hyperthreading ondersteunt.

Maybe dat je hier:

http://kerneltrap.org/node/2714

wat help kan vinden.

[SED]

dan ga je met de auto

Maar jouw probleem zit waarschijnlijk eerder in het feit dat de productiviteit van je server volledig in elkaar dondert als je HT uit zet.
Dat lijkt me meer iets om je druk over te maken.

[Verwijderd]

Voor de meeste servers zal dit ook geen probleem zijn. Want om een "lek" zoals dit te kunnen benutten moet je als gebruiker/hacker programma's kunnen uitvoeren... Dus zo een ernstig lek is het nou ook alweer niet

Nooit van buffer overflows gehoord ofzo?

Je eigen code op een andere bak laten draaien gaat nog wel, het moeilijkste deel hier lijkt me om de gegevens die je wilt hebben uit de andere thread te trekken.

[Verwijderd]

Jawel hoor.
Maar als iemand van deze "bug" gebruik kan maken, dan moet je de beheerder TERPLEKKE ontslaan, want dan kan er iemand bij zijn servers die er niet hoort.

[SKiLLa]

Volgens mij is dit gewoon een design-feature waarop OSes (nog) niet zijn voorbereid. Je kan met een single, non-HT CPU toch ook gewoon een process debuggen (en dus private memory ervan lezen) of een API-function afvangen (semi-simultaan) ?

Een OS zou een proces met non-root rechten niet de mogelijkheid moeten bieden om 'priviliged code' en/of APIs te gebruiken en zodanig directe toegang tot bv. geheugen of de speciale CPU / chipset registers moeten ontzeggen.

Om de 'HT-bug' hardware-matig te fixen moet HT gewoon opnieuw geimplementeerd gaan worden (ander design) als minder krachtige hulp-thread-core met een beperkte instructie-set en access-level.

[Verwijderd]

Exact mijn idee. Het lijkt me heel onwarschijnlijk dat het een hardware probleem is... Volgens mij zit het eerder in het feit dat een OS niet correct genoeg met die technologie omgaat...

[familyman]

Als een OS het doet is het toch ook weer via virusachtige dingen te omzeilen? Zoals ik het hier lees is er toch al een niet-standaard programma nodig. Mij lijkt het dat voor makers van dergelijke programma het OS omzeilen ook niet zo'n punt zal lijken. (zelfs al zit het heel diep in het OS)

[sphere]

http://www.daemonology.net/hyperthreading-considered-harmful/
http://www.daemonology.net/papers/htt.pdf

[Countess]

het is wel een "lek" wat alleen uit te buiten is als je zelf iets kunt draaien op de server in questie dus.
het is dus niet zo dat iedere intel gebazeerde webserver op internet ineens kwetsbaar is en zondermeer gehacked kan worden. en als je iets draaied moet op dat moment de andere thread op die cpu maar net iets aan het doen zijn waar jij iets aan hebt.
maar toch, het kan toch voor een hoop problemen zorgen.

[Verwijderd]

het is wel een "lek" wat alleen uit te buiten is als je zelf iets kunt draaien op de server in questie dus.

Dat lukt ook wel als er ergens weer een ander lekje in de software is, dmv. een buffer overflow bijvoorbeeld of gewoon met social engineering.

het is dus niet zo dat iedere webserver op internet ineens kwetsbaar is.

Inderdaad, alleen degene die HTT enabled hebben zijn hier kwetsbaar voor.

[Verwijderd]

alleen webservers met shell accounts..

en effe voor diegene die een bakkie op het net hebben hangen, doe jezelf een grote lol en ga nu je bak dichttimmeren.. gebruik tcpwrappers.. hierzo alvast some quick and dirty:

http://www.itc.virginia.edu/unixsys/sec/hosts.html

[Willson]

En is dit bij alle OS'en >??

[Pimmeh]

Ja natuurlijk. Het gaat om de processor, dus onafhankelijk van je OS.

[justice strike]

voorlopig wel, maar dat wil niet zeggen dat er geen workaround gevonden kan worden.

[Verwijderd]

mmmm
Is dit weer een PR-stunt? (of een anti-PR-stunt, je mag zelf kiezen).

"Je zou een thread kunnen draaien die kan uitzoeken waar een andere thread draait en zo gevoelige informatie achterhalen."

Ben ik de enige die dit klinkklare onzin vindt? Hoe kun je ten eerste een thread lanceren op een server om op zoek te gaan naar een andere thread waar gevoelige gegevens inzitten???
Volgens mij worden accountgegevens nog steeds opgeslagen in files, of in een LDAP-server.
Dit zijn statische gegevens, wordt niet echt iets met gedaan, enkel bij bijvoorbeeld het inloggen worden deze geraadpleegd om al dan niet toegang te geven.

Gevoelige informatie halen uit een thread..... Jonges, leer eerst eens de omschrijving van al deze begrippen. Gevoelige gegevens worden niet meegegeven in threads...

Klinkklare onzin dus volgens mij...

En als het toch zo'n probleem is, waarom komen ze er dan nu pas met op de proppen? Dat zou dus willen zeggen dat al die tijd dat al die servers die draaien op Intel met HT al die tijd kwetsbaar waren voor dit 'beveiligingslek'?

[Wouter Tinus]

Gevoelige informatie halen uit een thread..... Jonges, leer eerst eens de omschrijving van al deze begrippen. Gevoelige gegevens worden niet meegegeven in threads..

Alle gevoelige gegevens komen vroeg of laat wel een keer door de processor heen, dus ook accountgegevens. Hoe wil je anders ooit kunnen inloggen? Een harde schijf kan echt niet een ingevoerd wachtwoord met het opgeslagen wachtwoord vergelijken, dat doet de processor. De moeilijkheid is alleen de juiste timing, want je kunt geen tientallen gigabytes per seconde gaan lezen, laat staan opslaan. Voor inloggen is die waarschijnlijk te moeilijk, maar encryptie is toch een vrij makkelijk te herkennen rekenpatroon waarop gereageerd kan worden. Als je iemands (private) key niet gevoelig wil noemen dan weet ik het ook niet meer.

[TD-er]

"Je zou een thread kunnen draaien die kan uitzoeken waar een andere thread draait en zo gevoelige informatie achterhalen."

Ben ik de enige die dit klinkklare onzin vindt? Hoe kun je ten eerste een thread lanceren op een server om op zoek te gaan naar een andere thread waar gevoelige gegevens inzitten???

Waarschijnlijk niet de enige, maar het is dus geen onzin.
Het probleem is dus dat je als user X de gegevens van user Y kunt inlezen, terwijl deze door de processor verwerkt worden.
Als het goed is kun je niet de files van user Y lezen, omdat je OS dat afschermt. Tot nu toe werd het echter onmogelijk geacht om de registers van de andere CPU in een systeem uit te lezen en dus is daar verder geen beveiliging op gezet. Nu blijkt dat dat wel mogelijk is en moeten er dus maatregelen genomen worden. Waarschijnlijk in de kernel van het OS.

Volgens mij worden accountgegevens nog steeds opgeslagen in files, of in een LDAP-server.
Dit zijn statische gegevens, wordt niet echt iets met gedaan, enkel bij bijvoorbeeld het inloggen worden deze geraadpleegd om al dan niet toegang te geven.

Het heeft dus niets met bestanden op het filesysteem te maken, maar met de variabelen die jouw proces gebruikt op de processor.
Het vereist wel erg veel inzicht in de opbouw van het proces wat je wilt bespioneren, omdat je anders niet weet wat de gevonden waardes voorstellen, maar het is dus mogelijk.

Gevoelige informatie halen uit een thread..... Jonges, leer eerst eens de omschrijving van al deze begrippen. Gevoelige gegevens worden niet meegegeven in threads...

Klinkklare onzin dus volgens mij...

Waarom wordt gevoelige informatie niet meegegeven aan de thread die op de processor draait? Hoe wil je dan je data versleutelen als je de gebruikte sleutel niet in de registers van de processor hebt staan?

En als het toch zo'n probleem is, waarom komen ze er dan nu pas met op de proppen? Dat zou dus willen zeggen dat al die tijd dat al die servers die draaien op Intel met HT al die tijd kwetsbaar waren voor dit 'beveiligingslek'?

Waarom worden producten soms ineens uit de winkels gehaald? omdat ze er pas na productie en verspreiding achter kwamen dat er iets mee mis is.
Dus zolang een lek nog niet ontdekt is, is er nog geen kans op misbruik geweest, maar dat is met elk lek zo.

[MBV]

Als je het bestand uitleest om er wat mee te doen, waar gaan de gegevens dan naartoe? In alle gevallen een register op de processor. En die kan je dan weer uitlezen met een andere thread.

Ik zie mogelijkheden: een extreme debugger maken, runnen op een server waar dat mag, en alle gegevens uitlezen die langskomen als je een query uitvoert. Wedden dat je het MySQL wachtwoord ziet?

[Verwijderd]

matig, maar ik denk eigenlijk niet dat veel eigenaars hun hypert hreading van servers uit zullen zetten, vooral bij drukke servers kan dat toch tot aardig wat prestatie verlies lijden.
zowiezo vraag ik me toch af in hoeverre dit een bedreigend risico is.
natuurlijk moet je wel uitkijken maar ik denk wel dat het meevalt.

[TranceSetter]

servereheerders willen juist dat alles zo veilig mogelijk is. Het is hun werk. Als dit zoals gezegd een echt groot veiligheidsprobleem is/wordt, dan zullen de beheerders toch liever HyperThreading uitzetten. Liever ten koste van snelheid als van veiligheid. Een beetje bedrijf kan zich echt niet veroorloven om sleutels die toegang tot bedrijfsdocumenten geven te 'lekken'

Ik vind het wel raar, aangezien Intel al jaren HyperThreading gebruikt en ze er nu pas achter komen. En als dit een groot veiligheidsrisico is, dan heeft niemand dus meer wat aan de HT technologie.

[PuzzleSolver]

Als het probleem is dat de ene thread de andere kan "afluisteren" dan is het is dus alleen een risico als er applicaties van derden op de computer draaien.

Virussen en spyware applicaties zouden hier gebruik van kunnen maken om bellangrijke data af te luisteren. En zoals hier boven al gemeld wordt als er meerdere gebruikers op werken zou een gebruiker op dat systeem een programma kunnen starten die gegevens (zoals passwords) van andere gebruikers probeert te krijgen.

Feit is er moeten wel eerst exploits geschreven worden voordat het risico echt groot is. Maar mischien zijn deze al geschreven en anders worden ze nu na dit artikel wel geschreven.

[Chatslet]

Je zou bijvoorbeeld aan een webserver kunnen denken waar iemand een leuk cgi/bin scriptje op gaat draaien. Reken maar dat je dan rellen hebt.