ubuntuusers.de

Hallo zusammen!

Heise.de hat gestern eine ziemlich beunruhigende Sicherheitslücke der debian-basierten Systeme einschl. Ubuntu aufgedeckt. Offenbar kommt man auf die Notfallshell, wenn man bei der Passworteingabe der eigentlichen Shell Enter etwa 70 Sekunden gedrückt hält:

http://m.heise.de/newsticker/meldung/Enter-Taste-verschafft-Angreifern-Root-Rechte-auf-verschluesselten-Systemen-3466574.html?wt_ref=android-app%3A%2F%2Fcom.google.android.apps.plus%2Fhttps%2Fplus.url.google.com%2Fmobileapp&wt_t=1479313431125&_utm_source=1-2-2

Umgehen kann man das entweder mit dem dort vorgestellten Patch oder/und mit der Grub-Einstellung panic=5

Liebe Grüße

Yrwyddfa

PS: dieser Entry ist in der Grub-config als Workaround getestet worden:

1

GRUB_CMDLINE_LINUX="console=tty1 BOOT_DEBUG=2 ignore_loglevel panic=5"

Wobei man an keinerlei verschlüsselte Daten kommt.

Die Gefahr ist also genauso hoch wie bei jeder anderen Möglichkeit des physischen Zugriffs auf ein verschlüsseltes System, denn die genannten "Gefährdungsszenarien" (Kopieren der verschlüsselten Partitionen) existieren genauso von jedem Livesystem aus.

Aus dem selben Artikel:

Ein Angreifer kann auf diese Weise zwar auf das System zugreifen, die verschlüsselten Partitionen kann er ohne Kenntnis der passenden Passphrase jedoch weiterhin nicht entschlüsseln. Eine solche Root-Shell kann sich ein Angreifer in vielen Fällen auch dann verschaffen, wenn er von einem mitgebrachten Medium bootet.

Das dürfte wohl auf die meisten Rechner zutreffen. Wenn ich deinen PC in die Finger bekomme, oder deine Festplatte klaue komme ich genauso weit, auch ohne Bug.

Aber interessant, wie sich das liest ☺

yrwyddfa schrieb:

Offenbar kommt man auf die Notfallshell, wenn man bei der Passworteingabe der eigentlichen Shell Enter etwa 70 Sekunden gedrückt hält

Was in etwa genau so gravierend ist, wie ein init=/bin/bash oder das starten eines Live-Mediums oder…

Merke: Physischer Zugang zu einem Gerät ist generell ziemlich blöd, was solche Themen angeht, wobei die Verschlüsselung ja bestehen bleibt und man nicht an die Daten kommt.

yrwyddfa schrieb:

Heise.de hat gestern eine ziemlich beunruhigende Sicherheitslücke der debian-basierten Systeme einschl. Ubuntu aufgedeckt.

Nein.

Das ist keine Sicherheitslücke.

Scheinbar hat Heise finanzielle Probleme wenn es solchen technisch unqualifizierten Clickbait auslegen muss.

Offenbar kommt man auf die Notfallshell

Wie der Name schon impliziert... diese Shell ist ein Feature.

Derlei "Sicherheitslücken" gibts wie Sand am Meer. Man kann einfach so eine LiveCD booten und dort dann auch Root sein. Man kann die Grub Shell mit init=/bin/sh beglücken. Undsoweiterundosofort.

Bei Maschinen mit besonderen Anforderungen (Kiosk, Internetcafe, ...) ist es was anderes aber da kommt man allgemein mit der Standardinstallation nicht weit.

Ein Hebel um solche Features abschalten zu können ist natürlich trotzdem nicht verkehrt.

frostschutz schrieb:

Scheinbar hat Heise finanzielle Probleme wenn es solchen technisch unqualifizierten Clickbait auslegen muss.

Heise hat darüber berichtet - was wohl ihr Job ist. Und inhaltlich ist der Artikel ja auch nicht falsch, sie behaupten ja nicht mal selbst, dass das ein größeres "Risiko" als beim Zugriff von Livesystemen darstellen würde.

Das "Sicherheitsleck" ist ja hier beschrieben.

yrwyddfa schrieb:

PS: dieser Entry ist in der Grub-config als Workaround getestet worden:

1	GRUB_CMDLINE_LINUX="console=tty1 BOOT_DEBUG=2 ignore_loglevel panic=5"

Ich verstehe jetzt gerade nicht, was daran ein Workaround sein soll.

