Hoofdcategorieën

[RSS] Index » Nieuws » Core » Wetenschap » 'Intels HyperThreading vormt beveiligingsrisico' - update

'Intels HyperThreading vormt beveiligingsrisico' - update

Door Wouter Tinus, vrijdag 13 mei 2005 14:26
Bron: Deamonogy, views: 20.624

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.

HyperThreading zichtbaar in taskmanager

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

Volgende 17:12
Vorige 14:14

Categorieën

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 70 reacties zichtbaar700 Off-topic / Irrelevant: 67 reacties zichtbaar67+1 On-topic: 53 reacties zichtbaar53+2 Informatief: 23 reacties zichtbaar23+3 Must-read: 10 reacties zichtbaar10
«  1  2  »

Door bjorntje424, vrijdag 13 mei 2005 14:33

Score: 0
Volgens mij begin jij nu met die discussie,. door dat aan te halen ;)

Door halfgaar, zaterdag 14 mei 2005 12:33

Score: 1
Bij Dualcore kan dit denk ik niet. De ene CPU kan niet in geheugen dat door de andere CPU gebruikt wordt kijken volgens mij. Ook kunnen ze niet in registers van de andere CPU kijken.

Door jojarno, vrijdag 13 mei 2005 14:30

Score: 0
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.

Door TranceSetter, vrijdag 13 mei 2005 14:36

Score: 1
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. :'(

Door PuzzleSolver, vrijdag 13 mei 2005 15:38

Score: 1
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.

Door Chatslet, vrijdag 13 mei 2005 17:26

Score: 1
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.

Door Krisp, vrijdag 13 mei 2005 14:32

Score: 2
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.

Door justice strike, vrijdag 13 mei 2005 14:35

Score: 2
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.

Door n4m3l355, vrijdag 13 mei 2005 17:10

Score: 3
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.

Door Chatslet, vrijdag 13 mei 2005 17:30

Score: 0
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.

Door DataGhost, vrijdag 13 mei 2005 17:59

Score: 1
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 :)

Door bjorntje424, vrijdag 13 mei 2005 14:35

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

Door RuL0R, vrijdag 13 mei 2005 14:36

Score: 3
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.

Door garagaholic, vrijdag 13 mei 2005 14:37

Score: 3
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.

Door .oisyn, vrijdag 13 mei 2005 15:20

Score: 3
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).

Door PcDealer, vrijdag 13 mei 2005 14:38

Score: 2
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.

Door TD-er, vrijdag 13 mei 2005 14:52

Score: 3
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.

Door It_was_me, vrijdag 13 mei 2005 15:22

Score: 2
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...

Door TD-er, vrijdag 13 mei 2005 15:48

Score: 1
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.

Door crusty1507, zaterdag 14 mei 2005 03:43

Score: 1
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.

Door C0de Add!ct, vrijdag 13 mei 2005 14:33

Score: 1
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...

Door justice strike, vrijdag 13 mei 2005 14:37

Score: 3
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.

Door RuL0R, vrijdag 13 mei 2005 14:38

Score: 1
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.

Door Wolvie, vrijdag 13 mei 2005 15:03

Score: 0
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.

Door Sphere-, vrijdag 13 mei 2005 14:40

Score: 2
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.

Door JamesWest, vrijdag 13 mei 2005 14:50

Score: 3
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.

Door SED, vrijdag 13 mei 2005 15:58

Score: 1
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.

Door Countess, vrijdag 13 mei 2005 14:33

Score: 1
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.

Door RuL0R, vrijdag 13 mei 2005 14:41

Score: 2
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.

Door JamesWest, vrijdag 13 mei 2005 14:55

Score: 1
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

Door Willson, vrijdag 13 mei 2005 14:33

Score: 0
En is dit bij alle OS'en >??

Door Cmdr Chakotay, vrijdag 13 mei 2005 14:34

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

Door justice strike, vrijdag 13 mei 2005 14:41

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

Door Luuk1983, vrijdag 13 mei 2005 14:36

Score: 0
Ik denk toch dat er een verschil tussen zit omdat hyperthreading != 2 cores is, ook voor windows XP. Maar ja, ik denk dat je alles wel kan misbruiken. Het ene is alleen moeilijker dan het andere. Dit vind ik hetzelfde als je fiets op 50 sloten zetten: het helpt zeker tegen diefstal, maar als ze persé willen nemen ze de fiets toch wel mee. Dus om meteen HT uit te schakelen lijkt me een klein beetje overdreven. Als ze ECHT achter gevoelige gegevens willen komen lukt het uiteindelijk waarschijnlijk toch wel.

Door justice strike, vrijdag 13 mei 2005 14:40

Score: 1
met die redenering kun je net zo goed de deur van je auto niet op slot zetten, want "als ze echt willen dan stelen ze hem toch wel"

Door It_was_me, vrijdag 13 mei 2005 15:36

Score: 1
Luuk1983 hangt z'n WinNT machine zonder servicepacks, virusscanner of Firewall aan het Internet...

Door still_the_same, vrijdag 13 mei 2005 14:40

Score: 3
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.

Door RwD, vrijdag 13 mei 2005 14:41

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

Door 4VAlien, vrijdag 13 mei 2005 14:45

Score: 1
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.

Door still_the_same, vrijdag 13 mei 2005 14:56

Score: 2
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.

Door kidde, vrijdag 13 mei 2005 14:45

Score: 1
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.

Door JamesWest, vrijdag 13 mei 2005 14:58

Score: 2
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/

Door aToMac, vrijdag 13 mei 2005 15:43

Score: 1
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.

Door still_the_same, vrijdag 13 mei 2005 15:00

Score: 1
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.

Door it0, vrijdag 13 mei 2005 14:46

Score: 1
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.

Door thekip, vrijdag 13 mei 2005 14:46

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

Door CIS187, vrijdag 13 mei 2005 14:48

Score: 3
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.

Door erikdenv, vrijdag 13 mei 2005 15:29

Score: 1
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.

Door Wouter Tinus, vrijdag 13 mei 2005 15:37

Score: 1
Wie zegt dat het een hardwareprobleem is?

Door s463042, vrijdag 13 mei 2005 14:42

Score: 3
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?

Door Countess, vrijdag 13 mei 2005 14:47

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

Door TD-er, vrijdag 13 mei 2005 15:00

Score: 2
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.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 17:12
Vorige 14:14
VNU Media logo Hosted by True

© 1998 - 2009 Tweakers.net - Alle rechten voorbehouden - Uw Privacy - Algemene Voorwaarden

Uitgever van: