Gefährliche Sicherheitslücken in UEFI-Firmware – ThinkPad BIOS Updates von Lenovo

Nein, wie schon am 16.9. geschrieben, bedeutet "lokaler Zugriff" in diesem Kontext, dass ein Angreifer auf deinem Rechner Programme starten können muss, also auf ihm eingeloggt ist.
Im Gegensatz dazu wäre "Fernzugriff", wenn er, ohne auf deinem Rechner eingeloggt zu sein, einen von deinem Rechner im Netzwerk angebotenen Dienst für seinen Angriff nutzt.

In der Praxis wird eine Schwachstelle in einem Fernzugriffsdienst oft als Hebel benutzt, um sich "lokalen Zugriff" zu verschaffen, womit dann weitere Angriffsszenarien möglich werden.
Der Hinweis auf den lokalen Zugriff in dieser Meldung bedeutet also im Wesentlichen, dass ein Angreifer noch eine weitere Schwachstelle (mit Fernzugriff) braucht, um die hier behandelten "lokalen" Schwachstellen tatsächlich nutzen zu können.
 
hikaru schrieb:
dass ein Angreifer noch eine weitere Schwachstelle (mit Fernzugriff) braucht, um die hier behandelten "lokalen" Schwachstellen tatsächlich nutzen zu können.
Zum Vergrößern anklicken....
Den lokalen Zugriff geben leider viele auch, wenn Sie einen "Anruf von Microsoft" erhalten. Da braucht es dann keine Schwachstelle im Fernzugriff....

Leider alles schon direkt live erlebt bei Kunden
 
Doch, da ist die Schwachstelle dan eben auf Layer 8. ;)
 

Und es geht weiter (Stand: 12.04.23):​

Warten auf Sicherheitspatches: BIOS-Lücken gefährden Lenovo-Laptops​

www.heise.de

Warten auf Sicherheitspatches: BIOS-Lücken gefährden Lenovo-Laptops

Angreifer könnten Lenovo-Laptops attackieren und im schlimmsten Fall Schadcode ausführen. Updates sind noch nicht verfügbar.
www.heise.de www.heise.de

Angreifer könnten Lenovo-Laptops attackieren und im schlimmsten Fall Schadcode ausführen. Updates sind noch nicht verfügbar.
 
Der 8. August 2023 ist ein Microsoft Patch Tuesday, vielleicht hängt das damit zusammen.
 
heise.de in seiner Meldung:
Sechs Sicherheitslücken im BIOS-Code vom UEFI-Systemfirmware-Entwickler Insyde […] Viele Informationen zu den Lücken gibt es derzeit nicht. […] Sicherheitspatches erst am 8. August 2023.
Zum Vergrößern anklicken....
Was für eine Kack-Firma, InsydeH2O.
Die haben eine eigene Webseite für die Auflistung ihrer Sicherheitslücken. Zu den bei Heise genannten sind mittlerweile noch zwei dazugekommen, CVE-2021-38578 und CVE-2021-38575, letztere "remotely exploitable buffer overflows" und beide mit einem Score-Wert von über 8, beide aus dem Jahr 2021. 2021!!
Am 1. Februar letztes Jahr hat InsydeH2O 19 Sicherheitslücken auf seiner "pledge"-Seite ("We support you, our customers and partners, in closing the door to anything which compromises the security or privacy in your platforms. We take this role seriously, […]") gebeichtet (Heise berichtete), am 8. Nov. 2022 16 Lücken, und am 14. Februar dieses Jahr 12 Lücken. Das sind nur die größeren Listen, kleinere sind immer dazwischen.

Leute, flasht euch Coreboot auf den Rechner! Das, was sich InsydeH2O (hier im Verbund mit Lenovo) leistet, ist meiner Ansicht nach nicht tolerierbar.

Auch Coreboot ist natürlich nicht prinzipiell vor Sicherheitslücken gefeit. Der Unterschied zu diesem InsydeH2O-Closed-Source-Geschwür liegt aber nicht nur in der um Dimensionen geringeren Komplexität des Codes, er liegt nicht nur darin, dass jeder prinzipiell selbst sein Coreboot aus offenen Quellen kompilieren kann, er liegt hauptsächlich darin, dass bei Coreboot wirklich innerhalb kürzester Zeit ein valider Patch bereitsteht – wenn doch mal eine Sicherheitslücke auftaucht.
Ich habe das in einem anderen Thread – hier – ausführlicher behandelt. Und hier habe ich einiges Grundsätzliche zum Thema UEFI und dessen aus dem Ruder laufender Komplexität geschrieben – und was das mit "Sicherheit" zu tun hat.
 
Danke für eure Expertise und die Hintergrundbeleuchtung durch xxxx
 
xxxx schrieb:
Leute, flasht euch Coreboot auf den Rechner! Das, was sich InsydeH2O (hier im Verbund mit Lenovo) leistet, ist meiner Ansicht nach nicht tolerierbar.
Zum Vergrößern anklicken....
Mal abgesehen von der Programmier-Hardware und den fortgeschrittenen Kenntnissen, die man fürs Flashen braucht, holt man sich damit neue Fehler, die keiner braucht - und die anscheinend auch nicht gefixt werden:
 