Jeder, der Zugriff auf das Gerät hat, kann im GRUB-Auswahlmenü die E-Taste drücken und die Option wieder entfernen.

tomtomtom schrieb:

Das "Sicherheitsleck" ist ja hier beschrieben.

Ja, und ist totaler Quatsch.

Und der Patch (while true; do sleep 100; done) ist ein schlechter Witz.

Viel Lärm um nichts.

frostschutz schrieb:

Und der Patch (while true; do sleep 100; done) ist ein schlechter Witz.

Viel Lärm um nichts.

ACK.

yrwyddfa schrieb:

Heise.de hat gestern eine ziemlich beunruhigende Sicherheitslücke ...

...die so ziemlich beruhigendste Lücke, die man sich vorstellen kann. Denn was kann der Angreifer mit so einer Shell anfangen? Damit die Shell einen echten Mehrwehrt, wenn folgende Situationen und Motive des Angreifers zusammenkommen:

1. Auf dem Rechner sind Daten, die für einen Angreifer relevant sind

2. Der Rechner steht an einem öffentlichen Ort (widerspricht i.d.R. Punkt 1)

3. Der vielversprechendste Weg an die Daten geht darüber, die Verschlüsselung zu knacken und nicht etwa, sie z.B. übers Netzwerk abzugreifen.

4. Die Passworteingabe erfolgt vom Besitzer nicht physisch. Dann nämlich wäre es deutlich einfacher, ihm einfach über die Schulter zu schauen. Stattdessen wird z.B. SSH im Initramfs eingesetzt

5. Das mittelfristige Ziel des Angreifers ist es, den LUKS-Header zu kopieren, um darauf - auf dem eigenen System - eine Brute-Force-Attacke zu fahren.

6. Er kann im aktuellen Setup nicht von einem externen Medium booten, um dieses Ziel zu erreichen.

7. Er hat aber dennoch Zugang zu einem USB-Steckplatz oder einem DVD-Laufwerk, auf das er den Header kopieren könnte oder

8. im Initramfs ist ein Netzwerkstack mit einkompiliert (was man normalerweise nur tut, wenn man SSH verwendet, was dem bisherigen Anforderungsprofil widerspricht) und der Angreifer lädt dann über das enthaltene wget ein präpariertes Skript herunter, das den Header auf sein Zielsystem schickt

Wir reden also von einem Kiosk-System, auf dem sensible Daten generiert werden, das gegen physischen Zugriff gesichert ist, zum Beispiel, indem es in die Wand einbetoniert ist und bei dem es insbesondere keine Möglichkeit gibt, an die interne Festplatte zu kommen, bei der aber trotzdem Schnittstellen exponiert sind, über die eigene Datenträger einbinden kann. Und dann muss das System noch verschlüsselt sein und das Knacken der Verschlüsselung muss der sinnvollste Weg sein, um an die Daten zu kommen. Ich würde behaupten, ein solches System gibt es nicht.

unbuntuS12 schrieb:

… wenn folgende Situationen und Motive des Angreifers zusammenkommen: … Wir reden also von einem Kiosk-System, auf dem sensible Daten generiert werden, das gegen physischen Zugriff gesichert ist, zum Beispiel, indem es in die Wand einbetoniert ist … Und dann muss das System noch verschlüsselt sein und das Knacken der Verschlüsselung muss der sinnvollste Weg sein, um an die Daten zu kommen.

Und, wenn ich das richtig verstanden habe, muss der Angreifer den Rechner aus- und wiedereinschalten können…

Dazu schlug einer den FI-Schutzschalter als Auslöser vor. 😀 Ansonsten hatte ich das, ähnlich wie ihr auch hier, in x Themen dort zusammengefasst.

Wenn man den Recovery-Modus startet hat man doch den gleichen Zugriff auf das System, oder?

@lionlizard:

Stimmt, irgendwie muss der Angreifer ja eine Situation erzwingen, in der er überhaupt zur Eingabe des Passworts aufgefordert wird. Man müsste da mal ein Kunstprojekt draus machen.

novecento schrieb:

Wenn man den Recovery-Modus startet hat man doch den gleichen Zugriff auf das System, oder?

Definiere "Recovery-Modus" und "System". Für beide Begriffe kommen zwei Auslegungen infrage. Recovery-Modus des Ubuntu-Systems vs. Recovery-Modus (=Notfallshell) des Initramfs bzw. Ubuntu-System vs. Initramfs-System.

Wo man reinkommt, das ist die Notfallshell des initramfs. Aber das bringt ja wie beschrieben in realen Szenarien nix.