Nur blöd dass der Schlüssel irgendwo sein muss sonst schaut es sowohl mit einem remote-reboot als auch mit einer failover-lösung ggf. schlecht aus wenn der wichtige Server dann blöde da sitzt und nach dem Passwort für den Schlüssel fragt
Wenn ich aber mal in die grub-shell komme bin ich wesentlich näher daran an den Schlüssel zu kommen
Dein Posting klingt eher nach einem Wichtigtuer der mal gelesen hat "Ja man kann das rootfs verschlüsseln" aber so wirklich in der Praxis noch nie was mit IT zu tun hatte
"Ja. Weit weg vom System und am besten nur im Kopf" - Ja wenn es praktikabel ist, ist es aber nicht in jeder Umgebung und in jedem Anwendungsfall und Security besteht im wesentlichen darin so weit abdichten wie möglich ABER AUCH praktikabel, hab ich aber dem anderen Trottel auch eben erklärt
Wenn du Schlüssel und Schloss nebeneinander hast, dann hat das nichts mit Sicherheit zu tun. Für ein unnötiges Feature - wie das Fernstarten eines Laptops - einfach mal alle Sicherheit über Board werfen.... Ahoi Matrose! Das lob ich mir.
hab ich aber dem anderen Trottel auch eben erklärt
Wie bei den kleinen Kindern? Wenn man nicht Recht bekommt, dann wird mit den Füßen gestampft, geplärrt und die Luft angehalten.
"Für ein unnötiges Feature - wie das Fernstarten eines Laptops" -> Wer spricht von einem Laptop? Workstation != Laptop und was "unnötig" betrifft bist du schwerlich in der Position das zu beurteilen
Definiere nötig, klar wenn du eh dauernd im Büro anwesend sein musst mag es nicht nötig sein, es soll aber auch Leute geben die mal 2 Wochen nicht rein fahren müssen und zwischendurch doch mal was von der Maschine im Büro brauchen
"einfach mal alle Sicherheit über Board werfen" -> Schwachsinn, alle Sicherhit über Bord werfen wäre die Platte erst gar nicht zu verschlüsseln - Es geht darum es SCHWERER zu machen
Kapierst du nicht dass es einen Unterschied macht ob:
* Gar keine Verschlüsselung, Bootloader offen * Verschlüsselung, Bootloader offen * Verschlüsselung, Bootloader zu, Key auf der Maschine * Verschlüsseung, Key nicht vorhanden
Deswegen ist der Schlüssel, der beim Schloss liegt ist mit einem zusätzlichen Schlüssel (Passwort) verschlüsselt.
Das Spiel mit dem Schlüssel verschlüsseln kannst du ziemlich lange machen. Hilft halt nix, wenn zum Schluss das Passwort im Klartext auf der Platte liegt. Und das ist ja der Fall, wenn sein Pc ohne jegliche Eingabe komplett hochfahren kann.
Du kapierst es einfach nicht - ja er kann komplett hochfahren aber dann stehst du vor einem passwort prompt und das grub passwort stellt sicher dass du eben nicht einfach in eine Shell bootest
Wozu die Verschlüsselung dann dient?
Damit ich eine alte Platte einfach bedenkenlos wegwerfen kann weil /boot und somit der Key und alles was dazu gehört nicht auf dem selben Laufwerk liegen
und das grub passwort stellt sicher dass du eben nicht einfach in eine Shell bootest
Hoffentlich kommt niemand auf die Idee, dein BIOS zurückzusetzen und Grub über einen externen Datenträger zu booten - und damit dann in die Shell.
Wozu die Verschlüsselung dann dient?
Damit ich eine alte Platte einfach bedenkenlos wegwerfen kann weil /boot und somit der Key und alles was dazu gehört nicht auf dem selben Laufwerk liegen
Klar, ist ja auch der naheliegendste Grund für Verschlüsselung. Wäre auch zu einfach, die Platte mechanisch zu zerstören
Sir? Also wenn du deinen Schlüssel zum Entsperren auf dem gleichen Gerät, relativ einfach zugreifbar, gespeichert hast, dann hoffe ich, dass du nicht viel mit IT in der Praxis zu tun hast
Schwachkopf: 100% Sicherheit gibt es nicht, die setzt sich immer aus einem Haufen an Parametern zusammen die dann auch praktikabel sein müssen
Auf der Workstation im Büro die ich per VPN/WOL von zu Huse einschalte ist es wohl enig zielführend dann ins Taxi steigen und ein Passwort eingeben zu müssen
Es ist dort aber auch relativ unwahrscheinlich dass jemand in Ruhe Festplatten ausbauen kann ohne dass ihn jemandf fragt was er da macht und von USB/DVD booten oder Kernel-Parameter ändern ist nun mal nicht
Über den ungesicherten Bootloader umgehen und einen Backdoor installieren geht wesentlich unauffälliger weil schneller und ohne Lärm
Du hast keine Ahnung, wie man in der Praxis an ein solches Problem rangeht. Hier auf PL kannst du ruhig trollen, das finde ich noch ganz lustig haha. Aber mit der Realität hat das nichts zu tun.
Von Dr. Random am Fr, 18. Dezember 2015 um 22:09 #
sonst schaut es sowohl mit einem remote-reboot als auch mit einer failover-lösung ggf. schlecht aus wenn der wichtige Server dann blöde da sitzt und nach dem Passwort für den Schlüssel fragt
Hm.. meine Server, die in einem RZ stehen und weder IPMI, ILO, DRAC, geschweige denn eine serielle Konsole oder gar KVM haben, sind bis auf /boot luks-verschlüsselt. Beim (re-)boot startet dracut einen dropbear-sshd und gibt mir eine Shell. Dort lese ich /dev/console aus, gebe die Passphrase ein, logge mich aus und voilà: System ist up&running. Einer meiner anderen Server hat etwas ähnliches: SSDs als SED, und /boot auf einem USB-Stick. Auch hier: connect via dropbear, den dracut startet, ata unlock, rescan, fertig.
Automatischer Failover ist auch kein Problem, denn die Server im HA-Verbund laufen ja bereits.
Ja schön, es soll auch andere Umgebungen geben - Ändert nichts daran das "huhu was soll das bootloader passwort bringen" einfach nur geistiger Dünnschiss ist
Stellt euch einen Server arktischen vor, wo aus Wartungsgründen die Kisten neu gestartet werden. Der Admin rennt dann den ganzen Tag im Server um herum und gibt Passwörter ein *g*
Damit ist der Rechner bereits in der Hand des Angreifers.
Was er aber offensichtlich bereits zuvor war, sonst hätte er nicht an der Tastatur herumspielen können. Bei physischem Zugang zur Hardware hat der Angreifer eh freie Hand, wenn das Betriebssystem nicht gerade verschlüsselt ist.
Ähm es ist schon noch ein Unterschied ob ich die Festplatte ausbauen muss um irgendwas drauf zu bekommen oder mit eine Shell krallen kann wo ich binnen 20 Sekunden Malware installiere die beim booten einen Backdoor aufmacht
Wenn jemand nicht komplett blöde ist lässt sich die Maschine nicht von DVD/USB booten und sowhl BIOS als auch Bootloader erfordern ein Passwort um irgendwas das nicht vorgesehen ist zu starten
Ich gehöre zu dieser "sehr kleinen" Zahl von Nutzern, die diese Funktion nutzen — vor langer Zeit mal aus reiner Neugier ausprobiert und dann irgendwie einfach immer weiter mitgenommen und nie wieder abgeschaltet, auch wenn das Passwort nur ein Punkt ist. Mit 28-mal Backspace klappt es jedenfalls nicht, auch mit allem zwischen 16 und 40 nicht. Mehr Zeit zum Probieren habe ich gerade nicht, wie groß ist die Hardwareabhängigkeit dieser Spanne?
Von spaetschicht am Fr, 18. Dezember 2015 um 17:09 #
vermutlich hast du schon das update eingespielt^^
seit Gestern (17.12.2015) gibt es zumindest bei Red Hat und Debian schon Patches.
---
Der Bug trifft eigentlich nur Rechner, auf die physiklaisch Zugriff gewährt wird, bei Servern ist der Grub-Bug eh marginal. Bei Clients die nur durch dieses Grub-Passwort geschützt sind, empfinde ich ihn als ebenso marginal, da ja z.B. durch ein Life-System auch Zugriff erfolgen könnte....
m2c
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Dez 2015 um 17:11.
"da ja z.B. durch ein Life-System auch Zugriff erfolgen könnte...." - Bei dir vielleicht, überall anders wird sobald das OS installiert ist booten von externen Datenträgern komplett deaktiviert und sowhl BIOS als aus GRUB mit einem Passwort versehen
Was gab es da mehr zu quoten ausser der blödsinnigen Aussage man könnte einfach so ein Live-System booten nur weil die Kiste nicht auch noch verschlüsselt ist?
Schaut euch erst Star Wars 7 an, denn gehts euch besser...
Nee, jetzt geht es mir richtig mies, weil ich mit ansehen mußte, wie Jar Jar Abrams Star Wars verhunzt hat. IMHO der schlimmste Star Wars Film aller Zeit. Hat ja so rein garnichts mehr mit Star Wars zu tun.
War ja nach den beiden Action-Star Treks nicht anders zu erwarten.
> vermutlich hast du schon das update eingespielt^^
Da ist eine Suse 12.1 drauf — die wird nicht mehr gepflegt, soweit ich weiß. Der Rechner dient zur Heizungs- und Belüftungssteuerung und hat keinen Netzzugang. Hab' das Passwort aus der Konfiguration rausgenommen, sonst vergesse ich es noch (der letzte Reboot vor heute war am 2. Mai 2014).
Das kann passieren, da es ja etwas tricky ist in grup mit backspache und return 28 hinter einnander, wird ja ausführlich im bereicht der experten beschrieben und auch der fix, der ja eine weitere if abfrage nur ist.
Das eigendtiche Ding ist ja, das in 90 oder 80% der Installationen nicht das grup-password nutzt, viele nutzen es gar nicht und der recht nutzt das Bios passwd.
Das liegt auch daran, das oder wer zugriff auf ein lokalen Rechner hat eh viel machen kann, zb die Festplatte ausbauen oder eine andere live OS zu booten. Da hilft eher das man seine wichtigen Daten verschlüsselt.
Und prinzipiell gilt auch, kein System ist sicher.
Grub2 ist überhaupt tricky, verteilt die Konfigurationsdateien hirnloserweise gleich über mehrere /boot und /etc-Ordner, bläst die Syntax zum Booten so auf, das man sinnloserweise zu Files zu reinen Editierungszwecken umdirigiert wird, nur weil man glaubt, die hochheilige grub.cfg vor dem Nutzer wie Admin schützen zu müssen und kapiert einfach nicht, dass "er" nur Betriebssysteme starten, aber bitte selbst kein eigenes "Boot-Betriebssystem" sein soll.
Nun ist selbst diese Sicherheitslücke ebenso gestaltet, unübersichtlich in der "Anwendung" und offenbar in Abhängigkeit von jeweiligem Bios in immer wieder jeweils einer anderen Nuance ausnutzbar. Auch hier kostet Grub2 also nur Zeit. Man könnte fast meinen, dass es sich bei dieser Sicherheitslücke um eine Art Easter Egg handelt, daraufhin optimiert, den sicherheitslückenkundigen Cracker möglichst viel Zeit zu kosten, genauso wie das Originalprogramm Otto Normalnutzer endlos Zeit und Nerven kostet.
Fazit: Wir sollten mit Grub2 nochmals von vorne anfangen. Ich hätte nichts dagegen, wenn dieses unnötigerweise überkompliziert gestaltete Grub2- Etwas auch noch in Systemd aufgeht. Poettering schreibt jedenfalls bessere Software.
Das ganze ist eh eine Illusion. Siehe auch OpenSSH. In der Praxis kontrolliert eben kaum einer den Quellcode, obwohl ja laut Forenmeinungen ständig alle den ganzen Quellcode ihres Lieblingsprogrammes lesen, verstehen und nach Sicherheitslücken durchsuchen...
Es schaut sich wohl in der Praxis kaum einer irgend einen Quellcode an, alles andere zu behaupten ist nur Open Source Propaganda...
Von Toller Artikel am Sa, 19. Dezember 2015 um 08:59 #
aus dem Orignalartikel:
The successfully exploitation of the vulnerability has been possible because we made a very deep analysis of all components involved in this bug. As can be seen, the successful exploitation depends on many things: the BIOS version, the GRUB version, the amount of RAM, and whatever that modifies the memory layout. And each system requires a deep analysis to build the specific exploit.
das hört sich schon ein bissl anders an wie:
Es erfordert lediglich 28-mal die Rückschritttaste und einmal die Eingabetaste, um die Passwortabfrage zu umgehen. Vorausgesetzt, man hat sich nicht verzählt.
Uh - welch ein Drama! Ich bin erschüttert. Grub-PW ist genau wie ein BIOS-PW ein "Feature" mit höchst zweifelhaftem Nutzen. Für fern gewartete Rechner verbietet es sich von vornherein. Wenn ich mein System vor unautorisiertem Zugriff schützen will, dann verpasse ich ihm ein verschlüsseltes Dateisystem und sorge für sicheren (Fern-)Zugang. Ansonsten wäre das Grub-PW nämlich eine Stahltür in einem Pappkarton. Jeder, der physisch Zugrang zum Rechner hat, kann potentiell die Platte ausbauen und extern auslesen. Also, lasst uns den Ball flach halten. Dieses Drama ist ein Sturm im Wasserglas.
Halb so Wild. "Wichtige" Systeme gehören eh verschlüsselt.
Nur blöd dass der Schlüssel irgendwo sein muss sonst schaut es sowohl mit einem remote-reboot als auch mit einer failover-lösung ggf. schlecht aus wenn der wichtige Server dann blöde da sitzt und nach dem Passwort für den Schlüssel fragt
Wenn ich aber mal in die grub-shell komme bin ich wesentlich näher daran an den Schlüssel zu kommen
Dein Posting klingt eher nach einem Wichtigtuer der mal gelesen hat "Ja man kann das rootfs verschlüsseln" aber so wirklich in der Praxis noch nie was mit IT zu tun hatte
Nur blöd dass der Schlüssel irgendwo sein muss
Ja. Weit weg vom System und am besten nur im Kopf.
ggf. schlecht aus wenn der wichtige Server dann blöde da sitzt und nach dem Passwort für den Schlüssel fragt
Wenn auf einem Server überhaupt was verschlüsselt wird, dann lediglich die Partition mit den sensiblen Daten.
aber so wirklich in der Praxis noch nie was mit IT zu tun hatte
Ich hoffe stark, dass das auf dich zutrifft.
"Ja. Weit weg vom System und am besten nur im Kopf" - Ja wenn es praktikabel ist, ist es aber nicht in jeder Umgebung und in jedem Anwendungsfall und Security besteht im wesentlichen darin so weit abdichten wie möglich ABER AUCH praktikabel, hab ich aber dem anderen Trottel auch eben erklärt
Für ein unnötiges Feature - wie das Fernstarten eines Laptops - einfach mal alle Sicherheit über Board werfen.... Ahoi Matrose! Das lob ich mir.Wie bei den kleinen Kindern? Wenn man nicht Recht bekommt, dann wird mit den Füßen gestampft, geplärrt und die Luft angehalten.
"Für ein unnötiges Feature - wie das Fernstarten eines Laptops" -> Wer spricht von einem Laptop? Workstation != Laptop und was "unnötig" betrifft bist du schwerlich in der Position das zu beurteilen
Definiere nötig, klar wenn du eh dauernd im Büro anwesend sein musst mag es nicht nötig sein, es soll aber auch Leute geben die mal 2 Wochen nicht rein fahren müssen und zwischendurch doch mal was von der Maschine im Büro brauchen
"einfach mal alle Sicherheit über Board werfen" -> Schwachsinn, alle Sicherhit über Bord werfen wäre die Platte erst gar nicht zu verschlüsseln - Es geht darum es SCHWERER zu machen
Kapierst du nicht dass es einen Unterschied macht ob:
* Gar keine Verschlüsselung, Bootloader offen
* Verschlüsselung, Bootloader offen
* Verschlüsselung, Bootloader zu, Key auf der Maschine
* Verschlüsseung, Key nicht vorhanden
Das sind 4 völlig verschiedene Cases
Um es kurz zu machen: Deswegen ist der Schlüssel, der beim Schloss liegt ist mit einem zusätzlichen Schlüssel (Passwort) verschlüsselt.
Hast du es jetzt verstanden?
Das Spiel mit dem Schlüssel verschlüsseln kannst du ziemlich lange machen. Hilft halt nix, wenn zum Schluss das Passwort im Klartext auf der Platte liegt. Und das ist ja der Fall, wenn sein Pc ohne jegliche Eingabe komplett hochfahren kann.
Hast du das jetzt verstanden?
Du kapierst es einfach nicht - ja er kann komplett hochfahren aber dann stehst du vor einem passwort prompt und das grub passwort stellt sicher dass du eben nicht einfach in eine Shell bootest
Wozu die Verschlüsselung dann dient?
Damit ich eine alte Platte einfach bedenkenlos wegwerfen kann weil /boot und somit der Key und alles was dazu gehört nicht auf dem selben Laufwerk liegen
Hoffentlich kommt niemand auf die Idee, dein BIOS zurückzusetzen und Grub über einen externen Datenträger zu booten - und damit dann in die Shell.
Klar, ist ja auch der naheliegendste Grund für Verschlüsselung. Wäre auch zu einfach, die Platte mechanisch zu zerstören
Sir? Also wenn du deinen Schlüssel zum Entsperren auf dem gleichen Gerät, relativ einfach zugreifbar, gespeichert hast, dann hoffe ich, dass du nicht viel mit IT in der Praxis zu tun hast
Schwachkopf: 100% Sicherheit gibt es nicht, die setzt sich immer aus einem Haufen an Parametern zusammen die dann auch praktikabel sein müssen
Auf der Workstation im Büro die ich per VPN/WOL von zu Huse einschalte ist es wohl enig zielführend dann ins Taxi steigen und ein Passwort eingeben zu müssen
Es ist dort aber auch relativ unwahrscheinlich dass jemand in Ruhe Festplatten ausbauen kann ohne dass ihn jemandf fragt was er da macht und von USB/DVD booten oder Kernel-Parameter ändern ist nun mal nicht
Über den ungesicherten Bootloader umgehen und einen Backdoor installieren geht wesentlich unauffälliger weil schneller und ohne Lärm
Du hast keine Ahnung, wie man in der Praxis an ein solches Problem rangeht. Hier auf PL kannst du ruhig trollen, das finde ich noch ganz lustig haha. Aber mit der Realität hat das nichts zu tun.
Einer meiner anderen Server hat etwas ähnliches: SSDs als SED, und /boot auf einem USB-Stick. Auch hier: connect via dropbear, den dracut startet, ata unlock, rescan, fertig.
Automatischer Failover ist auch kein Problem, denn die Server im HA-Verbund laufen ja bereits.
Ja schön, es soll auch andere Umgebungen geben - Ändert nichts daran das "huhu was soll das bootloader passwort bringen" einfach nur geistiger Dünnschiss ist
Stellt euch einen Server arktischen vor, wo aus Wartungsgründen die Kisten neu gestartet werden.
Der Admin rennt dann den ganzen Tag im Server um herum und gibt Passwörter ein *g*
Wir schaffen das.
Bei physischem Zugang zur Hardware hat der Angreifer eh freie Hand, wenn das Betriebssystem nicht gerade verschlüsselt ist.
Ähm es ist schon noch ein Unterschied ob ich die Festplatte ausbauen muss um irgendwas drauf zu bekommen oder mit eine Shell krallen kann wo ich binnen 20 Sekunden Malware installiere die beim booten einen Backdoor aufmacht
Wenn jemand nicht komplett blöde ist lässt sich die Maschine nicht von DVD/USB booten und sowhl BIOS als auch Bootloader erfordern ein Passwort um irgendwas das nicht vorgesehen ist zu starten
Wenn jemand nicht komplett blöde ist, dann ist das Erste was er macht dein BIOS zu resetten...
Was bei einem gescheiten BIOS aber zumindest nicht das Passwort zurücksetzt.
Jumper umsetzen und das Passwort ist weg.
Und den gibt's ganz sicher überall (Eee-PC 1xxx)? Den Rechner, bei dem es mich interessieren würde, kann ich leider gerade nicht öffnen.
vllt hilft das weiter:
schau mal hier im EEE-Forum
Ich gehöre zu dieser "sehr kleinen" Zahl von Nutzern, die diese Funktion nutzen — vor langer Zeit mal aus reiner Neugier ausprobiert und dann irgendwie einfach immer weiter mitgenommen und nie wieder abgeschaltet, auch wenn das Passwort nur ein Punkt ist.
Mit 28-mal Backspace klappt es jedenfalls nicht, auch mit allem zwischen 16 und 40 nicht. Mehr Zeit zum Probieren habe ich gerade nicht, wie groß ist die Hardwareabhängigkeit dieser Spanne?
vermutlich hast du schon das update eingespielt^^
seit Gestern (17.12.2015) gibt es zumindest bei Red Hat und Debian schon Patches.
---
Der Bug trifft eigentlich nur Rechner, auf die physiklaisch Zugriff gewährt wird, bei Servern ist der Grub-Bug eh marginal.
Bei Clients die nur durch dieses Grub-Passwort geschützt sind, empfinde ich ihn als ebenso marginal, da ja z.B. durch ein Life-System auch Zugriff erfolgen könnte....
m2c
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Dez 2015 um 17:11."da ja z.B. durch ein Life-System auch Zugriff erfolgen könnte...." - Bei dir vielleicht, überall anders wird sobald das OS installiert ist booten von externen Datenträgern komplett deaktiviert und sowhl BIOS als aus GRUB mit einem Passwort versehen
du reisst meinen Satz auseinander - trennst Nebensatz vom Hauptsatz - kannst zweitens noch nicht mal richtig Quoten.....
...aber egal...ist ja Freitag
Was gab es da mehr zu quoten ausser der blödsinnigen Aussage man könnte einfach so ein Live-System booten nur weil die Kiste nicht auch noch verschlüsselt ist?
vielleicht den ganzen Satz, Süsser?
...dann würde dir auch dein Fehler auffallen
...du..Spezialist..du!!1!
Schaut euch erst Star Wars 7 an, denn gehts euch besser und es klappt auch mit Linux, oder so...
Er ist auf der dunklen Seite - da kommt er nicht mehr raus
Den Toast umdrehen er muss...
Ich wusste gar nicht, dass es diese Toaster wirklich gibt
Booten die mit Grub?
Das kann uns nur der Verflucht[e] erklären - er hat ja alles im Griff()
Nee, jetzt geht es mir richtig mies, weil ich mit ansehen mußte, wie Jar Jar Abrams Star Wars verhunzt hat. IMHO der schlimmste Star Wars Film aller Zeit. Hat ja so rein garnichts mehr mit Star Wars zu tun.
War ja nach den beiden Action-Star Treks nicht anders zu erwarten.
> vermutlich hast du schon das update eingespielt^^
Da ist eine Suse 12.1 drauf — die wird nicht mehr gepflegt, soweit ich weiß. Der Rechner dient zur Heizungs- und Belüftungssteuerung und hat keinen Netzzugang. Hab' das Passwort aus der Konfiguration rausgenommen, sonst vergesse ich es noch
(der letzte Reboot vor heute war am 2. Mai 2014).
Ohhh^^
...aber solang die Kiste ihren Dienst macht, ist doch alles vorzüglich. Wirst wohl erst beim Zusammenbruch der HW was neues aufspielen müssen....
lg
Es ist sehr BIOS-abhängig, niemand weiß genau, wie es auf anderen Rechnern funktioniert. Jedenfalls nicht offiziell.
Und alle haben so einen offensichtlichen Programmierfehler übersehen?
Das kann passieren, da es ja etwas tricky ist in grup mit backspache und return 28 hinter einnander, wird ja ausführlich im bereicht der experten beschrieben und auch der fix, der ja eine weitere if abfrage nur ist.
Das eigendtiche Ding ist ja, das in 90 oder 80% der Installationen nicht das grup-password nutzt, viele nutzen es gar nicht und der recht nutzt das Bios passwd.
Das liegt auch daran, das oder wer zugriff auf ein lokalen Rechner hat eh viel machen kann, zb die Festplatte ausbauen oder eine andere live OS zu booten. Da hilft eher das man seine wichtigen Daten verschlüsselt.
Und prinzipiell gilt auch, kein System ist sicher.
Grub2 ist überhaupt tricky, verteilt die Konfigurationsdateien hirnloserweise gleich über mehrere /boot und /etc-Ordner, bläst die Syntax zum Booten so auf, das man sinnloserweise zu Files zu reinen Editierungszwecken umdirigiert wird, nur weil man glaubt, die hochheilige grub.cfg vor dem Nutzer wie Admin schützen zu müssen und kapiert einfach nicht, dass "er" nur Betriebssysteme starten, aber bitte selbst kein eigenes "Boot-Betriebssystem" sein soll.
Nun ist selbst diese Sicherheitslücke ebenso gestaltet, unübersichtlich in der "Anwendung" und offenbar in Abhängigkeit von jeweiligem Bios in immer wieder jeweils einer anderen Nuance ausnutzbar. Auch hier kostet Grub2 also nur Zeit. Man könnte fast meinen, dass es sich bei dieser Sicherheitslücke um eine Art Easter Egg handelt, daraufhin optimiert, den sicherheitslückenkundigen Cracker möglichst viel Zeit zu kosten, genauso wie das Originalprogramm Otto Normalnutzer endlos Zeit und Nerven kostet.
Fazit: Wir sollten mit Grub2 nochmals von vorne anfangen. Ich hätte nichts dagegen, wenn dieses unnötigerweise überkompliziert gestaltete Grub2- Etwas auch noch in Systemd aufgeht. Poettering schreibt jedenfalls bessere Software.
systemd-boot funktioniert prima
Es gibt ja alternativen zu Grub2, LILO, SYSLINUX und andre.
Grub2 ist wirklich sehr mächtig, fast wie ein eigenes Betriebssystem.
Das ganze ist eh eine Illusion. Siehe auch OpenSSH. In der Praxis kontrolliert eben kaum einer den Quellcode, obwohl ja laut Forenmeinungen ständig alle den ganzen Quellcode ihres Lieblingsprogrammes lesen, verstehen und nach Sicherheitslücken durchsuchen...
Es schaut sich wohl in der Praxis kaum einer irgend einen Quellcode an, alles andere zu behaupten ist nur Open Source Propaganda...
aus dem Orignalartikel:
The successfully exploitation of the vulnerability has been possible because we made a very deep analysis of all components involved in this bug. As can be seen, the successful exploitation depends on many things: the BIOS version, the GRUB version, the amount of RAM, and whatever that modifies the memory layout. And each system requires a deep analysis to build the specific exploit.
das hört sich schon ein bissl anders an wie:
Es erfordert lediglich 28-mal die Rückschritttaste und einmal die Eingabetaste, um die Passwortabfrage zu umgehen. Vorausgesetzt, man hat sich nicht verzählt.
Vor allem weil sie den Exploit bisher nur in einer Qemu-Umgebung erfolgreich durchführen konnten.
Uh - welch ein Drama! Ich bin erschüttert.
Grub-PW ist genau wie ein BIOS-PW ein "Feature" mit höchst zweifelhaftem Nutzen. Für fern gewartete Rechner verbietet es sich von vornherein. Wenn ich mein System vor unautorisiertem Zugriff schützen will, dann verpasse ich ihm ein verschlüsseltes Dateisystem und sorge für sicheren (Fern-)Zugang. Ansonsten wäre das Grub-PW nämlich eine Stahltür in einem Pappkarton. Jeder, der physisch Zugrang zum Rechner hat, kann potentiell die Platte ausbauen und extern auslesen. Also, lasst uns den Ball flach halten. Dieses Drama ist ein Sturm im Wasserglas.
sorry für das Doppelposting; die Website spinnt bei mir etwas rum. Löschen geht anscheinend nicht, oder habe ich was übersehen?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Dez 2015 um 18:25.nee, hast nix übersehen.
beim Abschicken hab ich mir angewöhnt, wirklich nur einmal den Sende-Button zu berühren, dann warten und alles wird gut
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 21. Dez 2015 um 21:51.