linrunner schrieb:
Mal abgesehen von der Programmier-Hardware und den fortgeschrittenen Kenntnissen, die man fürs Flashen braucht, holt man sich damit neue Fehler, die keiner braucht - und die anscheinend auch nicht gefixt werden:
Zum Vergrößern anklicken....
Das sind ja nicht die einzigen Bugs – wer sich bei Coreboot in die Mailing-Liste einträgt (und diese verfolgt), bekommt einen Eindruck davon, an wie vielen Stellen gearbeitet wird, und wie viele Fehler, Ungereimtheiten und Inkompatibilitäten – fast täglich – neu auftauchen (und natürlich: wie viele Plattformen/Boards aktuell aktiv unterstützt werden).
Vor allem kann man dann auch nachvollziehen, dass da nicht nur einige wenige versprengte Figuren in ihrer Freizeit tätig sind (ja, die auch, und davon nicht nur vereinzelt ziemlich gute Entwickler) – sondern auch Festangestellte bei großen Firmen (u.a. Google & Facebook) dafür bezahlt werden, dass mit Coreboot wirklich gute Opensource-Software (weiter-) entwickelt wird.

Natürlich kann ich Dich, @linrunner, gut verstehen, dass es nervt, wenn eine Funktion nicht verfügbar ist, die man braucht/gerne hätte, und der Eindruck entsteht, dass es dort nicht vorangeht.

Aber das ist beim Linux-Kernel kein bisschen anders (z.B. dümpelt ein ärgerlicher Bug in cryptsetup-suspend [Aufwachen aus dem Ruhezustand bei mit einer GPG-Smartcard verschlüsselten LUKS-Festplatte funktioniert nicht] schon seit anderthalb Jahren vor sich hin, ohne dass etwas passiert).

Und trotzdem – das ist mein Argument – wird deshalb niemand sagen: "Finger weg von Linux, das ist prinzipiell unsicher, da gibt es einen Bug in crypsetup-suspend, der nicht gefixt wird".
(Das dürfte für Dich aber nichts Neues sein, @linrunner, Du bist ja selbst in der Opensource-Szene aktiv.)


(Kleine Randbemerkung: Wenn ein Akku unter Coreboot nicht/korrekt erkannt wird, ist das ärgerlich, und es wird Nutzer davon abhalten, Corebooot zu nutzen, was wirklich schade ist. Aber sicherheitsrelevant ist das nicht.
Wenn man sich hingegen die ellenlange Liste nur der bekannten, durchaus sicherheitsrelevanten Fehler in aktuellen UEFI-Implementierungen anschaut; Fehler, die zum Teil seit Jahren bekannt sind und nicht behoben werden: dann ist das Nicht-Beheben dieser Fehler nicht einfach nur irgendwie schade, sondern eine nicht hinnehmbare Fehlentscheidung aus niederen Motiven mit potentiell katastrophalen Folgen für jeden, auf dessen Rechner UEFI läuft. Also für fast alle von uns, die einen Rechner nutzen. – So komme ich zu meiner Einschätzung der Firmenpolitik u.a. von InsydeH2O.)
 
Ich bin kein Cyber Security Experte, aber LogoFAIL hört sich nach ner Menge Kopfschmerzen an. Ich mein ich bin mittlerweile soweit zu sagen, wenn die Maschine Legacy Boot unterstützt dann setzte ich sicherheitshalber lieber auf diese Karte. Die Nachteile von Uefi überwiegen doch die Vorteile, wenn sie sich nicht mehr die Waage halten..
Arstechnica
Linuxnews
 
Bei der Abwägung sollte man weitere Gesichtspunkte berücksichtigen:
  1. Den UEFI Boot deaktivieren bedeutet, dass man keine BIOS und Firmware Updates mehr einspielen kann, die benötigen nämlich zwingend UEFI Boot
  2. Gehöre ich wirklich zu einer Zielgruppe für einen solchen Angriff? Kriminelle die Ransomware verwenden, um breite Opferschichten zu infizieren, erreichen ihre Ziele auf einfacheren Wegen. Handelt es sich um Rechner mit sehr hohem Schutzbedarf, sprich solche die für Spione interessant sind, sieht die Gleichung natürlich anders aus.
  3. Um unter Linux LogoFAIL zu nutzen, braucht man erst einen Remote-, dann einen Root-Exploit - alternativ natürlich auch physischen Zugriff auf die Maschine ("Evil Maid"), um auf die EFI-Partition zu schreiben. Wenn man die hat, gibt es wiederum einfachere Möglichkeiten Schaden anzurichten.
  4. Bei vielen Linux-Installationen ist Secure Boot deaktiviert, so dass gar kein LogoFAIL-Exploit benötigt wird um Schaden anzurichten (siehe 3.).
  5. Wer sagt, dass ein UEFI BIOS, wenn es nur per CSM bootet, keine Angriffsfläche bietet?
