Linux Kernel 2.6 Local Root Exploit

[newsbot]

Der aktuelle Linux-Kernel und ältere Versionen bis einschließlich Kernel 2.6.17 enthalten eine Sicherheitslücke, die es lokalen Anwendern ermöglicht, sich Root-Rechte zu verschaffen.

Weiterlesen...

 

[Gast1]

Der Exploit funktioniert nachweislich auf 2.6.18 und 2.6.22 (openSUSE 10.2/10.3).

Wäre ich jetzt Admin mit "verwundbaren" Linuxkisten und vielen Usern an selbigen, wäre mir unwohl.

Bis zum nächsten Kernelupdate könnte folgender "Würgaround" helfen.

http://www.pc-forum24.de/sonstige-news/8398-pro-linux-linux-kernel-2-6-local-root-exploit.html

Das Einbinden in den Startprozess, _bevor_ sich $USER einloggen kann (sonst wäre das ja witzlos) kann ich nur für openSUSE beschreiben, für andere Distributionen können ja deren jeweilige User hier anfügen, wo man das hinpacken muss.

//Edit:

Die beschriebenen Stabilitätsprobleme hier

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953

kann ich bisher nicht nachvollziehen, aber trotzdem "use at your own risk".

Greetz,

RM

 

[defcon]

Debian etch hat heute das Kernel-update rausgeschickt. Also da besteht mal keine Gefahr mehr.

 

[Gast1]

Die Methode mit dem Kernelmodul novmslice.ko ist wohl die bessere Wahl (siehe 3. Posting).

Eben auf zwei Systemen getestet (OSS 10.2/10.3) und blockt den Exploit sauber ab.

Wer seine Kiste nicht neu starten kann, der ist mit dieser Methode bis zum Update gut bedient, nach einem insmod des Moduls ist das Loch gestopft.

Greetz,

RM

 

[sim4000]

Ich habs mal auf meinem Homie getestet.
Running System: SuSE 10.2 - 2.6.18.2-34-default

Hat allerdings nicht geklappt... Is ja eigentlich gut so.

 

[Gast1]

Oh doch, der Exploit funktioniert auf 10.2/2.6.18 (leider) wunderbar.

Lade Dir das Attachment runter, entpacke es und kompiliere es mit

gcc linux_vmsplice.c -o boeser_exploit

Danach als _normaler_ User

./boeser_exploit

whoami

und dann steht da auf einmal "root".

Vorher aber sauberes System, also direkt nach dem Start und bevor die andere Datei "disable-vmsplice-if-exploitable.c" kompiliert/ausgeführt wurde.

BTW:

Seit über einem Jahr keine Updates gefahren?

Das ist ja immer noch der Kernel, der auf der Installations-CD/DVD drauf war.

 

[doc]

also mit dem neuesten kernel update von debian etch läuft es in jedem fall nicht -- gerade mal getestet.

und mein gentoo will es nicht einmal compilieren ...

 

[kostjaXP]

in Fedora beheben den exploit diese kernel:

kernel-2.6.24.1-28.fc9
kernel-2.6.23.15-137.fc8
kernel-2.6.23.15-80.fc7

 

[sim4000]

Bei mir geht es nicht.
Habs mit dem Exploid das in proLinux verlinkt war probiert.

Seit über einem Jahr keine Updates gefahren?
Das ist ja immer noch der Kernel, der auf der Installations-CD/DVD drauf war.

Joa.
Is ja "nur" ein Homeserver der als Fileserver dient. Hat also keine Anbindung ans Internet. Hatte also kein Bedürfnis / keine Lust n Update zu fahren.

Habs noch mal mit RMs Anhängsel auf nem Debian Etch getestet:

debianserver:~# gcc disable-vmsplice-if-exploitable.c
debianserver:~# ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[-] !@#$
debianserver:~# su benutzer
benutzer@debianserver:/root$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7dcc000 .. 0xb7dfe000
[+] root
Exploit gone!
benutzer@debianserver:/root$ whoami
benutzer
benutzer@debianserver:/root$ exit
exit
debianserver:~# uname -r
2.6.18-5-686

Geht also auch nicht...

 

[Gast1]

Wer lesen kann ...

.. ist klar im Vorteil.

debianserver:~# gcc [B]disable-vmsplice-if-exploitable[/B].c

Natürlich geht das nicht, das ist schließlich der Hotfix, welcher den Exploit abblocken soll.

Greetz,

