Schlagwort: Intel

  • Debian schließt Intel-Lücken

    Debian schließt Intel-Lücken

    Debian schließt Intel-Lücken
    Screenshot: ft

    Debian weist im aktuellen Security Advisory DSA-4279-1 auf die Schließung der kürzlich unter der Bezeichnung Foreshadow beziehungsweise L1 Terminal Fault (L1TF) bekannt gewordenen Sicherheitslücken in Intel-CPUs hin. Die geschlossenen Lücken beziehen sich  auf die Kennnummern CVE-2018-3620 und CVE-2018-3646. Von den Lücken sind sowohl auf realer Hardware laufende als auch virtualisierte Systeme betroffen.

    Bereits länger bekannt

    Mehrere Forscher hatten die Schwachstellen in der Art, wie Intel-CPUs bei der spekulativen Ausführung von Anweisungen private Daten zugreifbar machen kann bereits vor Monaten entdeckt. Diese Fehler ähneln der Meltdown-Attacke und betreffen speziell die virtuelle Speicherverwaltung über Pagetables.

    Kernel und Microcode

    Um diese Schwachstellen vollständig zu schließen, ist es neben dem veröffentlichten Debian-Kernel 4.9.110-3+deb9u3 erforderlich, dass unter Debian »Stretch« der aktualisierte CPU-Microcode in Version 3.20180703.2~deb9u1 aus dem unfreien Repository non-free eingespielt wird. Dazu müssen Anwender kurzzeitig ihre Quellenliste erweitern. Dieser Microcode schließt durch Speculative Store Bypass Disable (SSBD) zusätzlich auch die Lücken Spectre Variante 3a und Variante 4 (CVE-2018-3639).

    Anwender von Debian Stable sind aufgerufen, die aktualisierten Pakete schnellstmöglich einzuspielen, um gegen die Lücken geschützt zu sein.

  • Intel bestätigt Gerüchte um diskrete Grafikkarte

     

     

     

     

    Diskrete Grafikkarte
    Bild: Graphikarte mit Intel i740 | Quelle: Wikimedia | Lizenz: GFDL

     

    In einem kurzen Promotion-Video, das anlässlich der SIGGRAPH2018 Konferenz veröffentlicht wurde, bestätigt Intel hartnäckige Gerüchte, der Konzern arbeite an einer diskreten Grafikkarte. In den letzten  Jahren hatte Intel Grafikkerne nur als Teil der CPU verkauft.

    Zunächst gescheitert

    Allerdings ist Intels Plan, eine selbstständige Grafikkarte zu vermarkten, nicht der erste Ausflug des Konzerns in diese Richtung. Bereits 1998, vor 20 Jahren, hat Intel einen diskreten Grafikchip auf den Markt gebracht. Dieser hörte auf den Namen Intel740, kurz  i740, trug den Codenamen Auburn und erlebte seinen zweiten Geburtstag nicht.

    AGP war schuld

    Der Chip, den Intel auf eigenen Karten anbot, wurde damals im 350nm-Prozess hergestellt – heute ist man bei 14nm – und bediente die AGP-Schnittstelle. Intel hatte gehofft, mit dem i740 den AGP-Port zu popularisieren, während die meisten Grafikanbieter noch PCI nutzten. Im Februar 1998 mit großem Aufwand für 34,50 US-Dollar auf den Markt gebracht, entsprach die Karte nicht der erwarteten Leistung und verschwand nach wenigen Monaten bereits wieder aus dem Fokus der Anwender. Im August 1999, nach weniger als 18 Monaten, zog Intel die i740 vom Markt zurück.

    Intel versuchte das Debakel abzumildern und entwarf verbesserte Versionen in Form der Chips  i752 und i754, die doppelte beziehungsweise vierfache AGP-Leistung brachten, hatte jedoch auch damit keinen Erfolg. Karten mit dem i752 erreichten den Markt, konnten die Leistung der i750 jedoch nur marginal verbessern. Die i754 wurde daraufhin erst gar nicht veröffentlicht. Die i752- und i754-Kerne wurden später für die integrierte Grafik in den Intel-Chipsätzen 810 und 815 verwendet. In späteren Analysen erhielt die AGP-Schnittstelle den schwarzen Peter.

    Zweiter Versuch

    Jetzt folgt also ein weiterer Anlauf von Intel in Sachen diskrete Grafikchips. Die derzeitigen HD-Grafik-Chips des Herstellers bieten 4K-Video und hardwareunterstütztes Video-Encoding, lassen aber einen großen Teil der Gamer und Grafikdesigner außen vor. Auch Data-Center und Artificial Intelligence (AI) kommen nicht ohne AMD oder Nvidia aus.

    Letztes Jahr gab es erste Hinweise auf Intels Pläne, als das Unternehmen den AMD-Vizepräsidenten und ehemaligen Apple-Grafik-Chef Raja Koduri als Vizepräsident und Chief Architect seiner Grafikabteilung anheuerte. Intel CEO Brian Krzanich verriet bereits im Juni, kurz vor seinem Ausscheiden, 2020 werde Intel in den Markt einsteigen.

    Wenig Details

    Krzanich ging nicht im Detail darauf ein, welches Leistungsniveau oder welchen Zielmarkt diese erste diskrete GPU-Lösung ansprechen soll, aber Intels Executive Vice President der Rechenzentrumsgruppe, Navin Shenoy, bestätigte, dass die Strategie des Unternehmens auch Lösungen für Rechenzentrumssegmente (Think AI, Machine Learning) umfassen wird. Für uns als Anwender kann es nur gut sein, wenn ein weiterer Anbieter den Markt der diskreten Grafikkarten betritt.

  • Foreshadow: Intel gibt weitere Spectre/Meltdown-Lücken bekannt

    Foreshadow
    Bild: Public Domain

    Intel hat drei neue Sicherheitslücken in den Prozessoren der Baureihen Skylake und Kaby Lake bekannt gegeben. Eine der Lücken wurde vor Monaten von Forschern entdeckt und bekam den Namen Foreshadow. Die beiden anderen Lücken entdeckte Intel selbst während der Untersuchung von Foreshadow. Intel bezeichnet die Lücken als L1 Terminal Fault (L1TF), da sie den Inhalt des Level-1-Cache der Prozessoren gefährden.  Die drei neuen Lücken wurden als CVE-2018-3615, CVE-2018-3620 und CVE-2018-3646 katalogisiert. Es sind davon nur Intel-Prozessoren betroffen.

    Foreshadow betrifft nur Intel

    Auch hier handelt es sich, wie bereits bei den anderen bekannten Spectre-Lücken, um Seitenkanal-Attacken. In einem Papier der Entdecker der ersten Lücken im Januar 2018 heißt es dazu, diese Angriffe veranlassten die CPU zu spekulativen Operationen, die während der korrekten Programmausführung so nicht stattfinden würden. Die so abgegriffenen Informationen werden dann über einen Seitenkanal exfiltriert.

    Tatort Pagetables

    Die neuen Lücken ähneln der Meltdown-Attacke und betreffen die virtuelle Speicherverwaltung über Seitentabellen. Diese Tabellen übernehmen die Zuweisung virtueller und realer Speicheradressen, denn in einem virtuellen Speichersystem zeigen die Speicheradressen, die sowohl vom Userspace als auch vom Kernel verwendet werden, nicht direkt auf den physischen Speicher.

    Bis zu 50 Prozent langsamer

    Besonders betroffen von den neuen Angriffsvektoren sind Cloud-Anbieter. Um sich gegen die neuen Angriffe zu schützen, reicht es nicht, auf Software-Ebene Patches einzuspielen. Es muss, wenn es um virtuelle Maschinen geht, auch das Hyperthreading abgeschaltet werden, da sich diese Threads teils den gleichen L1-Daten-Cache teilen. Das Abschalten kann zu großen Performance-Verlusten führt. Im Endeffekt wird Intel, wie bereits gehabt, neue Microcodes zur Verfügung stellen, um die Patches zu ergänzen.

    Die unbeabsichtigte Offenlegung von Speicherinhalten des Level-1-Datencache kann zwischen Userspace-Prozessen, zwischen Kernel und Userspace, zwischen virtuellen Maschinen und zwischen VMs und dem Gastsystem stattfinden.

    Kernel bereits gepatched

    Linus Torvalds hat den Linux-Kernel bereits gestern, zeitgleich mit Intels Bekanntgabe der Lücken, mit Patches gegen L1TF versehen. Neben dem im Oktober erwarteten Kernel 4.19 wurden die Patches von Greg Kroah-Hartman auch in die noch unterstützten Kernel-Versionen 4.18.1, 4.17.15, 4.14.63, 4.9.120 und 4.4.148 rückportiert.

    Die Distributionen arbeiten bereits an der Umsetzung auf die jeweiligen Distributionskernel. Red Hat hat sich sehr ausführlich zu L1TF geäußert. Im Ubuntu-Wiki gibt es ebenfalls ausführliche Informationen sowie Verweise auf bereits gepatchte Kernel. Auch auf Kernel.org selbst gibt es Informationen zu den Lücken.

  • Intel x86 – Sackgasse ohne Ausweg

    Intel x86 Bild: Hacker | Quelle: The Preiser Project | Lizenz: CC BY 2.0[/caption]

    Intels CPU-Sparte hat viele Probleme und es werden nicht weniger. Neben den Prozessorlücken Meltdown und Spectre, die tief im Silizium der Chips sitzen und fast im Wochentakt neue Angriffsvektoren offenbaren, entdecken Forscher auch immer wieder neue Sicherheitslücken in der Management Engine (ME) und der Active Management Technology (AMT). Aus Anwendersicht ist Intels x86-Schiene nichts weniger als eine Sackgasse.

    Volle Kontrolle

    Genauso wenig wie Meltdown und Spectre aus den derzeit verkauften Prozessorgenerationen entfernt werden kann, genauso wenig wird Intel jemals die Kontrolle über den ausgeführten Code in der ME aufgeben. Die Management Engine (ME), die beim Booten, zur Laufzeit und im Schlafmodus aktiv ist, wird über die permanente 5-V-Versorgung aus dem Netzteil gespeist und ist ein zusätzlicher Mikroprozessor, der in moderne Intel x86 CPUs eingebettet ist. Darin läuft ein Intel-signierter proprietärer Binär-Blob, der unter anderem über ein eigenes Betriebssystem und einen eigenen Webserver verfügt.Die ME hat direkten Zugriff auf das RAM, das Display, die Tastatur und das Netzwerk. Aufgrund der von der Hardware erzwungenen Code-Signing-Beschränkungen kann sie vom Benutzer nicht verändert oder ersetzt werden. AMD x86 CPUs haben übrigens einen ähnlichen Mikroprozessor, der auf den unverfänglichen Namen »Platform Security Processor«. Er ist auf genau die gleiche Weise abgeschottet.

    Löchriger Käse

    Die Sicherheitslücken in der ME sind ein Leckerbissen für jeden kriminellen Hacker, denn ein Eindringen in einen Rechner über die ME kann über lange Zeit unbemerkt bleiben. So wird zum Ausnutzen der aktuellen Lücke in der AMT nicht einmal mehr ein Admin-Account benötigt. Der Angriff kann nach Aussagen der Forscher von Positive Technologies ohne jede Autorisierung durchgeführt werden, wenn sich der Angreifer im gleichen Subnetz befindet.

    Besorgniserregende Technologie

    Als Anwender haben wir wenig bis keine Möglichkeiten, dem Bermudadreick Management Engine zu entkommen. Das hat die polnische Sicherheitsforscherin Joanna Rutkowska, die auch das Betriebssystem Qubes OS entwickelt, bereits 2015 in ihrem Essay Intel x86 considered harmful (PDF) als Fazit dargelegt.

    »Wir haben gesehen, dass Intel ME potenziell eine sehr besorgniserregende Technologie ist. Wir können nicht wissen, was alles wirklich in diesem Co-Prozessor ausgeführt wird, der immer eingeschaltet ist und der vollen Zugriff auf den Speicher unseres Hostsystems hat. Wir können ihn auch nicht deaktivieren. Wenn Du denkst, dass dies wie ein schlechter Witz klingt oder wie eine Szene, die von George Orwells Arbeit inspiriert ist, lieber Leser, dann bist Du nicht allein mit diesem Gedanken…« Joanna Rutkowska, Invisible Things Lab

    Ohne ME kein Booten

    In den letzten zwei Jahren haben einige Notebook-Hersteller wie Purism, System 76, Dell oder Tuxedo Computers daran gearbeitet, Intels ME zu neutralisieren und – einen Schritt weiter – zu deaktivieren.  Das ist ein sehr arbeit-intensives Unterfangen, an dem auch bei Google gearbeitet wird. Grundlegende Arbeit hat hier auch das Team von Positive Technologies geleistet. Die Entfernung gelingt bestenfalls zu rund 90 Prozent und Purism ist mit seinen Librem-Notebooks hier am weitesten fortgeschritten. Wird die ME völlig ausgeschaltet, hindert das den Rechner am Hochfahren. Also müssen einige Module der frühen Bootphase aktiv sein, um den Rechner überhaupt zu starten.

    Google gegen ME

    Google-Sicherheitsforscher Robert Minnich, der unter anderem auch an Linux Boot arbeitet,  geht davon aus, dass es viele Jahre dauern wird, bis die ME völlig unschädlich gemacht werden kann. Da man, ohne Aluhutträger zu sein, davon ausgehen kann, dass ME durch die NSA infiltriert ist, sind das keine rosigen Aussichten. Außerdem ist da noch das in Coreboot vorhandene Intel Firmware Support Package (FSP), das der Entschärfung bedarf.

    Träge Masse

    Dank der Trägheit der großen Masse der Computeranwender gibt es zu diesem Szenario wenig Alternativen. Genausowenig wie sich die Masse darum schert, welches Betriebssystem auf dem PC läuft, kümmert sie sich darum, wie sehr der Hersteller der CPU sie kontrollieren kann. AMD ist kein Ausweg und ist quasi durch Marktmacht gezwungen, diesen Weg mitzugehen.

    Kaum Alternativen zu Intel x86

    Alternative Plattformen wie ARM am Desktop existieren quasi nicht, Systeme, die dem Anwender die Kontrolle geben, sind in Preislagen angesiedelt, die sie für den Massenmarkt ungeeignet machen. Dazu gehören etwa Hersteller wie Raptor mit seinen Talos-Mainboards. Hier kommen Power9-CPUs zum Einsatz, die Preise für eine Workstation beginnen bei rund 3.000 Euro. Bleibt eigentlich nur, auf offene Plattformen wie RISC-V zu hoffen, die aber vom Erreichen des Massenmarkts noch viele Jahre entfernt sind. Keine rosigen Aussichten, oder?

  • Intel nennt neue Lücken Spectre 3a und 4

    Spectre 3a und 4
    Bild: Public Domain

     

    Die Anfang des Monats entdeckten acht neuen Sicherheitslücken in Intel-CPUs, die unter dem Sammelbegriff Spectre-NG eingeführt wurden, wurden von Intel damals bestätigt. Bei den von mehreren Forscherteams entdeckten Lücken schätzt der Hersteller die Hälfte als »hochriskant« und den Rest mit der Gefährlichkeitsstufe »mittel« ein. Jetzt wurden zwei der Lücken offiziell mit Spectre 3a und 4 bezeichnet. Die US-Sicherheitsbehörde US-Cert bezeichnet sie offiziell als Side-Channel Vulnerability Variants 3a und 4, nachdem Intel sie am Pfingstmontag öffentlich gemacht hatte. Die neuen Verwundbarkeiten ähneln denen von Spectre, indem sie auch durch Lücken in der spekulativen Ausführung ausgenutzt werden können.

    Nicht nur Intel

    Bei Variante 3a handelt es sich um die als CVE-2018-3640 kategorisierte und in ihrer Gefählichkeit als »moderate« eingestufte »Rogue System Register Read«-Lücke (RSRE). Variante 4, auch »Speculative Store Bypass« (SSB) genannt, trägt die Kennung CVE-2018-3639 und ist als »important« gekennzeichnet. Intel kündigte Updates an und erklärte, die beiden Lücken beträfen wiederum fast alle CPUs des Herstellers aus den letzten zehn Jahren. Damit nicht genug, sind auch Prozessoren von AMD, ARM und IBMs Power8, Power9 und System Z betroffen. Intel hat inzwischen eine Liste seiner betroffenen Prozessoren veröffentlicht. Auch AMD und ARM haben Stellung bezogen.

    Microcode-Updates in der Erprobung

    Wann die Updates verfügbar sind, hat Intel bisher ebenso wenig verraten wie die anderen Hersteller. Es ist lediglich bekannt, dass Microcode-Updates in Beta-Versionen vorliegen, die in den nächsten Monaten stabil verfügbar werden sollen. Die Linux-Kernel-Entwickler haben bereits gestern Patches für Kernel 4.17 eingereicht. So reichte Thomas Gleixner Patches gegen SSB ein. Über Nacht folgten Patches für die PowerPC-Plattform. Die Patches sollen nun auf die weiteren unterstützten Kernel-Versionen rückportiert werden. Allerdings wird eine weitestgehende Entschärfung der Lücken auch diesmal nicht ohne neue Microcodes gehen.

  • Intel: Keine neuen Microcodes gegen Spectre v2

    Microcode gegen Spectre
    Bild: Public Domain

     

    Intel hat in einem Update seines Papiers Microcode Revision Guidance (PDF) erklärt, die Arbeiten an Microcodes gegen die Spectre-v2-Sicherheitslücke seien beendet. Damit bleiben 10 Produktfamilien mit insgesamt mehr als 230 CPUs ungeschützt vor den im Januar bekannt gewordenen katastrophalen Sicherheitslücken Meltdown und Spectre. Das berichtet heute das Magazin The Register.

    Keine Microcodes gegen Spectre v2

    Das am 2. April herausgegebene Papier nennt die Familien Bloomfield, Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 und E0, Jasper Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield und Yorkfield Xeon. Darunter sind CPU der Reihen Xeon, Core-i, Pentium, Celeron und Atom. Auch die einst weit verbreiteten Core 2 Duo gehören dazu. Die ungepatcht verbleibenden CPUs für Desktops oder Notebooks sind alle sechs bis zehn Jahre alt.

    Intel nennt drei Gründe, warum CPUs einer dieser Familien nicht gepatched werden:

    • Mikroarchitektonische Merkmale, die eine technische Mitigation ausschließen, um Spectre v2 abzumildern
    • Eingeschränkte Unterstützung für kommerziell erhältliche Systemsoftware
    • Basierend auf den Eingaben der Kunden werden die meisten dieser Produkte als »geschlossene Systeme« implementiert und es wird daher eine geringere Wahrscheinlichkeit erwartet, dass sie diesen Schwachstellen ausgesetzt sind.

    Halbherziges Eingeständnis

    Intel gibt an, einer oder mehrere dieser Punkte könnten dazu führen, dass eine CPU nicht gepatched wird. Zum ersten Punkt, in dem Intel verklausuliert zugibt, dass seine Ingenieure bestimmte CPUs technisch nicht gepatched bekommen, macht der Konzern keine Angaben, um welche CPUs es sich dabei handelt. Eine gute Nachricht enthält der aktualisierte Report jedoch:  die Familien Arrandale, Clarkdale, Lynnfield, Nehalem und Westmere, die vorher nicht gepatcht wurden, haben jetzt funktionierende Korrekturen.

    Kernel-Entwickler weiterhin beschäftigt

    Für Intel scheint der Skandal um die Sicherheitslücken in den meisten CPUs der letzten 15 Jahre des Unternehmens abgeschlossen. Für die Linux-Kernel-Entwickler ist er das noch nicht. Die Patches direkt im Kernel halten die Entwickler immer noch in Atem. Der gerade erschienene Kernel 4.16 bringt weitere zusätzliche Patches gegen die insgesamt drei Schwachstellen.

    Die Überprüfung des Kernelcodes wird die Entwickler noch eine Weile beschäftigen. Mittlerweile wird die Suche nach Stellen, die für Spectre v1 anfällig sind, teilweise automatisiert. Dazu zählt die Identifizierung anfälliger Code-Abschnitte  und das Ersetzen des Array-Zugriffs durch die Funktion array_index_nospec() und damit die Abschaltung der spekulativen Ausführung.

  • Intel CEO gibt Stellungnahme zu Meltdown und Spectre

    Bild: „Intel“ von Christian Rasmussen Lizenz: CC By-SA 2.0
      Intels CEO Brian Krzanich hat eine schriftliche Stellungnahme zu den Sicherheitslücken Meltdown und Spectre abgegeben, die seit Jahresbeginn für viel Furore sorgten. Darin gab er bekannt, dass die veröffentlichten Aktualisierungen des Microcodes nun alle CPUs der letzten fünf Jahre zu 100 Prozent abdecken. In den letzten Tagen war eine neue Version des Microcodes freigegeben worden und ist beispielsweise in Debian Unstable mit der Versionsnummer 3.20180312.1 bereits ausgerollt worden. [su_slider source=“media: 4558″ link=“image“ width=“700″ height=“460″ arrows=“no“ mousewheel=“no“ autoplay=“0″ speed=“0″]

    Spectre v1 braucht trotzdem Microcode

    Die achte Generation von Intels Core-Architektur, die auf den Namen Coffee Lake hört, erhielt ein neues Stepping oder eine neue Revision, die die Angriffsvektoren von Meltdown (Rogue Data Cache Load) und Spectre v.2  (Branch Target Injection) gänzlich schließen sollen, so Krzanich. Allerdings benötigt die Abwehr von Angriffen über Spectre in Variante 1 (Bound Check Bypass) auch dann zusätzlich immer noch Microcode.

    »With these [microcode] updates now available, I encourage everyone to make sure they are always keeping their systems up-to-date. It’s one of the easiest ways to stay protected.« – BrianKrzanich

    Die achte Generation

    Da die 8th-Gen-Prozessoren bereits im Sommer letzten Jahres als »Coffee Lake« erschienen sind, ist hier nicht ganz klar, welche Desktop-Prozessoren  Krzanich damit meint. Vermutlich wird aber im Desktop-Segment Cascade Lake gemeint sein. Hier wird seit längerem über eine Core i9-8000-CPU als Nachfolger des Core i9-7000 gesprochen, der auch als Skylake-X bezeichnet wird. Diese neuen Prozessoren sollen »im Jahresverlauf« erscheinen. Auch und vor allem die Servervarianten Xeon Scalable (ebenfalls Cascade Lake) wurden bereits im Silizium gegen die Lücken gerüstet, was für Server besonders wichtig ist, da sie ein Hauptziel möglicher Angriffe darstellen.

    Fazit

    Somit bleibt zusammenzufassen: Bei CPUs für Desktop und Server, die ab 2018 auf den Markt kommen, sind die Lücken auf Silizium-Ebene geschlossen worden. Allerdings wird auch dort gegen Spectre v.1 immer noch Microcode gebraucht. Alle anderen CPUs der letzten fünf Jahre bleiben rein auf Software-Patches angewiesen. Meltdown sollte damit gut abgedeckt sein. Für Spectre v2 verwenden immer mehr Linux-Distributionen Googles Retpoline anstelle von Intels Microcode. Bei Googles Lösung fallen die Strafen in Form von langsamerer Code-Ausführung um einiges geringer aus. Wer noch ältere CPUs verwendet, bleibt von Intels Seite aus ungeschützt. Allerdings werden von Angriffen auf der Basis von Meltdown und Spectre kaum private PCs betroffen sein. Dazu ist der Aufwand viel zu hoch und der mögliche Gewinn zu klein.
  • Intel Microcode-Updates gegen Spectre v2

     

    Intel Microcode-Updates
    Quelle: Natascha Eibl Lizenz: CC0 1.0

     

    Intel hat weitere Microcode-Updates freigegeben, wie der aktualisierten Microcode Revision Guidance zu entnehmen ist. Dort listet Intel den jeweiligen Stand der Microcode-Updates zur Eindämmung von Meltdown und Spectre, den beiden CPU-Verwundbarkeiten, die Anfang des Jahres publik wurden. Änderungen seit der letzten Version des Papiers werden jeweils gelb hinterlegt. Braun hinterlegte Abschnitte sind noch in der Erprobungsphase.

    Skylake abgedeckt

    Anfang Februar hatte Intel überarbeitete Microcodes für Skylake-CPUs der Serien U, Y, H, S und U23e freigegeben, die sich gegen die Spectre Variante 2 richten. In der vergangenen Woche folgten dann korrigierte Codes für die Plattformen  Apollo Lake, Cherry View und Bay Trail. Die Microcodes für die älteren Plattformen Broadwell, Haswell, Sandy Bridge und Ivy Bridge verblieben noch in der Beta-Phase.

    Broadwell und Haswell nachgeliefert

    Jetzt wurden die überarbeiteten Microcodes für Broadwell- und Haswell-CPUs aus dem Beta-Status entlassen und gelten als stabil. Damit verbleiben die Prozessorgenerationen Sandy Bridge und Ivy Bridge als letzte in der Beta-Phase. Sie stellen auch die ältesten Generationen dar, die Gegenmaßnahmen gegen die Verwundbarkeiten erhalten. Die Überarbeitung der Microcodes war unter anderem dadurch nötig geworden, da mit im Januar ausgelieferten Microcodes Broadwell- und Haswell-CPUs spontane Neustarts der Hardware auslösten und daraufhin von Intel zurückgezogen wurden.

    [su_slider source=“media: 4318″ link=“image“ width=“700″ height=“460″ mousewheel=“no“ autoplay=“0″ speed=“0″]

    Linux am schnellsten versorgt

    Die Updates wurden bereits an Hersteller und OEMs ausgeliefert. Naturgemäß wird es eine Weile dauern bis diese als BIOS- oder Firmware-Updates bei den Endanwendern ankommen. Am schnellsten landen Intel Microcode-Updates wie auch die von AMD in der Regel bei Linux. Die meisten Distributionen liefern die Microcodes als Distributionspakete aus, die beim Start des Rechners in den Kernel geladen werden. Den Stand des jeweils erreichten Schutzes gegen die beiden Lücken können Linux-anwender mit dem Script Spectre-Meltdown-Checker überprüfen, das in einigen Distributionen, wie etwa bei Debian, auch als Paket im Archiv vorliegt. In der letzten Woche erhielt zudem auch OpenBSD Patches gegen Meltdown.

     

     

  • Intel rät von Microcode gegen Spectre ab

    Microcode gegen Spectre
    Bild: Public Domain

    Intel rät seit gestern offiziell von der Verbreitung und Verwendung des aktuellen Microcodes mit der Versionsnummer 20180108 ab. Die Firmware enthält hauptsächlich Maßnahmen gegen Spectre in Variante 2 mit der Kennung CVE-2017-5715. Bereits am 11. Januar hatte Intel bekannt gegeben, dass die aktuelle Version des Microcodes auf einigen Plattformen Probleme verursachen könne. Auf den CPU-Plattformen Broadwell und Haswell wurden spontane Reboots sowie insgesamt instabiles Verhalten beobachtet.

    Microcode gegen Spectre

    Daraufhin zogen einige OEM-Partner ihre dementsprechenden BIOS-Versionen vom Download zurück. In den letzten Tagen gingen auch Linux-Anbieter diesen Weg. Hier bedarf es keiner BIOS-Version, der Microcode kann direkt beim Start des Rechners geladen werden. Red Hat machte, gefolgt von Ableger CentOS  den Anfang, zog das Microcode-Paket zurück und verwies seine Kunden für weitere Aktualisierungen an die OEM-Partner.  Auch Ubuntu zog die aktuelle Version zurück, ersetzte sie allerdings gegen eine ältere Version vom Juli 2017. Mittlerweile setzte auch Debian bei Unstable die Version zurück auf  20171117.

    Torvalds kritisiert Intel

    Seit gestern rät nun auch Intel offiziell von der Verwendung der Firmware ab. Intel gibt gleichzeitig an, das Problem mittlerweile gelöst zu haben. Eine neue Version der Firmware werde bereits von Industriepartnern getestet. Intel entschuldigte sich für die Störungen, die durch den Microcode verursacht wurden. Auch bei Linus Torvalds steht Intel derzeit in der Kritik. Dieser äußerte sich am Wochenende mit drastischen Worten zu einer Patch-Serie, die Intel für Kernel 4.16 eingereicht hat. Er kritisiert, dass die Patches »absoluten Müll« enthalten und den Kernel schützen wollen, wo dieser durch Retpoline bereits mit weit weniger Overhead geschützt sei.

    Komplexe Materie

    Im Nachhinein betrachtet ist er damit wohl etwas über das Ziel hinausgeschossen. Das zeigt deutlich die Komplexität der Sachlage auf, wenn selbst Torvalds nach einem kurzen Review die Fakten verwechselt. Dave Woodward, der ehemals für Intel arbeitete und die Patch-Serie einreichte, versucht die komplizierte Sachlage etwas verständlicher darzustellen.

  • Weiterer Fehler in Intels AMT gefährdet Notebooks

    Intel AMT
    Bild: „Intel“ von Christian Rasmussen Lizenz: CC By-SA 2.0

     

    Das Jahr fing schlimm an für Intel. Und so geht es auch weiter. Nicht nur die Hardware, auch die Software scheint erneut mit heißer Nadel gestrickt zu sein. Finnische Sicherheitsforscher der Firma F-Secure beschreiben einen weiteren Fehler in Intels Active Management Technology (AMT), einem Bestandteil der mit reichlich negativen Schlagzeilen behafteten Intel Managment Engine.

    AMT wird in praktisch allen Desktops, Servern und Tablets, welche auf Intel vPro basieren, eingesetzt. Unter anderem sind dies die Intel-Core-i-Serien i3, i5, i7 und die Intel Xeon Prozessorfamilien. Unter Linux lässt sich recht einfach feststellen, ob AMT an Bord ist. Der Befehl lspci listet dann eine Zeile zu einem Communication Controller, die entweder die Kürzel HECI oder MEI enthält.

    Noch eine Lücke in Intels ME

    Zu den bereits bekannten Sicherheitsmängeln in Intels Active Management Technology (AMT) kommt nun eine weitere Lücke hinzu, die es Angreifern erlaubt, Anmeldeinformationen auf Firmen-Laptops zu umgehen. Wie F-Secure berichtet, erlauben unsichere Standardeinstellungen in Intel AMT es einem Eindringling, Benutzer- und BIOS-Passwörter sowie TPM- und Bitlocker-PINs vollständig zu umgehen und in 30 Sekunden in fast jeden Firmen-Laptop einzubrechen, wenn physischer Zugriff auf das Gerät besteht. Der neueste Fehler erhält seine Brisanz wegen der einfachen Ausnutzung. »Die Schwachstelle kann in Sekundenschnelle ohne eine einzige Codezeile ausgenutzt werden«  berichteten die Entdecker bei F-Secure.

    BIOS-Passwort verhindert den Angriff nicht

    Das Setzen eines BIOS-Passworts, das normalerweise verhindert, dass ein unbefugter Benutzer das Gerät hochfährt oder Änderungen an ihm vornimmt, verhindert laut F-Secure nicht den Zugriff auf die AMT-BIOS-Erweiterung. Dies ermöglicht einem Angreifer Zugriff auf die Konfiguration von AMT und ermöglicht unter Umständen die Fernausnutzung. Um die Lücke auszunutzen muss ein Angreifer lediglich den Zielcomputer einschalten und während des Bootvorgangs die Tastenkombination STRG+P drücken. Der Angreifer kann sich dann mit dem Standardpasswort admin in die Intel Management Engine BIOS Extension (MEBx) einloggen, sofern hier kein neues Passwort gesetzt wurde. Im BIOS findet sich unter Security oder Config eine Option, AMT anzuschalten.

    Laut F-Secure steht es dem Angreifer dann frei, das Standardkennwort zu ändern, den Fernzugriff zu aktivieren und das Benutzer-Opt-In von AMT auf None zu setzen.  Harry Sintonen, Senior Security Consultant bei F-Secure, schreibt der Lücke ein hohes zerstörerisches Potential zu, wenn er sagt: »In der Praxis kann es einem Angreifer die vollständige Kontrolle über den Arbeitslaptop eines Einzelnen geben, trotz der umfangreichsten Sicherheitsmaßnahmen.«

    Mit VPN-Support doppelt brisant

    Der Angriff fällt wegen der sehr kurzen Zeit, die er zur Ausführung braucht in die Kategorie »evil maid attacks«. Notebooks in Hotelzimmern, alleingelassene Laptops im Büro sind für solche Angriffe anfällig. Potenziert wird das Problem bei neueren CPUs, die per AMT über VPN-Support verfügen. Hier steht dem Angreifer schnell das Firmennetzwerk offen.

    Auch die Gerätehersteller in der Pflicht

    Das Problem wird dadurch befördert, dass viele Gerätehersteller nicht in Einklang mit Intels nach den letzten Lücken im November 2017 nochmals überarbeiteten Anleitung (PDF) vorgehen und das Passwort bereits vor der Auslieferung ändern oder AMT standardmäßig deaktivieren. Den meisten Anwendern entgeht bisher die Problematik, selbst in vielen Unternehmen nehmen die Administratoren hier keine Änderungen vor. Sintonen rät, die AMT völlig abzuschalten, falls diese Option im BIOS angeboten wird. Auf jeden Fall sollte sie mit einem sicheren Passwort versehen werden. Obwohl Privatanwender hier nicht völlig außen vor sind, wird diese Lücke vermutlich eher in Unternehmen und Organisationen ausgenutzt.