Da gewisse Kreise mal wieder trollgleich Häme verbreiten wollen, nur weil eine Schwachstelle im Kernel ist, muß man das mal für die etwas einordnet, die nicht soviel davon verstehen, wie Sicherheitslücken einzuordnen sind.
Entspannt Euch mal – Kernel Schwachstelle in 6.1.x++
Für Desktopbenutzer ist eine Kernelschwachstelle erstmal keine besondere Lücke. Sie muß geschlossen werden, keine Frage, aber besonders kritisch ist die erst mal nicht. Bevor jemand eine Kernellücke ausnutzen kann, muß er i.d.R. Code auf dem PC ausführen können und der wird idealerweise direkt mit dem Kernel reden müssen. Von der Regel gibt es natürlich Ausnahmen, z.b. wenn die Lücke im Netzwerk-, USB- oder Bluetoothstack ist. Diese sind von außen erreichbar, sonst wären sie ja sinnlos 😉
Für Euch bedeutet das, der Angreifer muß eine Lücke in einem der unzähligen Programme auf Eurem PC ausnutzen können um seinen Code auszuführen. Dazu muß da aber erst einmal eine Lücke vorhanden sein. Und ganz realistisch betrachtet, wenn da eine Lücke drin ist, braucht der Angreifer keinen Kernel Exploit mehr. Ihr seid i.d.R. der einzige Benutzer, was bedeutet: er hat jetzt Vollzugriff auf Eure Daten. Was kann er noch mehr erreichen?
Das Extra-Mehr eines Kernelexploits
Das Extra-Mehr besteht darin, daß wenn Ihr schlau wart und Eure Bankgeschäfte mit einem anderen Benutzer macht, er da dann auch dran kommt. Bedingung für das Extra-Mehr ist also, daß Ihr Euch auch extra angestrengt habt um Eure Sicherheit zu erhöhen. Einige tun das, ich habe auch mehrere Benutzer die Jobs erledigen, aber die meisten Benutzer da draußen haben das nicht.
Deswegen solltet Ihr mehr Angst vor einer Schwachstelle in Chrome und Firefox haben, als vor dieser Kernellücke, denn die befindet sich im Speichermanagement des Kernels. Eine sogenannte Use-After-Free-Schwachstelle. Dabei gibt ein Prozess Speicherbereiche frei, die aber von einem anderen Programm/Codeteil noch aufgerufen werden, also eigentlich noch in Benutzung sind. Bekommt ein anderes Programm Zugang dazu, kann es ggf. Code in dem Kontext des den Speicherblock freigegebenen Programmes ausführen lassen.. Das geht auch in die andere Richtung, da also z.b. der Angreifer einen Stück Speicher mit Code versieht, freigibt und ein anderer Prozess führt den dort befindlichen Code aus( eher seltenes Szenario).
In einer Multi-Benutzer-Umgebung
Die Crux an dem Kernelexploit hier ist jetzt, daß die Besitzer des Prozesses der den Exploit nutzen will und des angegriffenen Programmes nicht gleich sein müssen. D.b. der Angreifer kann ein x-beliebiger User im System sein, und der angegriffene Prozess kann Root gehören. In der Konstellation wird es also richtig gefährlich, weil der angreifende Benutzer, so seine Rechte ausweiten kann. Auf einem Server muß man sich daher große Gedanken zu dieser Lücke machen, auf dem heimischen Desktop eher nicht.
Also, entspannt Euch ein bisschen. Ich fahr jetzt auf eine Party 😉