Seit einigen Tagen wissen wir, dass Bluetooth noch unsicherer ist als bisher angenommen. Dafür sorgte »BleedingTooth«, womit die Zusammenfassung dreier Lücken in BlueZ, dem Bluetooth-Stack von Linux, gemeint sind, die Sicherheitsforscher von Google und Intel kürzlich entdeckt haben.
Drei Bluetooth Lücken
Es handelt sich um drei Lücken, die als CVE-2020-24490, CVE-2020-12352 und CVE-2020-12351 katalogisiert sind. Während die ersten beiden Lücken als »moderate« eingestuft wurden, gilt CVE-2020-12351 beim Gefährdungspotenzial als »high«. Die Lücken sind im [wiki title=”CVSS”]CVSS Scoring System[/wiki] zwischen 7.1 und 8.3 bewertet. Die Lücken erlauben unter Umständen eine Rechteausweitung sowie das Einbringen und die Ausführung von Remote Code, ohne dass der Nutzer involviert ist.
Über das genaue Ausmaß gibt es unterschiedliche Aussagen, klar ist, dass sich ein Angreifer innerhalb der Reichweite des Geräts befinden muss. BleedingTooth wurde bereits im Sommer 2016 eingeschleppt und betrifft alle Kernel-Versionen seit 4.8. Für Linux 5.10 wurden Patches eingereicht, deren Integration für 5.9 derzeit vorbereitet werden.
Kritik an früher Veröffentlichung
Der bei Google angestellte bekannte Sicherheitsforscher Matthew Garrett kritisiert nun Intel für die verfrühte Veröffentlichung eines Security Advisories, bevor aktuelle Kernel und Distributionen Patches erhalten haben. Zum Zeitpunkt der Veröffentlichung gab es lediglich einen Patch für den im Dezember erwarteten Kernel 5.10, der aber noch nicht für aktuelle Kernel zurückportiert war. Eigentlich hätte der Patch im Mainline anstatt im Next-Branch eingereicht werden sollen. Bereits einmal in diesem Jahr hatte Intel laut Garrett eine Bluetooth-Lücke zu früh veröffentlicht, ohne die Distributionen zu informieren. Das habe er dann selbst getan.
Wie auf dem IT-Blog Marius Welt zu lesen ist, hat zumindest Fedora Kernel-Updates für die Kernel 5.8,14 und 5.8.15 gegen BleedingTooth verfügbar gemacht.
Ich frage mich gerade, wieviele Millionen Geräte zu diesem Problem kein Firmwareupdate kriegen werden…
Traurige Welt…
Komisch: Sonst machen sich Linuxer immer über Windows lustig, weil da alles im Geheimen abläuft. Doch keine so gute Idee, dieses öffentliche Programmieren, hm?
Es gibt eben gewisse Spielregeln an die sich auch Intel halten sollte. Die Sicherheitslücken von Closed Source haben dann wohl noch einen ganz anderen Hintergrund.
Und die aktuell gewünschte Spielregel ist „security by obscurity“? Notiert.
Nicht verstanden. Bei Windows wird kritisiert, dass es nur Microsoft weiß, was Du zu vergleichen meinst ist, dass es bei der genannten Spielregel erstmal nicht in der Öffentlichkeit breit getreten wird, bis die Entwickler einen “Stopfen” haben.
….aber ich glaube ich füttere hier nur den Tierpark 🙁
Gruß
Ist es nicht gerade der „Geist der Open Source“, dass die Öffentlichkeit Fehler im Code jederzeit selbst sehen kann?
Das man den Code sehen und darin enthaltene Fehler finden kann, wird auch nicht kritisiert. Wenn allerdings jemand eine schwerwiegende Sicherheitslücke findet, die sich für solche Angriffe nutzen lässt, ist es üblich, die Entwickler vertraulich darüber zu informieren und ihnen ~90 Tage zu geben, bevor man die Sache öffentlich macht. Andernfalls weist man nämlich auch Kriminelle auf die Sicherheitslücke hin, lange bevor es einen Patch gibt.
Kriminelle wissen üblicherweise ohnehin als Erste von Sicherheitslücken. Von einer späten Veröffentlichung haben somit nur die Nutzer Nachteile. Erschwerend kommt hinzu, dass die „übliche Vorgehensweise“ von open-source-feindlichen Konzernen wie Intel letztendlich auch vorsätzlich Nutzer von weniger werbewirksamen Systemen gefährdet, siehe Meltdown-Bug:
https://www.itwire.com/security/81338-handling-of-cpu-bug-disclosure-incredibly-bad-openbsd-s-de-raadt.html
Bei closed-source wissen halt nur die Kriminellen und die lieben Geheimdienste von den Sicherheitslücken, die sie dann Jahre bis Jahrzehnte nutzen können. Von all den absichtlichen Hintertüren mal ganz abgesehen. Hältst du das etwa für besser?
Ich halte beide Lösungen aus vorbezeichnetem Grund für außerordentlich beknackt.
Dann kannst du es wohl besser! 😉
Natürlich, weshalb ich das Vorgehen der Offenleger sehr begrüße.
Da Du so beharrlich diskutierst, bist Du ja vielleicht doch kein dummer Troll, sondern, naja … zumindest kein Troll …
FOSS: Jeder kann gucken, bei Fund von Sicherheitslücke an die Entwickler melden (ggf. schon mit Patch), später allen bekanntgeben – das ist die sicherst mögliche Art Software zu entwickeln und Sicherheitslücken zu melden/zu beheben/bekannt zu geben. Auch, wenn vorher schon einigen „Bösen“ bekannt. Dass dadurch alles sicher ist, bedeutet es leider nicht; auch nicht, dass die ursprünglichen Entwickler korrekt reagieren (sie können untätig bleiben oder (wie hier) zu früh rausposaunen); auch nicht, dass dadurch die Lücken automatisch gefunden werden oder zuerst von den „Guten“ gefunden werden.
Aber besser geht es nicht.
Traurig genug, wie leicht es ist, von der hiesigen „Community“ als „Troll“ abgetan zu werden. Einfach mal die falsche Frage stellen, schon hagelt es Däumchen runter. Als wäre das dann ein argumentativer Sieg!
Doch, es ginge besser: ein bekannt unsicheres Programm wird mit mehr Umsicht genutzt. Auch da könnte Transparenz also helfen.
Nein, ein Troll bist du nicht. Aber ein provokanter Querargumentierer schon.
Wenn du mit deiner kryptischen Mitteilung sagen wolltest, dass man Bluetooth insgesamt mehr Skepsis entgegenbringen sollte, dann hast du recht.
Eben nicht! Du kannst doch immer noch den Quellcode auditieren und Löcher finden, wenn du willst. Nur daß halt ein gemeldetes Loch nicht sofort öffentlich bekannt gegeben wird, sondern auf internen Listen gelöst wird. Macht schon Sinn, daß man nicht auch sofort, bevor man einen Fix hat, die Werbeindustrie das Einfallstor benutzen läßt.
Und im Gegensatz zu “security by obscurity” können hier Löcher gefunden werden. Ist der Quellcode nicht einsehbar, kann man nur mit trial&error versuchen, Löcher zu finden, oder by-accident. Und dieses Klientel wird wohl nur sehr unwahrscheinlich eine CVE melden… vermute ich mal.