Windows, FreeBSD en Xen hadden zes jaar oud beveiligingsprobleem
Windows 7, de Xen-hypervisor en verschillende BSD-varianten waren kwetsbaar voor een bug die al sinds 2006 bekend is. Dat heeft een Poolse onderzoeker ontdekt. Het gaat om een foutieve implementatie van een Intel-cpu-instructie.
Beveiligingsonderzoeker Rafal Wojtczuk ontdekte eerder dit jaar dat een bug die al sinds 2006 bekend was en destijds in Linux ook was gepatcht, nog steeds aanwezig was in 64bit-versies van Windows 7, Windows Server 2008 R2, FreeBSD, NetBSD en de Xen-hypervisor. Of eerdere Windows-versies ook kwetsbaar waren, is onduidelijk.
Inmiddels is de bug voor alle besturingssystemen en Xen gepatcht, zegt Wojtczuk in een interview met Tweakers.net op de Black Hat-beveiligingsconferentie, waar hij zijn bevindingen presenteerde. Er werd actie ondernomen nadat Wojtczuk zijn bevindingen bij de betreffende bedrijven en organisaties meldde.
Het gaat om een zogenoemde privilege escalation bug, waarbij een aanvaller met toegang tot een systeem zijn rechten weet op te hogen. De fout zat hem in dit geval in de manier waarop besturingssystemen omgingen met een instructie in 64bit-Intel-cpu's. Volgens Intel gaat het niet om een bug in de x64-instructieset, maar om een foute implementatie van de instructie in besturingssystemen.
Het is de vraag waarom het patchen van de bug in veel gevallen zes jaar heeft geduurd; Wojtczuk kan daarover enkel speculeren. "Ik denk dat het komt doordat 64bit-cpu's zes jaar geleden gewoon nog niet in gebruik waren", aldus Wojtczuk. "Het is gewoon niet opgemerkt."
Hoewel de bug op zichzelf niet genoeg is om op afstand toegang te krijgen tot een systeem, was het een risico voor desktops en servers waar veel mensen gebruik van maken. Virtuele hostingproviders hadden er met name last van kunnen hebben, omdat één gebruiker zijn toegang op gebruikersniveau had kunnen 'opwaarderen' tot toegang als root.
Omdat de veelgebruikte Xen-hypervisor kwetsbaar was, had het ook gevolgen voor aanbieders van virtuele servers: aanvallers zouden uit een virtuele server kunnen 'breken' en toegang krijgen tot de onderliggende server van de provider. Overigens was Xen alleen kwetsbaar als hij in een bepaalde modus draaide, genaamd de paravirtualisatiemodus.
Reacties (64)
FreeBSD ? Dus Mac OSX ook ?
Nee. Maar Mac OSX is zelf al heel buggy met veel security flaws
Ter verdediging van Mussie's standpunt:
http://www.security.nl/artikel/41273/Kaspersky%3A_Apple_loopt_10_jaar_achter_op_Microsoft.html
http://www.security.nl/artikel/41273/Kaspersky%3A_Apple_loopt_10_jaar_achter_op_Microsoft.html
Allicht zal Kaspersky dat zeggen.
Maar als je het artikel leest, gaat het puur om hoe Apple om zou moeten gaan met patchcycli. Dat Mac OS X een al veel veiliger basis heeft (Darwin) dan Microsoft wordt gemakshalve even buiten beschouwing gelaten.
Maar als je het artikel leest, gaat het puur om hoe Apple om zou moeten gaan met patchcycli. Dat Mac OS X een al veel veiliger basis heeft (Darwin) dan Microsoft wordt gemakshalve even buiten beschouwing gelaten.
Tuurlijk, het is Kaspersky. Die lult ook dat Android zo onveilig is. Maar ondertussen worden mensen wel bang en kopen ze extra anti-virus software(van Kaspersky!).
Ja MS heeft met 2 miljoen gevallen van malware elk jaar veel meer ervaring dan Apple met 1 geval. Dat is wat ze ongeveer zeggen. Dit soort FUD wordt door MS de wereld in gebracht. Ze halen Kaspersky over om zoiets de wereld in te brengen (Hoe? Kan op allerlei manieren, voorrechten bieden, geld bedrag, samenwerking etc). Voor Kaspersky zit er een eigen belang in om Apple als onveilig voor te stellen dat zodat mensen hun virusdweil kopen.
Wil je weten hoe MS te werk gaat met FUD? Download hun eigen interne memo's hier. Dit soort dingen zijn naar buiten gekomen bij de vele rechtzaken die tegen MS zijn aangespannen.
“Working behind the scenes to orchestrate “independent” praise of our technology, and damnation of the enemy’s, is a key evangelism function during the Slog. “Independent” analyst’s report should be issued, praising your technology and damning the competitors (or ignoring them). “Independent” consultants should write columns and articles, give conference presentations and moderate stacked panels, all on our behalf (and setting them up as experts in the new technology, available for just $200/hour). “Independent” academic sources should be cultivated and quoted (and research money granted). “Independent” courseware providers should start profiting from their early involvement in our technology. Every possible source of leverage should be sought and turned to our advantage.”
Wil je weten hoe MS te werk gaat met FUD? Download hun eigen interne memo's hier. Dit soort dingen zijn naar buiten gekomen bij de vele rechtzaken die tegen MS zijn aangespannen.
“Working behind the scenes to orchestrate “independent” praise of our technology, and damnation of the enemy’s, is a key evangelism function during the Slog. “Independent” analyst’s report should be issued, praising your technology and damning the competitors (or ignoring them). “Independent” consultants should write columns and articles, give conference presentations and moderate stacked panels, all on our behalf (and setting them up as experts in the new technology, available for just $200/hour). “Independent” academic sources should be cultivated and quoted (and research money granted). “Independent” courseware providers should start profiting from their early involvement in our technology. Every possible source of leverage should be sought and turned to our advantage.”
Magalaan, Kaspersky is een Russisch bedrijf. Hetzelfde bedrijf dat Stuxnet heeft ontdekt. Kaspersky heeft geen belang om samen te zweren met Microsoft. Maar alu-hoedjes zien overal samenzweringen.
De aangehaalde tekst is uit 2000. Microsoft is veranderd sindsdien. Natuurlijk blijft het een commercieel bedrijf dat winst wil maken maar alsik kijk hoe ze de laatste 5 jaar opereren denk ik dat er veel verbeterd is.
De aangehaalde tekst is uit 2000. Microsoft is veranderd sindsdien. Natuurlijk blijft het een commercieel bedrijf dat winst wil maken maar alsik kijk hoe ze de laatste 5 jaar opereren denk ik dat er veel verbeterd is.
[Reactie gewijzigd door Xenan op 27 juli 2012 16:32]
Verbeterd weet ik niet. Men doet dit in ieder geval niet zo duidelijk meer (logisch: als iedereen weet dat dit je strategie is, werkt het niet meer).
Samenzweren? Dan lees je de verkeerde boeken. De wereld wordt echt niet geregeerd door de iluminatie hoor.Magalaan, Kaspersky is een Russisch bedrijf. Hetzelfde bedrijf dat Stuxnet heeft ontdekt. Kaspersky heeft geen belang om samen te zweren met Microsoft. Maar alu-hoedjes zien overal samenzweringen.
In het bedrijfsleven noemen we dat geen samenzweren, maar samenwerken. Bedrijven maken deals die voor beiden lucratief zijn. voor MS is het lucratief dat IOS als onveiliger wordt voorgesteld dan Windows, en voor Karperski is het lucratief dat Apple gebruikers gaan denken dat ze antivirus producten nodig hebben.
Alleen is het hier een zo apert onjuiste voorstelling van zaken dat Kasperski hier zijn eigen geloofwaardigheid op het spel zet. Daarom en het feit dat ze zo nadrukkelijk Microsoft prijzen doet mij vermoeden dat die twee een deal gemaakt hebben.
Een DEAL begrijp je, geen samenzwering van de V, de extraterraanse reptielen. en zo. En de CIA zit er ook niet achter om ons te knechten. Nee gewoon de immorele hebzucht die Microsoft al sinds haar ontstaan drijft.
Hebzucht is erg menselijk. Onder ons lopen hele nobele mensen en ook het grootste uitschot, en dat is onder de rijken en de armen, onder individuen en organisaties. Daarom zegt Marc Benioff, CEO van Salesforce.com:
Boeven zijn niet zeldzaam of zo hoor, en we hoeven echt geen alu hoedjes op te zetten om ons te beschermen, we moeten alleen onze ogen opendoen, onderscheiden wie netje zijn en wie boeven. Door de gladde marketingpraat hen kunnen kijken."Het zijn eigenlijk boeven. Elke bloeiende economie heeft boeven en we hebben die ook, en dat is prima. Persoonlijk ben ik alleen teleurgesteld om dit soort gedrag te zien van een voormalig leider van onze industrie."
Dat de tekst uit 2000 is, is irrelevant, de bedrijfscultuur bij MS is niet veranderd, integendeel, de boetes zijn alleen maar hoger geworden. Het is zo goed als onmogelijk om een bedrijfscultuur te veranderen.
[Reactie gewijzigd door Magalaan op 27 juli 2012 21:22]
Waar blijf je die onzin toch halen? Wat heeft bedrijfscultuur te maken met boetes?Dat de tekst uit 2000 is, is irrelevant, de bedrijfscultuur bij MS is niet veranderd, integendeel, de boetes zijn alleen maar hoger geworden. Het is zo goed als onmogelijk om een bedrijfscultuur te veranderen.
Ik vraag me soms echt af waar het fout gelopen is tussen Microsoft en jou. Ik heb echt met je te doen, want het moet vreselijk geweest zijn.
Als ik mijn lijstje met Windows security patches naloop en de ene patch op de andere patch voorbij zie komen, dan daalt toch wel mijn algemene vertrouwen in de veiligheid van Windows. Trouwens dit gevoel wordt bij elke nieuwere versie van Windows steeds sterker. Het lijkt wel alsof Operatins Systems steeds sneller op de markt moeten komen, zonder eerst eens kritisch te kijken welke bugs er nog allemaal inzitten, en dan heb ik het niet alleen over beveiligingsbugs.
Ze kunnen dus maar beter niet meer pachten, zodat jij niet bang wordt?Als ik mijn lijstje met Windows security patches naloop en de ene patch op de andere patch voorbij zie komen, dan daalt toch wel mijn algemene vertrouwen in de veiligheid van Windows.
Je kan ook juist blij zijn dat ze ondersteuning bieden, en regelmatig patches uitbrengen.
Ondersteuning? my @#$!!!, Microsoft biedt mensen juist een belabberde ondersteuning. Voorbeeld: het halve bedrijfsleven zit nog op Windows XP, maar jij als bedrijf zijnde moet maar overstappen omdat Microsoft perse Windows 8 of een opvolger van XP door je strot wilt duwen. En dat denken ze dan te kunnen doen door te stoppen met het uitbrengen van patches en het beiden van ondersteuning in zijn geheel op een besturingssyteem, waarbij ze bij de introductie anders dolenthousiast over waren (trouwens dat zijn ze bij elke introductie, want elk besturingssysteem wat ze uitbrengen is zogenaamd altijd beter dan het vorige).
sorry hoor maar je heb weet ik hoe veel jaar de tijd gehad om je bedrijfs netwerk klaar t emaken voor een opvolger van win xp. dat jij verlang dat ze xp eeuwen lang blijven ondersteunen is toch eerder een tekortkoming van jou kant. en ja als jij met je bedrijf eeuwen lang xp wil blijven gebruiken zul je ook meer patches krijgen. je wil er zelf voor kiezen om op een oud OS te blijven doorgaan. je zit de boel beetje te verdraaien om MS maar zwart te maken.
Even voor de duidelijkheid. Ik werk momenteel zelf met Windows 7 Ultimate en zal zodra Windows 8 er is, hierop overstappen. Dus wie loopt hier nu MS zwart te maken?
Een stuk software als Windows bevat zo belachelijk veel code dat het simpelweg onmogelijk is om met een ontwikkelteam als dat van Microsoft alle bugs eruit te halen. Daar is de wereld voor nodig, en zelfs die vinden jaren na de release nog bugs.
Heb je meer vertrouwen in Linux dan in Windows? Voor Linux komen zelfs dagelijks patches uit
Voor Windows ook, maar om de boel beheersbaar te houden worden ze maandelijks vrijgegeven
Heb je meer vertrouwen in Linux dan in Windows? Voor Linux komen zelfs dagelijks patches uit
Voor Windows ook, maar om de boel beheersbaar te houden worden ze maandelijks vrijgegeven
Jij noemt een maandelijkse patchdag "beheersbaar houden", ik noem het gebruikers onnodig veiligheidsupdates onthouden. Als er een lek is wil ik de patch gisteren hebben, niet volgende maand. Al die weken loop je kans gehacked te worden door een bug die allang al gefixed is.
Dringende updates worden wel degelijk tussendoor verspreid.
Kritische patches worden door Microsoft eerder / sneller gereleased. Onlangs nog eentje, die toevallig in de patch tuesday viel, zie ook nieuws: Microsoft dicht zero day-xml-lekJij noemt een maandelijkse patchdag "beheersbaar houden", ik noem het gebruikers onnodig veiligheidsupdates onthouden. Als er een lek is wil ik de patch gisteren hebben, niet volgende maand. Al die weken loop je kans gehacked te worden door een bug die allang al gefixed is.
Das redelijk goed te doen, voor een thuis PC. Maar bij bedrijven is dat technisch onmogelijk. Dat is niet te management en te testen. Iedereen weet nu wanneer patches uitkomen, dus kan je daar rekening mee houden.
Sterker nog je kunt aangeven dat een server wel alvast de patches downloadt, maar dat deze bijvoorbeeld pas in het weekend worden geïnstalleerd. Hierdoor hebben de werknemers er dan het minste last van en worden ze niet gestoord tijdens hun werk door allerlei pop-ups en reboot meldingen van de desbetreffende updates.
Het geeft mij juist volop vertouwen dat ze zoveel patchen.
De code is gewoon heel groot, Het is juist goed dat het steeds veiliger gemaakt kan worden met patches.
De code is gewoon heel groot, Het is juist goed dat het steeds veiliger gemaakt kan worden met patches.
En ter verdediging van het standpunt dat dat FUD van een softwarebedrijf is wat antivirus software probeert te slijten:
En dat was de vorige versie van OSX. In Mountain Lion zijn allemaal andere security features toegevoegd als sandboxing, gatekeeper, kernel ASLR en meer.
http://www.apple.com/osx/whats-new/features.html#security
http://www.theregister.co...1/mac_os_x_lion_security/Major overhaul makes OS X Lion king of security
“It's a significant improvement, and the best way that I've described the level of security in Lion is that it's Windows 7, plus, plus,” said Dino Dai Zovi, principal of security consultancy Trail of Bits and the coauthor of The Mac Hacker's Handbook. “I generally tell Mac users that if they care about security, they should upgrade to Lion sooner rather than later, and the same goes for Windows users, too.”
No doubt, Apple deserves kudos for setting a new standard in OS security that Microsoft and Linux distributors would do well to emulate.
En dat was de vorige versie van OSX. In Mountain Lion zijn allemaal andere security features toegevoegd als sandboxing, gatekeeper, kernel ASLR en meer.
http://www.apple.com/osx/whats-new/features.html#security
Voor windows lijkt dat anders veelal wel te kloppen. 
Omdat non-apple gebruikers geen roze bril op hebben mbt Apple? het is al lang bekend dat de beveiliging van MacOSX net zo lek is als Windows jaren geleden, enige reden dat de lekken niet misbruikt worden is dat het aantal MacOSX gebruikers vele VELE malen lager ligt dan bij Windows..
Er zijn nou eenmaal een hoop gebruikers op deze site die alle berichten over welk OS dan ook om te zetten in een Apple discussie. Of het nou de Apple fanboys of de Apple haters zijn, iedere keer is het weer hetzelfde verhaal.
Kunnen al die flamers niet gewoon een keer goed onderbouwd commentaar posten? In plaats van loze kreten als "een bedrijf dat windows software maakt vind windows beter, dus is windows beter"? Inhoudelijke reacties hebben we een stuk meer aan dan nutteloos gehaat.
En kunnen al die fanboys eens een keer kappen met iedere gelegenheid aan te grijpen om te roepen dat OS X zo veel beter is? Alle software bevat bugs. De een wat meer dan de ander, maar vroeg of laat is jouw software ook aan de beurt.
Kunnen al die flamers niet gewoon een keer goed onderbouwd commentaar posten? In plaats van loze kreten als "een bedrijf dat windows software maakt vind windows beter, dus is windows beter"? Inhoudelijke reacties hebben we een stuk meer aan dan nutteloos gehaat.
En kunnen al die fanboys eens een keer kappen met iedere gelegenheid aan te grijpen om te roepen dat OS X zo veel beter is? Alle software bevat bugs. De een wat meer dan de ander, maar vroeg of laat is jouw software ook aan de beurt.
Met andere woorden, breng een besturingssysteem niet zo snel op de markt als je weet dat er nog bugs inzitten (ja, en ik weet dat geen enkel systeem foutloos is). Maar onder druk van de concurrentie wordt daar vaak geen gehoor aan gegeven. Men wil het besturingssysteem zo snel als men kan op de markt hebben. Dat kan 2 oorzaken hebben: verkoop en dus geld, of een soort van arrogantie: zo van wij hebben het lekker al wel en jullie niet. Maar nogmaals, das puur mijn mening. Iets waar je volgens mij om vroeg in het bovenstaande stukje
En Microsoft heeft code gejat van FreeBSD, dat is toch ook een onzin conclusie.
Aangezien de BSD licentie het gebruik van code door anderen gewoon toestaat is dit gejat natuurlijk onzin...
Darwin is geen freeBSD, maar een afgeleide van langer dan 6 jaar geleden. Kan dus twee kanten op gaan...
Mac OS X is niet hetzelfde als FreeBSD. Mac OS X is een XNU (op mach gebaseerde) kernel, en bevat dus niet de FreeBSD kernel.FreeBSD ? Dus Mac OSX ook ?
Er zitten delen van 4.3 BSD uit het FreeBSD project in die kernel, dus an sich is het het onderzoeken waard, maar ik heb zo'n vermoeden dat deze onderzoeker dat ook al gedaan heeft.
[Reactie gewijzigd door arjankoole op 27 juli 2012 11:40]
XNU is de kernel van Mac OS X, het besturingssysteem van Apple voor Macs. XNU is een microkernel-ontwerp gebaseerd op de Mach 3.0 microkernel en de 4.4BSD system services. Het is een opensourceproject. XNU is een acroniem voor X is Not Unix.
Gedeeltelijk dus wel gebaseerd op BSD.
Bron: http://nl.wikipedia.org/wiki/XNU
Gedeeltelijk dus wel gebaseerd op BSD.
Bron: http://nl.wikipedia.org/wiki/XNU
Dat weet ik. En dat ontken ik ook niet. Ik zeg dat het niet hetzelfde ( == ) is als FreeBSD.
Het is een 4.3 BSD, die de code heeft uit FreeBSD, maar dat maakt het nog niet gelijk aan FreeBSD, of direct gevoelig voor dezelfde fout, omdat het niet de FreeBSD kernel bevat.
Da's de nuance, zeg maar.
Het is een 4.3 BSD, die de code heeft uit FreeBSD, maar dat maakt het nog niet gelijk aan FreeBSD, of direct gevoelig voor dezelfde fout, omdat het niet de FreeBSD kernel bevat.
Da's de nuance, zeg maar.
Ik mag toch hopen dat ze die 4.3BSD code inmiddels vervangen hebben door 4.4BSD (Lite (2)).
Het merendeel is inmiddels door Apple herschreven ja. Dat is wel weer terug gesynced naar FreeBSD. (Hoeft volgens de licentie niet eens)
Vorige maand was dit probleem reeds in het nieuws:
http://www.security.nl/ar..._met_Intel_processor.html
http://www.security.nl/ar..._met_Intel_processor.html
En nu dus opgelost 
Weer een vinkje minder in MetaSploit?
Weer een vinkje minder in MetaSploit?
Ja of gelijk weer tig nieuwe, want een oplossing voor het 1, kan wel zorgen voor tientallen problemen bij iets anders.
Wat ik vreemd vindt is dat er gesproken wordt over 'een verkeerde implementatie van een Intel X64 instructie' in een OS ?
Het is een compiler die de code van een OS compileerd naar bits en bytes die de CPU begrijpt, niet het OS. Als een compiler wat verkeerd doet tijdens het compileren, dan kan er inderdaad een instructie ontstaan die iets anders doet dan bedoeld (omdat de juiste bits en bytes niet gezet worden), of je krijgt een uitzondering wat meestal tot een crash leidt (afhangkelijk van hoe goed het OS de uitzonderingen kan opvangen).
Maar het OS zelf ? Dat lijkt mij toch erg sterk.
Het is een compiler die de code van een OS compileerd naar bits en bytes die de CPU begrijpt, niet het OS. Als een compiler wat verkeerd doet tijdens het compileren, dan kan er inderdaad een instructie ontstaan die iets anders doet dan bedoeld (omdat de juiste bits en bytes niet gezet worden), of je krijgt een uitzondering wat meestal tot een crash leidt (afhangkelijk van hoe goed het OS de uitzonderingen kan opvangen).
Maar het OS zelf ? Dat lijkt mij toch erg sterk.
Niet alles word gecompileerd hoor, vaak zijn er nogal wat "hooks"(Wikipedia, jbremer artikel, Microsoft MSDN) waar een programma haakt in het OS, de fout die hier op gedoeld word is een fout in de verwerking van zo'n "Hook".
Het gaat hier om hoe de os zelf de hook oppikte en met welke instructie op de processor dit werd gedaan.
Dus dit is een runtime probleem, niet (per definitie) een compiler probleem. (al hoe wel de fout uiteraard door een compiler kan zijn geïntroduceerd, is het feit dat zo veel verschillende OS'en dit hebben niet erg waarschijnlijk.)
Het gaat hier om hoe de os zelf de hook oppikte en met welke instructie op de processor dit werd gedaan.
Dus dit is een runtime probleem, niet (per definitie) een compiler probleem. (al hoe wel de fout uiteraard door een compiler kan zijn geïntroduceerd, is het feit dat zo veel verschillende OS'en dit hebben niet erg waarschijnlijk.)
Voor zover ik begrepen heb was de betreffende software geschreven op basis van de implementatie van AMD. Echter, Intel had e.a. net iets anders geïmplementeerd (en ook gedocumenteerd) en daar werd geen rekening mee gehouden.
Juist op OS niveau kom je nog behoorlijk wat direct geschreven assembly code tegen. De compilers waar jij over praat werken prima voor applicaties en de grootste delen van een OS, maar sommige zaken krijg je echt niet gedaan zonder assembly code.
Voorbeeldje: Je processor start op in een mode dat hij nog steeds MSDOS code kan draaien. Om in de mode te komen die in WIndows gebruikt wordt, waarbij al je geheugen toegankelijk is zal je een paar instructies uit moeten voeren op de processor die geen enkele compiler zal genereren, tenzij je ze zelf in assembly opschrijft. Assembly code wordt direct vertaald in bits en bytes, zoals je het zelf noemt, dus als je die instructies verkeerd opschrijft kan je gekke dingen krijgen.
Compilers zijn trouwens ook niet vlekkeloos, de linux kernel zit vol met hacks om bugs uit de compilers en linkers te omzeilen, bijvoorbeeld http://www.gossamer-threads.com/lists/linux/kernel/259044. Ook halen de compilers soms truckjes waar je niet bij stil staat, bijvoorbeeld https://isc.sans.edu/diary.html?storyid=6820
Voorbeeldje: Je processor start op in een mode dat hij nog steeds MSDOS code kan draaien. Om in de mode te komen die in WIndows gebruikt wordt, waarbij al je geheugen toegankelijk is zal je een paar instructies uit moeten voeren op de processor die geen enkele compiler zal genereren, tenzij je ze zelf in assembly opschrijft. Assembly code wordt direct vertaald in bits en bytes, zoals je het zelf noemt, dus als je die instructies verkeerd opschrijft kan je gekke dingen krijgen.
Compilers zijn trouwens ook niet vlekkeloos, de linux kernel zit vol met hacks om bugs uit de compilers en linkers te omzeilen, bijvoorbeeld http://www.gossamer-threads.com/lists/linux/kernel/259044. Ook halen de compilers soms truckjes waar je niet bij stil staat, bijvoorbeeld https://isc.sans.edu/diary.html?storyid=6820
Volgens mij is het voor een mens onmogelijk een ingewikkeld programma (zoals een besturingssysteem) te maken, zonder eerst alle mogelijke uitkomsten van een instructie getest te hebben. Ik kan het mis hebben, maar dan hoor ik ook wel graag hoe het dan wel zit. We zijn immers tweakers en ik ben altijd bereid om iets nieuws te leren.
Het gaat hier gewoon om de interpretatie van hoe de SYSRET instructie precies werkt. Intel heeft de x86_64 instructieset gekopieerd van AMD, maar heeft daarbij een subtiel andere betekenis gegeven aan deze specifieke instructie (en ook andere, maar dat terzijde).
Aangezien de auteurs van het stukje kernel code dat syscalls afhandelt, hebben gerekend op "AMD gedrag", gaat het nu met Intel CPUs soms de mist in.
Sommige mensen vinden dat dit een fout van Intel is, omdat ze niet precies hetzelfde gedrag als AMD hebben geimplementeerd. Intel zelf zegt dat ze gewoon in de handleiding hebben gespecificeerd dat het anders werkt, en ze zijn dus kennelijk niet van plan om er iets aan te wijzigen (bijvoorbeeld met een microcode update).
Lees voor een iets uitgebreidere uitleg dit verhaal even.
Aangezien de auteurs van het stukje kernel code dat syscalls afhandelt, hebben gerekend op "AMD gedrag", gaat het nu met Intel CPUs soms de mist in.
Sommige mensen vinden dat dit een fout van Intel is, omdat ze niet precies hetzelfde gedrag als AMD hebben geimplementeerd. Intel zelf zegt dat ze gewoon in de handleiding hebben gespecificeerd dat het anders werkt, en ze zijn dus kennelijk niet van plan om er iets aan te wijzigen (bijvoorbeeld met een microcode update).
Lees voor een iets uitgebreidere uitleg dit verhaal even.
En OpenBSD? OpenBSD is extreem gefocust op security maar lenen ook veel code van de andere BSD-smaakjes. Ben wel benieuwd of deze bug daar ook nog bestond.
Nee, OpenBSD had dit probleem al jaren geleden opgelost. Zie deze mail thread.
Volgens mij virtualiseert Amazon haar AWS-diensten met Xen, op Intel CPU's, in PV-mode. Iemand enig idee waarom ze zelf stellen dat ze niet kwetsbaar waren?
UIt artikel:
Ik geloof (correct me if i'm wrong) dat Amazone meerdere laags virtualisatie gebruikt (soort van zwevende virtuele omgeving) om zelfs single machine failure stil, automatisch en snel op te kunnen vangen.
Amazone draait dus hun (root) XEN servers niet in die modus.Overigens was Xen alleen kwetsbaar als hij in een bepaalde modus draaide, genaamd de paravirtualisatiemodus.
Ik geloof (correct me if i'm wrong) dat Amazone meerdere laags virtualisatie gebruikt (soort van zwevende virtuele omgeving) om zelfs single machine failure stil, automatisch en snel op te kunnen vangen.
[Reactie gewijzigd door Sysosmaster op 27 juli 2012 12:25]
Een cloud service provider die het uitvallen van een machine niet stil, automatisch en snel op kan vangen is in mijn ogen geen aanbieder van cloud services. Sterker nog, in mijn ogen moet de uitval van een compleet datacentrum automatisch en snel opgevangen kunnen worden door een cloud provider.
Voor de gewone XP worden nog security fixes uitgebracht, maar ik kan zo snel even nergens vinden of dat voor XP64 ook nog zo is...!? Want als Microsoft dit nu oplost, dan neem ik aan dat ze het oplossen in alle versies waar ze überhaupt nog fixes voor uitbrengen en dat is (voor een 64bit-specifiek probleem) volgens mij alles wat ze ooit uitgebracht hebben, behalve dan misschien XP64 / Server2003.in 64bit-versies van Windows 7, Windows Server 2008 R2 (..) Of eerdere Windows-versies ook kwetsbaar waren, is onduidelijk.
Windows XP 64 heeft extended support tot 2014-04-08 (bron). Dus ja, MS zou hiervoor een patch moeten uitbrengen.
Hier de patch voor de geïnteresseerden:
Index: sys/amd64/amd64/trap.c
===================================================================
--- sys/amd64/amd64/trap.c.orig
+++ sys/amd64/amd64/trap.c (working copy)
@@ -972,4 +972,21 @@
syscallname(td->td_proc, sa.code)));
syscallret(td, error, &sa);
+
+ /*
+ * If the user-supplied value of %rip is not a canonical
+ * address, then some CPUs will trigger a ring 0 #GP during
+ * the sysret instruction. However, the fault handler would
+ * execute with the user's %gs and %rsp in ring 0 which would
+ * not be safe. Instead, preemptively kill the thread with a
+ * SIGBUS.
+ */
+ if (td->td_frame->tf_rip >= VM_MAXUSER_ADDRESS) {
+ ksiginfo_init_trap(&ksi);
+ ksi.ksi_signo = SIGBUS;
+ ksi.ksi_code = BUS_OBJERR;
+ ksi.ksi_trapno = T_PROTFLT;
+ ksi.ksi_addr = (void *)td->td_frame->tf_rip;
+ trapsignal(td, &ksi);
+ }
}
Zo te zien is die van BSD (gezien het KNF indenting gebruikt).
Yep, ik zag 't aan de Index entry.
Scherp gezien. Dit was de FreeBSD Patch, die van Windows heb ik nog niet gevonden
Als ik de comment van die patch goed begrijp gaat het om de fault handler code die een (foutieve) aanroep van de sysret-instructie met als parameter een illegaal adres afhandelt met verkeerde privileges. Dus een gewone gebruiker kan mogelijk in kernelspace knoeien door dit als exploit toe te passen?
Geen idee wat %gs en %rsp zijn, maar dat "some CPUs" zegt me toch dat het iets met de hardwareimplementatie van sysret te maken heeft, of in ieder geval onduidelijkheid daarin.
Bij FreeBSD zie ik trouwens dat het geen effect heeft op AMD processors en alle andere 64-bit processors die een 32-bit kernel draaien. Dus er valt een erg groot deel weer af
Geen idee wat %gs en %rsp zijn, maar dat "some CPUs" zegt me toch dat het iets met de hardwareimplementatie van sysret te maken heeft, of in ieder geval onduidelijkheid daarin.
Bij FreeBSD zie ik trouwens dat het geen effect heeft op AMD processors en alle andere 64-bit processors die een 32-bit kernel draaien. Dus er valt een erg groot deel weer af
[Reactie gewijzigd door blorf op 27 juli 2012 13:59]
Ja, dat is kortweg het gevolg. Je zou hiermee als VM guest kunnen proberen te "ontsnappen" uit je virtuele kooi.Dus een gewone gebruiker kan mogelijk in kernelspace knoeien door dit als exploit toe te passen?
VMware had er geen last van, want die handelden een syscall return kennelijk anders af.gs is een segment register, dat wordt gebruikt om makkelijk bij bepaalde informatie over het lopende proces te komen. rsp is de 64-bits stack-pointer.Geen idee wat %gs en %rsp zijn, maar dat "some CPUs" zegt me toch dat het iets met de hardwareimplementatie van sysret te maken heeft, of in ieder geval onduidelijkheid daarin.
Zoals hierboven al gezegd, gaat het om een subtiel verschillende implementatie door Intel van de SYSRET instructie. AMD was hier eigenlijk de standaard, maar Intel heeft daar dus ietsje van afgeweken. Nu kan het zwartepieten beginnen.
[Reactie gewijzigd door Dim op 27 juli 2012 17:56]
Microsoft heeft jaren met de tcp/ip stack van een BSD variant gedraaid, die ze met veel gepruts werkend hebben gekregen. Daarna hebben ze jaren en jaren allerlei fouten gewoon laten zitten.
Microsoft heeft nog geprobeerd om een alternatief internet te gaan bouwen, met eigen satellieten en zelf bedachte protocollen en/of andere rare kronkels. Ik ben ooit gegijzeld geweest omdat ik tijdens een lezing van ome Bill weg wilde vanwege de grote hoeveelheid kansloze fantasie. Ik mocht niet weg!
Microsoft heeft altijd kwaliteitsproblemen gehad, en inmiddels zit dat in de bedrijfscultuur. Als je na 30 jaar nog steeds niets verdient aan je besturing systemen dan doe je toch iets fout. We weten allemaal dat Microsoft iedere 2a3 jaar een nieuwe versie van office door je strot moet drukken anders zijn ze zo weg. Ze verdienen op office en Xbox de rest wat ze doen levert, hoe vaak ook verkocht, alleen maar rooie cijfers op. Alles wat ze doen om het beter te maken kost nog meer 'verlies' .
Microsoft is een stervende reus, ze zijn te lomp om te kunnen switchen (Zie tablet/phone) en er is nog nooit zo veel concurrentie voor Microsoft geweest.
Gates is altijd een looser geweest, en Balmer is de Gore verkoper die zijn eigen kinderen nog verpatst voor een dubbeltje, Dat is Microsoft.!
Al die fantasie verhalen over hoe goed MS wel niet is komen van de door Microsoft gebrainwashte MCSE en MCSE figuren. Windows 8 is niet beter dan XP of zeven, het is een systeemeis voor de volgende versie van office.
Iedere computer met spullen van Microsoft heeft 30 jaar oude beveiligingsproblemen, wen daar maar aan.
Microsoft heeft nog geprobeerd om een alternatief internet te gaan bouwen, met eigen satellieten en zelf bedachte protocollen en/of andere rare kronkels. Ik ben ooit gegijzeld geweest omdat ik tijdens een lezing van ome Bill weg wilde vanwege de grote hoeveelheid kansloze fantasie. Ik mocht niet weg!
Microsoft heeft altijd kwaliteitsproblemen gehad, en inmiddels zit dat in de bedrijfscultuur. Als je na 30 jaar nog steeds niets verdient aan je besturing systemen dan doe je toch iets fout. We weten allemaal dat Microsoft iedere 2a3 jaar een nieuwe versie van office door je strot moet drukken anders zijn ze zo weg. Ze verdienen op office en Xbox de rest wat ze doen levert, hoe vaak ook verkocht, alleen maar rooie cijfers op. Alles wat ze doen om het beter te maken kost nog meer 'verlies' .
Microsoft is een stervende reus, ze zijn te lomp om te kunnen switchen (Zie tablet/phone) en er is nog nooit zo veel concurrentie voor Microsoft geweest.
Gates is altijd een looser geweest, en Balmer is de Gore verkoper die zijn eigen kinderen nog verpatst voor een dubbeltje, Dat is Microsoft.!
Al die fantasie verhalen over hoe goed MS wel niet is komen van de door Microsoft gebrainwashte MCSE en MCSE figuren. Windows 8 is niet beter dan XP of zeven, het is een systeemeis voor de volgende versie van office.
Iedere computer met spullen van Microsoft heeft 30 jaar oude beveiligingsproblemen, wen daar maar aan.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets E3 2013 Mobiele telefoons Google Sony Microsoft Apple Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