Mir persönlich reicht 1. um weiter UEFI zu verwenden. Der Autor bei ARS Technics schreibt z.B.
The best way to prevent LogoFAIL attacks is to install the UEFI security updates that are being released as part of Wednesday’s coordinated disclosure process.
Zum Vergrößern anklicken....
Die c't schreibt zu dem Thema:
www.heise.de

Löcher im Unterbau

Alle paar Wochen tauchen neue BIOS-Sicherheitslücken auf. Doch die meisten älteren PCs, Notebooks und gebrauchten Computer erhalten keine BIOS-Updates mehr. Es stellt sich die Frage, wie unsicher solche Rechner sind – wir versuchen eine Antwort.
www.heise.de www.heise.de
Attacken auf BIOS-Sicherheitslücken sind kein bloßer Mythos, aber glücklicherweise selten. Bei Windows-Rechnern stellt das BIOS ein relativ kleines zusätzliches Sicherheitsrisiko dar. Denn in Betriebssystem und Anwendungssoftware klaffen viel häufiger Lücken, die sich zudem leichter für Angriffe missbrauchen lassen.
Zum Vergrößern anklicken....
Speichert ein PC besonders schützenswerte Daten, sollte man auf Firmware-Updates achten.
Zum Vergrößern anklicken....
Für mein P14s Gen 2 AMD ist ein Update für den 29.12. angekündigt, fürs X1C Gen 6 ist eines im LVFS Testing Zweig unterwegs. Einfach mal die Tabelle checken und Ruhe bewahren.

BIOS Image Parsing Function Vulnerabilities (LogoFAIL) - Lenovo Support US

support.lenovo.com support.lenovo.com
 
Zuletzt bearbeitet:
Coreboot ist ja nett, aber für kein einziges meiner Thinkpads verfügbar. Ich hatte mal ein T60 mit Libreboot (das war sehr gut), aber für X61/T61 gab's nie was und ab mein ältestes jüngeres ist T460s - dafür gibt's auch keines (und nicht für T470, T480 ...) - also leider kein Gück.
 
linrunner schrieb:
Um unter Linux LogoFAIL zu nutzen, braucht man erst einen Remote-, dann einen Root-Exploit - alternativ natürlich auch physischen Zugriff auf die Maschine ("Evil Maid"), um auf die EFI-Partition zu schreiben. Wenn man die hat, gibt es wiederum einfachere Möglichkeiten Schaden anzurichten.
Zum Vergrößern anklicken....
Was ist wenn noch kein OS auf der Maschine installiert ist und ergo auch keine EFI Partition vorhanden ist? Kann man den Exploit nur auf bereits installierten Systemen anwenden? Remote und dann noch Root Zugriff? Hier ist das Proof of Concept von Binarly gut zu sehen, wie es unter Windows exploitet wird.

Ich stimme dir zu, dass ungepatchedte, nicht oder nur unregelmäßig aktualisierte Software eine viel größere Angriffsfläche anbietet als LogoFail, aber da es bei dem Thread hier ja nun mal um U-EFI geht, ist es auch ein anderes Thema das mitnichten weniger wichtig ist als die Dinge die sich weiter oben im userspace abspielen. Ich halte den Bootvorgang eines Systems für überaus kritisch und noch schützenswerter als die Dinge die man als user handhaben kann. Denn seien wir mal ehrlich, OS und Programm Updates sollte man irgendwann für sich abgefrühstückt haben und bedürfen nicht mehr als eine Erwähnung in der Fußnote.

Wenn wir aber an die echten Buletten rangehen, dann kommen wir in gefährliches Fahrwasser. Und ja BIOS ist sicher nicht ohne sein Schwächen, allerdings habe ich das Gefühl dass es zumindest ausgereifter ist, als das immer noch sehr wackelige UEFI...Die 1-Millionen Frage ist letztlic doch: Sollte nicht gerade eben so eine "Unified" Systemumgebung i.e. System-Fimware quelloffen sein? Wie viele Zeilen Code kann uefi beheimaten, bevor es zu überladen wird?
 
Ambrosius schrieb:
Ich halte den Bootvorgang eines Systems für überaus kritisch und noch schützenswerter als die Dinge die man als user handhaben kann.
Zum Vergrößern anklicken....

Trotzdem willst du genau die Funktionen, die ihn sicherer machen, abschalten.

Ambrosius schrieb:
Wenn wir aber an die echten Buletten rangehen, dann kommen wir in gefährliches Fahrwasser. Und ja BIOS ist sicher nicht ohne sein Schwächen, allerdings habe ich das Gefühl dass es zumindest ausgereifter ist, als das immer noch sehr wackelige UEFI...
Zum Vergrößern anklicken....

Das letzte reine BIOS dürfte auf Systemen von 2011 zu finden sein. Natürlich finden sich da keine keine Sicherheitslücken. Niemand sucht danach bei historischer Hardware. Und warum sollte man auch suchen? Es gibt beim klassischen BIOS quasi keinerlei Sicherheit. Es gibt halt weniger Funktionen, aber jegliche Funktionen in Richtung Sicherheit sind eher "security by obscurity".
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben