CleanPress

Schlagwort: Intel

  • Prozessor-Bug: Schadensbegrenzung beim Super-Gau

    Prozessor-Bug
    Bild: „CPU“ von Jaroslaw W Lizenz: CC-By-2.0

     

    Am dritten Tag nach der Veröffentlichung des mit Fug und Recht als Super-GAU bezeichneten Bugs in den meisten seit 1995 produzierten Prozessoren wird das gesamte Ausmaß des katastrophalen Fehlers klar: es handelt sich um einen in Silizium gegossenen Design-Fehler, der Milliarden von Geräten betrifft, von denen viele niemals einen Fix sehen werden. Dazu zählen vor allem viele Android-Smartphones. Über den Umfang der Auswirkungen auf AMD-Prozessoren besteht weiterhin Unklarheit. AMD selbst hatte die Chance, die Lücken beträfen auch AMD-CPUs als nahe Null bezeichnet.

    Entwarnung für Heimanwender

    Etwas Entwarnung gibt es dagegen bei den zu erwartenden Performance-Einbrüchen für durchschnittliche Heimanwender. Wer an seinem Rechner hauptsächliche surft, spielt und Office-Aufgaben erledigt, wird kaum einen Verlust an Geschwindigkeit verspüren, die Werte sollten im niedrigen einstelligen Bereich liegen. Anders kann das im Büro aussehen, wenn etwa große Datenbanken betrieben werden. Hier kann die Höchststrafe unter Umständen bei bis zu 30 Prozent liegen. Das liegt hauptsächlich daran, dass die Fixes für die Lücken die I/O-Last nach oben treiben.

    Intel in bekannter Manier

    Viele Hersteller haben sich zu Wort gemeldet, Intel gleich zwei Mal. Die Nachricht aus dem Intel Newsroom ist ähnlich vage und nichtssagend wie die vom Vortag. Dort heißt es:

    »Intel hat Updates für alle Arten von Intel-basierten Computersystemen – einschließlich PCs und Servern – entwickelt und veröffentlicht, die diese Systeme gegen beide von Google Project Zero gemeldeten Exploits (als „Spectre“ und „Meltdown“ bezeichnet) immun machen. Intel und seine Partner haben bedeutende Fortschritte bei der Bereitstellung von Updates erzielt, sowohl bei Software-Patches als auch bei Firmware-Updates.«

    In weiteren Verlauf der Verlautbarung stellt sich Intel an die Speerspitze derer, die Lösungen für das Problem anbieten, ohne dabei konkret zu sagen, was Intel den Betroffenen anbietet. Am Ende gibt es einen Link, der zumindest weitere technische Einzelheiten enthält, aber nichts an den Tag bringt, was nicht bereits bekannt war und von anderer Seite mit wesentlich mehr Details veröffentlicht wurde. Zudem behauptet Intel dort weiterhin, es handle sich nicht um einen Fehler in Intels Hardware. Die Begründung lautet, es seien auch andere Hersteller betroffen. Diese Logik wirkt zumindest befremdlich.

    Betroffene Intel-CPUs aufgelistet

    Die zweite Veröffentlichung von Intel stammt aus dem hauseigenen Security Center und erweist sich als nützlicher, denn sie nennt im Detail die betroffenen Plattformen und Prozessoren aus eigener Produktion. Zudem bedankt sich Intel bei den Forschern von Google und der Universität Graz, die die Lücke in etwa zeitgleich entdeckt hatten.

    ARM reagiert vorbildlich

    ARM hat ausführlich und übersichtlich Stellung zu den betroffenen Prozessoren und dem, was ein Anwender zur Absicherung tun sollte Stellung bezogen. Dabei wird pro betroffenem Prozessor dargestellt, welche der drei Varianten auf den jeweiligen Cortex-Kern zutrifft. Leider wird das vielen betroffenen Smartphone- und Tablet-Besitzern nicht viel nützen, da es vom Hersteller des Geräts abhängt, wann ein Update angeboten wird. Für viele Geräte wird das heißen: niemals. Googles eigene Baureihen Nexus und Pixel haben bereits ein Update für Januar erhalten oder es ist in der Auslieferung und wird zeitnah aufgespielt.

    Google stellt Retpoline vor

    Google hat ebenfalls am gestrigen Tag weitere Details veröffentlicht. Darin geht es hauptsächlich um die von Google erstellten Gegenmaßnahmen und die zu erwartenden Leistungseinbußen. Dabei stellt Google eine neue Technik zur Entschärfung namens Retpoline vor, die gegen Spectre, auch als »Branch Target Injection« bezeichnet, eingesetzt werden kann und wenig Leistungseinbußen nach sich ziehen soll. Retropline ist ein zusammengesetzter Begriff aus den Worten »return trampoline«. Die Technik verwendet eine Endlosschleife, die nie ausgeführt wird, um die CPU daran zu hindern, auf das Ziel eines indirekten Sprunges zu spekulieren. Entwickler Paul Turner hat die Technik gestern auch den Kernel-Entwicklern vorgestellt.

    Distributionen verteilen KPTI-Patches

    Die großen Linux-Distributionen haben Kernel veröffentlicht, die die KPTI-Patches gegen die Lücken verteilen. Microsoft hat wegen der Brisanz der Lücken die Auslieferung weiterer Patches für Windows 10 vorgezogen, die ab dem 03. Januar 2018 ab 22 Uhr verteilt werden sollen. Patches für ältere Versionen wie Windows 7 und  8 sollen zum nächsten Microsoft Patchday folgen. Bei den jetzt für Windows 10 angebotenen Updates gab es vereinzelt Kompatibilitätsprobleme mit Anti-Viren-Software. Microsoft rät dringend dazu, das Update nicht manuell zu forcieren, sondern erst einzuspielen wenn es über die Update-Funktion angeboten wird.

    Firefox vorerst abgesichert

    Mozilla hat als Reaktion auf die Lücke Firefox 57.0.4 veröffentlicht. Als vorübergehende Maßnahme, bis die genaue Funktionalität der Lücken bekannt sei, hat Mozilla die Genauigkeit der Zeitintervalle über die Funktion performance.now() von 5μs auf 20μs heraufgesetzt, um Javascript-Angriffe zu erschweren, die auf die Messung präziser Zeitintervalle angewiesen sind. Zudem wurde der SharedArrayBuffer-Standard deaktiviert, um die Verwendung höher auflösender Timer zu verhindern. Auch Google, Apple und Microsoft haben ihre Browser entsprechend gepatched. Diese sind allerdinmgs im Gegensatz zu Firefox noch nicht veröffentlicht. Micosoft wird Edge am 9. Januar aktualisieren, Google Chrome 64 erscheint am 23. Januar.

    Mitlesen von der Tastatur

    Auf LWN gibt es einen  Überblick über weitere interessante Links zum Thema. Auch ein Interview der Berliner Zeitung  »Der Tagesspiegel« mit einem der Entdecker der Lücken von der Universität Graz lohnt das Lesen. Michael Schwarz erläutert darin, man könnte theoretisch alles mitlesen, was gerade auf der Tastatur eingegeben wird. Die Lücken können allerdings nur ausgenutzt werden, wenn bereits Zugriff auf den Rechner besteht.

    Das trifft allerdings nur für Meltdown zu, Spectre kann bereits über den Browser ausgenutzt werden. Allerdings ist es mit Spectre wesentlich schwerer, Daten auszulesen. Hierbei müssen sehr präzise Timings eingehalten werden, zudem muss der Angreifer wissen, welche Prozesse gerade laufen und welche Daten sich im Speicher befinden. Schwarz bestätigt, dass Meltdown bisher nur auf Intel-Prozessoren reproduziert wurde. Spectre schließt auch alle Smartphones mit ARM-Prozessoren ein.

    Linus Torvalds not amused

    Die Kernel-Entwickler bei Linux sind alles andere als erfreut über die Art und Weise, wie die Informationspolitik im Hinblick auf die Lücken gehandhabt wurden, die Intel seit Juni 2017 bekannt waren. Linus Torvalds äußert sich für seine Verhältnisse sehr zurückhaltend zu Intels PR:

    »Ich denke, dass jemand innerhalb von Intel wirklich einen langen harten Blick auf ihre CPUs werfen muss, und tatsächlich zugeben muss, dass sie Probleme haben, anstatt PR-Blurbs zu schreiben, die besagen, dass alles so funktioniert, wie es entworfen wurde….

    …Oder sagt Intel im Grunde genommen, dass sie darauf abonniert sind, uns für immer und ewig Scheiße zu verkaufen und nie etwas zu reparieren? Denn wenn das der Fall ist, sollten wir vielleicht anfangen, uns mehr auf die ARM64-Leute zu konzentrieren.«

    Zu spät informiert

    Andere Entwickler monieren, dass die Betriebssystemhersteller viel zu spät über die Vorgänge informiert worden seien und nun zum Schutz ihrer Anwender unter Zeitdruck Gegenmaßnahmen entwerfen mussten. Nach Aussagen von Mounir Hahad, Chef der Sicherheitsanalyse bei Juniper Networks, konnte bisher in freier Wildbahn kein Fall entdeckt werden, der die Lücken ausnutzt. Da diese Lücken aber schon seit rund 20 Jahren bestehen, kann niemand mit Bestimmtheit sagen, ob sie nicht in der Vergangenheit bereits von Geheimdiensten oder Kriminellen ausgenutzt wurden.

    Eines ist jedoch bereits jetzt klar: Die Auswirkungen dieses Design-Fehlers werden uns noch lange begleiten und beschäftigen. Ganz besonders im Fall von Spectre, da hier jede Anwendung einzeln gegen die Lücke abgeichert werden muss. die Kernel-Patches reichen hier nicht aus.

  • Gefährlicher Design-Fehler in Intel CPUs

    Fehler in Intel CPUs
    Bild: „Intel“ von Christian Rasmussen Lizenz: CC By-SA-2.0

     

    Nach den Erkenntnissen der letzten Wochen zu Intel ME scheint Intel auch 2018 nicht aus den negativen Schlagzeilen herauszukommen. In einem Blog erschien am 1. Januar  ein Artikel, der Hinweise auf einen Fehler sammelte, der anscheinend alle Intel-CPUs der letzten Jahre betrifft. Der Artikel weist zwar einige Fehler und vorschnelle Annahmen auf, folgt aber generell der richtigen Spur. Eine Beseitigung der Sicherheitslücke dahinter ist nur durch teils massive Änderungen an den einzelnen Betriebssystemen möglich, er kann anscheinend nicht in Intels Microcode repariert werden.

    Linux- und Windows-Patches vorhanden

    Bei Linux sind die Patches teilweise in Kernel 4.15 integriert und weitere für 4.16 geplant. Seit gestern abend ist bereits Kernel 4.14.11 gepatched. Bei Windows wurden sie den Benutzern des Fast Ring bereits im alten Jahr ausgeliefert und sollen an einem der nächsten Microsoft-Patchdays offiziell ausgeliefert werden. Apple schweigt sich wie üblich aus. Aber auch Intel hüllt sich über den Fehler in Schweigen. Die Kommentare in den Patches, die die Sicherheitslücke stopfen, verschleiern die technischen Hintergründe.

    Viel geteilter Blogeintrag

    Aufmerksam war der Autor des ersten Berichts durch hektisches Treiben bei den Kernel-Entwicklern in den letzten Wochen und über die Feiertage geworden. Tiefgreifende Änderungen am Virtual-Memory-Subsystem des Kernels, die ansonsten oft über Monate und Jahre diskutiert werden, bevor eine Zeile Code einfließt, brauchten nur wenige Wochen um in Kernel 4.15 einzufließen, der vermutlich in zwei Wochen veröffentlicht wird.

    Hektik bereits seit Oktober

    Der entsprechende Bug hat derzeit den Status embargoed, was bedeutet, dass betroffene Institutionen Kenntnis davon haben, der Fehler aber noch nicht veröffentlicht ist. Die zugrundeliegende Sicherheitslücke und die seit Oktober einfließenden Patches wurden zuerst am 20. Dezember auf LWN näher gewichtet. Der dortige Artikel ist derzeit aber nur für Abonnenten zugänglich und wird erst in den nächsten Tagen freigegeben.

    Torvalds lässt Patches für 4.15-rc4 zu

    Linus Torvalds hatte sich zu den sogenannten KAISER-Patches, die seitdem in KPTI für Kernel-Page-Table-Isolation umbenannt wurden, am 27. November dahingehend geäußert, er würde die Patches lieber in 4.16 sehen, wies aber auch gleich auf die Notwendigkeit der Portierung in die zurückliegenden LTS-Kernel 4.9 und 4.14 hin. Trotzdem flossen in 4.15-rc4 vorbereitende Patches ein, der Großteil wird, der gebotenen Sorgfalt bei solch tiefgreifenden Änderungen geschuldet,  erst mit 4.16 ausgeliefert.

    Künftig getrennte Page-Table-Bereiche

    Was steckt nun hinter dem ganzen geschäftigen Treiben? Die Kernel-Entwickler trennen damit strikt die Page Tables, die derzeit noch von Kernel- und User-Space gemeinsam genutzt werden, in zwei völlig getrennte Sätze auf. Damit wollen sie verhindern, dass ein unprivilegierter Prozess auf den Speicherbereich im Kernel-Space zugreifen kann. Nach bisherigem Erkenntnisstand kann ein Prozess eine Intel-CPU durch Ausnutzen der Sicherheitslücke dazu bringen, Speicherbereiche zu prefetchen und dann durch Aushebeln der Zugriffskontrolle direkten Zugriff auf den Kernel-Bereich zu erhalten. Zudem könnte auch der Sicherheitsmechanismus ASLR ausgehebelt werden. Die auslösenden Prozesse können von normalen Anwendungen wie Office-Anwendungen bis hin zum JavaScript in Web-Browsern stammen. Im schlimmsten Fall könnten manipulierte Anwendungen oder Anwender den Kernelspeicher auslesen, der alle möglichen Geheimnisse wie Passwörter und weitere Zugangsdaten enthalten kann. Stellt man sich das auf öffentlichen Cloud-Servern vor, wird das mögliche Ausmaß klar.

    Systemaufrufe bald langsamer

    Wenn eine Anwendung in eine Datei schreiben oder eine Netzwerkverbindung öffnen will, muss sie dazu vorübergehend die Kontrolle über den Prozessor an den Kernel abgeben. Um den Übergang vom User-Modus in den Kernel-Modus und zurück so schnell und effizient wie möglich zu gestalten, hat der Kernel Zugriff auf den  virtuellen Adressraum aller Prozesse, obwohl dieser für die Anwendung unsichtbar ist. Wenn der Kernel benötigt wird, führt das Programm einen Systemaufruf (syscall) durch, der Prozessor wechselt in den Kernel-Modus und hat Zugriff auf den Kernel. Wenn das erledigt ist, wird die CPU aufgefordert, in den Benutzermodus zurückzukehren und den Prozess erneut zu starten. Im Benutzermodus bleiben der Code und die Daten des Kernels für die Anwendung unsichtbar, ist aber in den Page Tables des Prozesses vorhanden.

    AMD vermutlich nicht betroffen

    Diese Sicherheitslücke ist in hohem Maße für virtuelle Maschinen und Container relevant, wo Bereiche mit Kernel-Techniken isoliert werden und ein Ausbrechen daraus kritisch sein kann. Nach Angaben des Kernel-Entwicklers Thomas Lendacky, der bei AMD beschäftigt ist, sind AMD-CPUs nicht betroffen. Er schreibt dazu auf LKML: » Die AMD-Mikroarchitektur erlaubt keine Speicherreferenzen, einschließlich spekulativer Verweise, die auf höher privilegierte Daten zugreifen, wenn sie in einem weniger privilegierten Modus ausgeführt werden, wenn der Zugriff zu einem Seitenfehler führen würde.«

    Mindestens 5 Prozent Strafe

    Also kann, wenn sich das bewahrheitet, für AMD-Prozessoren der KPTI-Patchset entfallen. Das könnte sich als Wettbewerbsvorteil herausstellen, da mit der Trennung der Page Tables ein anwendungsabhängiger Performance-Verlust von derzeit geschätzten mindestens fünf Prozent einhergeht. Diese Geschwindigkeitseinbußen entstehen dadurch, dass pro Syscall-Kontextwechsel ein TLB-Flush notwendig wäre. In Phasen ohne Syscall soll der TLB weiter wie gewohnt arbeiten. Modernere Intel-CPUs können dem TLB-Flush mit der PCID-Technik etwas entgegenwirken. Auf Phoronix gibt es erste Benchmarks dazu.

    Des Pudels Kern?

    Eines der Schlüsselwörter in der Aussage von Lendacky ist »spekulative Referenzen«. Bereits bei der Durchsicht der ursprünglichen KAISER-Patches von Sicherheitsforschern der Universität zu Graz stellte der Reviewer Anders Fogh in seinem Bericht fest: »Meine Ergebnisse zeigen, dass die spekulative Ausführung trotz Verstößen gegen die Isolation zwischen Kernel- und Benutzermodus tatsächlich weiter ausgeführt wird.« Hier könnte nach heutiger Erkenntnis der auslösende Fehler in Intels Silizium liegen.

    Intel schweigt

    Im Moment ist vieles an dieser Sicherheitslücke noch recht spekulativ, vor allem fehlen Informationen von Intel selbst. Klar ist, dass die Lücke besonders im Unternehmensumfeld ausgenutzt werden könnte. Große Cloud-Anbieter wie Amazon und Microsoft Azure haben bereits kurzfristig Wartungsmaßnahmen und Reboots angekündigt, ohne dabei jedoch ein mögliches Problem zu erwähnen.

    Klar scheint auch zu sein, dass der Patch erst beim Booten aktiviert wird und somit AMD-CPUs von dem Performance-Verlust nicht betroffen sein werden. Unklar ist noch, wie weit genau die Lücke bei Intel-CPUs zurückreicht. Bisher sieht es aber so aus, als seien mindestens alle Intel-CPUs der letzten zehn Jahre betroffen.

     

     

  • Ubuntu-17.10 legt Lenovo-BIOS lahm

    Ubuntu 17.10 Lenovo
    Bild: Canonical

     

    Ein Treiber im Linux-Kernel der Ubuntu-17.10-»Artful-Aardvark«-Images sorgt dafür, dass das UEFI/BIOS vieler Lenovo-Notebooks keine Änderungen mehr speichern kann. Auch einige andere Hersteller sind betroffen. Direkter Auslöser scheint der verwendete Intel-SPI-Treiber zu sein. Mittlerweile wurde der Download von Images für 17.10 von der offiziellen Download-Seite gestoppt und das ISO zurückgezogen, während an einem neuen Image gearbeitet wird.

    Bisher Lenovo, Toshiba und Acer betroffen

    Das Problem betrifft nicht nur Ubuntu 17.10 »Artful Aardvark« selbst, sondern alle Varianten des Betriebssystems in Version 17.10. Bereits in der letzten Novemberwoche gingen erste vereinzelte Meldungen ein, die das Problem schilderten. Betroffen sind mindestens die Gräte Lenovo B40-70, Lenovo B50-70, Lenovo B50-80, Lenovo Flex-10, Lenovo G40-30, Lenovo G50-70, Lenovo G50-80, Lenovo S20-30, Lenovo U31-70, Lenovo Y50-70, Lenovo Y70-70, Lenovo Yoga Thinkpad (20C0), Lenovo Yoga 2 11″- 20332, Lenovo Z50-70, Lenovo Z51-70 und Lenovo IdeaPad 100-15IBY. Ebenfalls als betroffen bekannt sind bisher Acer Aspire E5-771G, Acer TravelMate B113, Toshiba Satellite S55T-B5233 und Toshiba Satellite L50-B-1R7. Weitere Firmen die ein UEFI-BIOS der Firma Insyde ausliefern könnten ebenfalls betroffen sein.

    Kein Hochfahren mehr möglich

    Wenn das Problem auftritt lassen sich nach der Installation keine Änderungen am BIOS mehr speichern. Betroffene Systeme haben teilweise Probleme beim Hochfahren von der Festplatte und von USB-Sticks und sind im somit weitgehend unbrauchbar, da viele dieser Geräte kein Laufwerk für optische Medien mehr haben. Für einige Benutzer der DVD trat das Problem bereits beim Benutzen der Live-DVD auf. Eine Lösung um betroffene Systeme wieder lauffähig zu bekommen steht derzeit noch aus. Auch mindestens ein Anwender, der sein System auf 17.10 aktualisiert hat, ist von dem Fehler betroffen.

    Download gestoppt

    Theoretisch könnten auch andere Distributionen betroffen sein, die Kernel 4.13.4 direkt nutzen oder ihren Kernel davon ableiten. Ein korrigierter Intel-SPI-Treiber wird derzeit bei Canonical getestet. Eine weitere Möglichkeit wäre, den Treiber zu deaktivieren, da kaum ein Endanwender diesen einsetzen wird. Eine Zusammenarbeit mit Lenovo soll helfen, die eigentliche Ursache zu finden und eine Lösung für betroffene Geräte zu erarbeiten.

  • Intel stellt Test-Tool für IME-Lücke bereit

    Intel-SA-00086 Detection Tool
    Bild: „Intel“ von Kazuhisa Otsubo Lizenz: CC BY 2.0

     

    Vor wenigen Tagen musste Intel zum zweiten Mal in diesem Jahr eine Lücke in der umstrittenen Intel Management Engine eingestehen. Durch Hinweise von externen Sicherheitsforschern aufmerksam geworden, hat Intel nun nach einer internen tiefgreifenden Sicherheitsüberprüfung der Intel Management Engine (ME), Intel Server Platform Services (SPS) und der Intel Trusted Execution Engine (TXE) die Lücke bestätigt.

    Das Os im OS ist angreifbar

    Intel zufolge könnte ein Angreifer unbefugten Zugriff auf Intel ME-Funktionen und die Geheimnisse Dritter erlangen, die durch die Intel Management Engine (ME), den Intel Server Platform Service (SPS) oder die Intel Trusted Execution Engine (TXE) geschützt sind. Das könnte zum Laden und Ausführen von beliebigem Code außerhalb des Wahrnehmungsbereichs des Benutzers und des Betriebssystems führen.

    Intel-SA-00086 Detection Tool

    Der Konzern hat ein Test-Tool zur Verfügung gestellt, mit dem jeder Nutzer eines Intel-Systems unter Windows oder Linux sein System auf die hin Lücke testen kann. Im Intel-Download-Center steht dafür ein Archiv mit dem Intel-SA-00086 Detection Tool zum Download bereit. Das kleine Python-Script wird entpackt und als Root von der Kommandozeile gestartet.

    Schnell überprüft

    Zuvor ist darauf zu achten, dass die Dateien intel_sa00086.py und spsInfoLinux64 ausführbar sind. Ist dass der Fall, wird das Script mit dem Aufruf ./intel_sa00086.py gestartet. Nach weniger als einer Sekunde wird das Ergebnis angezeigt. Anwender, die bereits Python 3 als Standard verwenden, müssen vorher den Shebang der Datei von #!/usr/bin/env python zu #!/usr/bin/env python2 abändern. Danke an den Leser Fryboyter für den Hinweis.

    Ich habe bei mir zwei Intel-Systeme gestestet. Ein Notebook mit Intel Core i3 4000M wurde als nicht verwundbar eingestuft. Die Workstation mit Intel Core i7-6700 CPU dagegen ist über diese Lücke angreifbar. Selbst wenn Rechner im privaten Umfeld hier primär eher nicht das Angriffsziel sind, will man so etwas nicht haben. Intel rät, den Mainboardhersteller zu kontaktieren, um das System wieder abzusichern. Vermutlich nur bis zur nächsten Lücke.

    Mainboard-Hersteller in der Pflicht

    Intel hat bereits einen Patch an die Hersteller ausgeliefert, den diese als BIOS-Update an ihre Kunden ausliefern. Ich werde morgen MSI kontaktieren und mal schaun, wie zeitnah die Lücke geschlossen werden kann. Das Problem dabei sind die Millionen von Anwendern privat und in Unternehmen, die diesen Patch nie erhalten werden, da sie von dem Problem gar nichts mitbekommen.

  • Intel warnt vor Lücke in Management Engine

    Intel Management Engine
    Bild: Bill Bradford Licence: CC-by-2.0

    Intel hat jetzt eine offizielle Warnung vor einer Lücke in der Intel Management Engine (IME) herausgegeben. Bereits im Mai musste der Konzern eine kritische Lücke in der umstrittenen Komponente eingestehen. Die neuerliche Lücke, auf die externe Sicherheitsforscher Intel hingewiesen hatten, hat Intel nun nach einer internen tiefgreifenden Sicherheitsüberprüfung der Intel Management Engine (ME), Intel Server Platform Services (SPS) und der Intel Trusted Execution Engine (TXE) bestätigt. Zur Schwere der Lücke sagt Intel:

    »Auf Grundlage der durch die umfassende Sicherheitsüberprüfung identifizierten Elemente könnte ein Angreifer unbefugten Zugriff auf Intel ME-Funktionen und die Geheimnisse Dritter erlangen, die durch die Intel Management Engine (ME), den Intel Server Platform Service (SPS) oder die Intel Trusted Execution Engine (TXE) geschützt sind. Dazu gehören Szenarien, in denen ein erfolgreicher Angreifer folgendes tun könnte: Imitieren der ME/SPS/TXE, wodurch die Gültigkeit der lokalen Sicherheitsmerkmale beeinträchtigt würden; Laden und Ausführen von beliebigem Code außerhalb des Wahrnehmungsbereichs des Benutzers und des Betriebssystems; Verursachen eines Systemabsturzes oder einer Systeminstabilität.«

    Fast alle Plattformen betroffen

    Dabei sind fast alle Plattformen, die Intel in den letzten Jahren veröffentlicht hat, betroffen. Jeder Rechner mit Intel-Core-Prozessoren der Generatikonen 6, 7 und 8 ist betroffen. Die Liste umfasst Intel Core, Intel Xeon E3-1200 v5 und v6, Xeon Processor Scalable, Xeon Processor W, Atom C3000, Apollo Lake-basierte Atom oder Pentium, sowie Celeron N oder J.

    Schutz der Anwender dauert noch

    Intel hat zwar die Lücken mittlerweile geschlossen, trotzdem wird es noch einige Zeit dauern, bis die Anwender dadurch geschützt werden. Der Microcode, der die Lücken stopft wird über Firmware-Updates ausgeliefert, die von den Mainboard-Herstellern integriert und verteilt werden. Ältere Systeme werden von solchen Fixes oft gar nicht mehr erreicht.

    Verstecktes Betriebssystem

    Angesichts der erneuten Lücke sieht sich Intel wieder mit Forderungen konfrontiert, IME für den Anwender abschaltbar zu gestalten oder einen externen Sicherheits-Audit zu erlauben. Die Management Engine (IME), die beim Booten, zur Laufzeit und im Schlafmodus aktiv ist, wird über die permanente 5-V-Versorgung aus dem Netzteil gespeist. Die Firmware ist eine von Intel kryptografisch signierte Binärdatei. Die IME ist nicht durchgehend dokumentiert. Somit führt die CPU im Rahmen der ME unbekannten und nicht nachprüfbaren Code aus, auf die der Käufer von Intels CPUs keinerlei Einfluss hat.

     

  • Intel: BIOS-Unterstützung soll 2020 enden

    BIOS-Unterstützung
    Bild: uefi.org

     

    Das herkömmliche BIOS, das Basic Input/Output System, soll es nach Plänen von Intel ab dem Jahr 2020 nicht mehr geben. Die Firmware zum Starten von x86-PCs wird dann ausschließlich durch UEFI 3.0 repräsentiert, was für Unified Extensible Firmware Interface steht, Ab Version 3.0 wird das herkömmliche BIOS nicht mehr unterstützt. Das geht aus einer Präsentation (PDF) hervor, die Intel-Entwickler Brian Richardson kürzlich als Grundlage eines Vortrags benutzte. Richardson hat seine gesamte Karriere mit der Arbeit an BIOS-Firmware verbracht und arbeitet jetzt an UEFI.

    Kein BIOS mehr mit UEFI Class 3

    Die jetzige UEFI Spezifikation 2.5 ermöglicht noch die Verwendung des Legacy-Bios, was auch die allermeisten Hersteller auf ihren Mainboads anbieten. Dort besteht meist die Wahl zwischen BIOS, UEFI oder beidem als Einstellung. Mit einer dieser Vorgaben lassen sich die allermeisten Linux-Distributionen starten. Mit UEFI 3.0 soll es diese Wahlmöglichkeit nicht mehr geben. Damit fällt eine Möglichkeit weg, Linux-Distributionen mit einer seit langem bekannten, vergleichsweise einfachen und gut verstandenen Technik zu booten. Das hat Linus Torvalds bereits vor über zehn Jahren treffend formuliert: BIOS ist nur ein Bootloader und so hässlich, dass niemand auf die Idee kommt, daraus etwas anderes machen zu wollen.

    Mehr Nachteile

    Sicher bietet UEFI auch Vorteile, aber es sind vermutlich nicht die, die Richardson in seinem Papier hervorhebt. Wenn er von mehr Sicherheit spricht, meint Intel damit wohl eher mehr Kontrolle. Und dass die Ausgabe eines Compilers, denn nichts anderes ist UEFI, platzsparender sein soll als handgeschriebener Assembler-Code wie beim BIOS ist auch nicht unbedingt glaubwürdig. Ein Vorteil für den Endanwender ist da eher die einfachere Möglichkeit, Updates der UEFI-Firmware einzuspielen. Unverändert wird es nach jetzigem Stand die Möglichkeit geben, Rechner mit oder ohne Secure Boot zu betreiben.