RM

 

[Wolfgang]

Ist ja ein lokaler Exploid!
Wer also kein gcc auf der Kiste hat (brauch man nicht auf einem Webserver. Wenn alles installiert ist => entfernen), hat da nix zu befürchten.

Trotzen interessdanter Hack.

Gruß Wolfgang

 

[Gast1]

*Ähm*

Und wenn der "Böse Hacker" eine vorkompilierte Version des Exploits mitbringt?

ldd linux_vmsplice-exploit
        linux-gate.so.1 =>  (0xffffe000)
        libc.so.6 => /lib/libc.so.6 (0xb7e18000)
        /lib/ld-linux.so.2 (0xb7f7b000)

Sooooooo schlecht stehen die Chancen da nicht, daß der auch auf ner anderen Kiste läuft.

OK, wenn ein Angreifer schon ne Usershell hat, dann ist eh übel.

Greetz,

RM

 

[Wolfgang]

*Ähm*

Und wenn der "Böse Hacker" eine vorkompilierte Version des Exploits mitbringt?

Die muss er aber erstmal mitbringen.
Bis dahin ist er nicht als root unterwegs.
Dann kannst du aber auch gleich jede andere manipulierte Datei mitbringen.
Klar mit Shellzugang ist das natürlich etwas Anderes.

 

[sim4000]

.. ist klar im Vorteil.

debianserver:~# gcc [B]disable-vmsplice-if-exploitable[/B].c

Natürlich geht das nicht, das ist schließlich der Hotfix, welcher den Exploit abblocken soll.

Greetz,

RM

Ups.
Ja, ich war heute morgen noch ein bissl müde...

//edit
Mit dem Exploid geht aber auch nicht.

 

[Gast1]

Mit welchem?

Und wenn vorher schon der Hotfix ausgeführt wurde, dann gehts bis zum nächsten Neustart sicher nicht, das ist ja der Sinn der Sache.

Der Exploit funktioniert auf allen bekannten Distributionen mit Kernel 2.6.17 bis 2.6.24 und vor allem auch auf openSUSE 10.2 mit dem 2.6.18er, wieso sollte das gerade bei Dir nicht der Fall sein?

Greetz,

RM

 

[kostjaXP]

Mit dem Exploid geht aber auch nicht.

Mich interessiert das jetzt gar nicht wo der Exploit net geht obwohl er gehen sollte..sondern nur, was man tut, um ihn auszumerzen!
--> hab mir den gefixten fedora-kernel von hier installiert..

Ich jedenfalls plane nicht, jemand Fremdem ne Usershell zu geben..gleichwohl habe ich natürlich den gcc und surfe auch im Netz und so...also wie kann ein Angreifer was kompilieren, wenn er zwar ne usershell hat aber nicht sudo machen darf und auch nicht root ist?
Und wie kompiliert man ein Modul auf einen kernel, den man nicht hat?
Also weiß ich schonmal, das ein Angreifer wohl genau den kernel haben müsste, um mich zu erwischen.
Würde für mich heißen,
1.öfter den kernel zu updaten
2.ein System zu verwenden, was nicht so viele Leute haben
3.welches bei Sicherheitsfragen schnelle Lösungen bietet
4.Sich über die Sicherheit seines Systems zu informieren

Frage ist: Was tut meine Distri für Sicherheit?
Beispiel Fedora:
-sudoers file: wer nicht drin ist ist, kann kein sudo ausführen (kann nur mit visudo über Konsole als root editiert werden)
-SELinux: meldet (im Idealfall) eine unkoschere Aktion..(leider Standardaktionen auch..)
-puplet: meldet verfügbare Updates (läuft als Applet im Infobereich -- schön, wenns Beachtung findet)

 

[gropiuskalle]

openSuSE hat seine Kernel gefixt, gleiches gilt auch für z.B. den realtime-Kernel von Jengelh.

 

[tuxlover]

Komisch ich kriege für 10.2 keinen Kernel. Und den Jengel Kernel gibts ja nur für 10.3 oder irre ich da?
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Das Einbinden in den Startprozess, _bevor_ sich $USER einloggen kann (sonst wäre das ja witzlos) kann ich nur für openSUSE beschreiben, für andere Distributionen können ja deren jeweilige User hier anfügen, wo man das hinpacken muss.

RM

Ist dir eigentlich aufgefallen dass auf der von Dir geposteten Website explizit von dieser Methoder abgeraten wird?