Zum Heise-Artikel "Fehler im Linux-Kernel" ermöglicht Rechteausweitung

[Blue]

Unter https://www.heise.de/news/Fehler-in-Lin ... 34791.html warnt Heise.de vor einem Fehler im Linux-Kernel, welcher eine Rechteausweitung ermöglichen soll. Ein Leserkommentar sagt aus, dass Debian davor geschützt sei https://www.heise.de/forum/heise-online ... 3548/show/ . Als Kontrolle gibt er einen Konsolenbefehl in einem normalen Terminal an („#unshare -Unr /bin/bash"). Sollte dieser Befehl eine Root-Shell erzeugen, so sei das betreffende Betriebs-System verwundbar.

Ich habe das jetzt natürlich auf meinem System (Bullseye/Gnome3) ausprobiert und die Shell wurde prompt zu „Root“. Allerdings offensichtlich nur als „Attrappe“, weil sich in dieser Konsole keine Root-Befehle (z.B. ein Update oder dmesg -T) ausführen ließen:

root@..…:~# apt update
Paketlisten werden gelesen… Fertig
W: chown to _apt:root of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (22: Das Argument ist ungültig)
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (1: Die Operation ist nicht erlaubt)
W: chown to _apt:root of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (22: Das Argument ist ungültig)
W: chmod 0755 of directory /var/lib/apt/lists/auxfiles failed - SetupAPTPartialDirectory (1: Die Operation ist nicht erlaubt)
E: Sperrdatei /var/lib/apt/lists/lock konnte nicht geöffnet werden. - open (13: Keine Berechtigung)
E: Das Verzeichnis /var/lib/apt/lists/ kann nicht gesperrt werden.
W: Problem beim Entfernen (unlink) der Datei /var/cache/apt/pkgcache.bin - RemoveCaches (13: Keine Berechtigung)
W: Problem beim Entfernen (unlink) der Datei /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Keine Berechtigung)
root@…..:~# dmesg -T
dmesg: read kernel buffer failed: Die Operation ist nicht erlaubt
root@…..:~#

(Meinen Benutzernamen habe ich mit „…..“ anonymisiert)

Es entsteht also etwas, das wie eine Root-Shell aussieht, aber offensichtlich keine ist.
Ein OpenSuseLeap-15.3-Nutzer hat die gleiche Erfahrung gemacht.

Hat hier zu diesem Thema irgend jemand etwas dazu zu informieren oder zu kommentieren?

[inne]

Das ja ein Ding
Scheinbar wird aber kein apt aufgerufen
bash: u: Kommando nicht gefunden.
sagt das das nur u als Befehl "probiert" wurde.

Erstmal wüsste ich nicht was sagt echo $UID usw? probier mal bash buildins zu nutzen!

[Blue]

@inne:

sagt das das nur u als Befehl "probiert" wurde.

Bei meinem Post hatte ich anfänglich für ein Update reflexartig mein Alias dafür ("u") angegeben. Da dies die Leser hier natürlich irritiert, habe ich den Post editiert und mit der Shell-Ausgabe ersetzt, welche nach dem "normalen" Befehl ("#apt update") kommt.
Sorry für meine Unachtsamkeit.

Erstmal wüsste ich nicht was sagt echo $UID usw?

Darauf kommt:

root@.....:~# echo $UID
0

Aber solche Diagnosen kann von Euch ja jeder selbst in dieser Attrappen-Shell machen.
Ich denlke erst einmal, dass wir "Debianer" tatsächlich sicher sind, weil ja immer "Die Operation ist nicht erlaubt" kommt.
Habe ich da recht?

[inne]

Immhin schonmal die UID ist die von root: 0! Aber mit Namesräumen kenne ich mich nicht weiter aus.

[Blue]

Immhin schonmal die UID ist die von root: 0!

Ja, in der Shell steht ja auch root@xxx
Nur folgen auf entsprechende Root-Befehle eben Verweise auf "keine Berechtigung".

Aber mit Namesräumen kenne ich mich nicht weiter aus.

Zu den Namespaces steht im zitierten Thread von der Heise-Kommentare Interessantes: https://www.heise.de/forum/heise-online ... 3548/show/

[inne]

Hast Du dir mal den PoC angesehen, der bei Heise verlinkt ist. Er hat dort was mit nftabels geschrieben. Noch habe ich das nicht probiert. Ist dein Befehl dem gleichzusetzen?

[Blue]

Hast Du dir mal den PoC angesehen, der bei Heise verlinkt ist. Er hat dort was mit nftabels geschrieben und nutzt aber auch eine C funktion unshare_setup(getuid(), getgid()); noch habe ich das nicht probiert. Ist dein Befehl dem gleichzusetzen?

Inne, Du überschätzt meine Kompetenz bezüglich Linux.
Ein User hat gepostet, dass der Kernel 5.18.2 einen Patch zur vorliegenden Problematik enthält. Soviel ich weiß, hat "Bookworm" erst den Kernel 5.17.0-1-4...
Ich hoffe, dass Berufenere hier noch posten werden.

[inne]

Ok. Ich weiss gerade nicht, was mir alles an Libs fehlt, um das zu kompilieren...
41705
PS: Zeilennummern stimmen nicht mehr, hab im Header ein paar Notizen gemacht!

[Blue]

Noch`n Gedicht:
https://www.itmagazine.ch/Artikel/77336 ... griff.html und https://wochentlich.de/fehler-in-linux- ... usweitung/

Hier wird behauptet, dass zwei Konsolen-Befehle den Fehler ausmerzen würden.
Ich wäre jetzt aber als DAU vorsichtig und würde wegen möglicher und noch nicht dokumentierten "Nebenwirkungen" (z.B. auf Sandboxes) solche Befehle nicht blind geben...
Besser ist es imho, auf Updates mit den entsprechenden Bug-Fixes zu warten.

[Blackbox]

Was ist denn das schon wieder für eine völlig überhitzte „Diskussion“?
Es gibt in Debian immer noch das Security-Team, das dieses Problem längst auf dem Zettel hat und nach einer Lösung für alle unterstützten Releases sucht.

Aber diese Information hätte wohl weniger Kommentare eingebracht, was?

[Blue]

@Blackbox:

Was ist denn das schon wieder für eine völlig überhitzte „Diskussion“?

Aber diese Information hätte wohl weniger Kommentare eingebracht, was?

"Überhitzt" ist hier noch gar nichts. Und so soll es imho auch bleiben.
Es sei denn, Dir gelingt es, eine Sachdiskussion unnötig mit unhöflichen Off-Topic Kommentaren zu befeuern...

Es gibt in Debian immer noch das Security-Team, das dieses Problem längst auf dem Zettel hat und nach einer Lösung für alle unterstützten Releases sucht.

Yep. Genau meine Meinung, siehe ein Post über Dir. Ich wiederhole, speziell für Dich:

Besser ist es imho, auf Updates mit den entsprechenden Bug-Fixes zu warten.

[inne]

Yep. Genau meine Meinung, siehe ein Post über Dir. Ich wiederhole, speziell für Dich:

Besser ist es imho, auf Updates mit den entsprechenden Bug-Fixes zu warten.

Achso; und ich dachte du wolltest den Exploit/PoC ans laufen bekommen

[Blue]

Yep. Genau meine Meinung, siehe ein Post über Dir. Ich wiederhole, speziell für Dich:

Besser ist es imho, auf Updates mit den entsprechenden Bug-Fixes zu warten.

Achso; und ich dachte du wolltest den Exploit/PoC ans laufen bekommen

Nee...

Aber im Ernst, ich dachte eher an das "/etc/sysctl.d/99-disable-unpriv-userns.conf" mittels der erwähnten Befehle, welche man als Laie aber wie bereits geschrieben, imho besser unterlassen sollte.

[Blackbox]

Aber im Ernst, ich dachte eher an das "/etc/sysctl.d/99-disable-unpriv-userns.conf".

Genau einen Workaround gibt es auch bereits, deswegen noch einmal die Frage an dich @rockyracoon was soll diese Polemik?
Wenn es dir wirklich um eine Lösung gegangen wäre, hättest du einen qualifizierten Bugreport geschrieben und/oder gleich den Workaround in deinen ersten Beitrag dieses Threads gegeben.

1 Beitrag, Thema erledigt.
Ist nicht das erste Mal, dass du so agierst.
Und wie immer keine Eigenleistung.

[hikaru]

Mehr Ahnung als ihr habe ich auch nicht, aber eine echte Rechteausweitung gibt es hier offenbar nicht. Es sieht nur so aus. Der tatsächliche User wird nicht geändert:

Code: Alles auswählen

hikaru@desktop:~$ unshare -Unr /bin/bash
root@desktop:~# whoami
root
root@desktop:~# touch /tmp/test.txt
root@desktop:~# ls -l /tmp/test.txt 
-rw-r--r-- 1 root root 0  9. Jun 19:52 /tmp/test.txt
root@desktop:~# exit
exit
hikaru@desktop:~$ ls -l /tmp/test.txt
-rw-r--r-- 1 hikaru hikaru 0  9. Jun 19:52 /tmp/test.txt

Es sieht also zunächst gefährlich aus, aber es war alles nur Show. Zur Überprüfung aus einer anderen, echten root-Shell:

Code: Alles auswählen

root@desktop:~# ls -l /tmp/test.txt 
-rw-r--r-- 1 hikaru hikaru 0  9. Jun 19:52 /tmp/test.txt

@Blackbox:
Dass Mancher angesichts solch einer Meldung unruhig wird und niederschwellig erst mal auf dem Schulhof (Debianforum) nachfragt, ob jemand etwas weiß, bevor er ins Lehrerzimmer (Debian-Bugreport) läuft, ist durchaus verständlich.

[Blue]

@hikaru:

Es sieht nur so aus. Der tatsächliche User wird nicht geändert
Es sieht also zunächst gefährlich aus, aber es war alles nur Show

Ja, es sieht nach einer "Attrappen-Root-Shell" aus.
Thx für Deinen konstruktiven Beitrag.

[TRex]

Evt. könnte man so eine binary mit setuid-bit austricksen... ich vertrau dem Frieden noch nicht ganz, finde aber die Überschrift des Heise-Artikels noch ein wenig zu clickbaitig.

[DeletedUserReAsG]

Ich hab das gerade mehr oder weniger erfolgreich dazu genommen, einem Installer einer Software vorzugaukeln, dass es als Root liefe:

Code: Alles auswählen

niemand@MIN ~/tmp % ./MPLABX-v6.00-linux-installer.sh 
The installer needs to be run as root

1 niemand@MIN ~/tmp % unshare -Unr
root@MIN ~/tmp # ./MPLABX-v6.00-linux-installer.sh
64-bit Linux detected.
Check for 64-bit libraries
Verifying archive integrity... All good.
Uncompressing MPLAB X v6.00 installer.....

… es gab da noch einige Kleinigkeiten, bei denen der Installer trotz umgebogener Pfade in Systemverzeichnisse schreiben wollte, aber grundsätzlich hat’s letztlich funktioniert.

Ich will diesen Bug nun als Feature

[Blackbox]

Thx für Deinen konstruktiven Beitrag.

Und warum war es nicht möglich, wenigstens einen konstruktiven Beitrag zu von dir zu lesen?
Versteh' doch bitte meine Kritik als konstruktiv, dann braucht es in diesem Fall den Melden-Button nicht.

Dass Mancher angesichts solch einer Meldung unruhig wird und niederschwellig erst mal auf dem Schulhof (Debianforum) nachfragt, ob jemand etwas weiß, bevor er ins Lehrerzimmer (Debian-Bugreport) läuft, ist durchaus verständlich.

Ich hätte nichts geschrieben, wenn das nicht viel zu oft der Modus Operandi dieser Person wäre.
Und anschließend wird dann fleißig Selbstverharmlosung betrieben.

[hikaru]

Versteh' doch bitte meine Kritik als konstruktiv, dann braucht es in diesem Fall den Melden-Button nicht.

Ich kann in deinen Beiträgen in diesem Thread bisher nichts Konstruktives finden.
Weiteres bitte per PN!

[mcb]

So heute kam ein Kernelupdate unter Bullseye, ist da der Fix schon drinnen?

Buster und älter waren ja eh nicht betroffen.

[DeletedUserReAsG]

Es gibt ein Changelog und eine entsprechende Mail in der Security-ML.

[Ano]

So heute kam ein Kernelupdate unter Bullseye, ist da der Fix schon drinnen?

Buster und älter waren ja eh nicht betroffen.

Gestern konnte ich die Aufdatierung von 5.10.0-14 auf 5.10.0-15 installieren. Hier scheint sich noch nichts geändert zu haben.

Und laut der genannten Liste kommt der Fix erst mit 5.10.120. Wobei man ja die beiden Versionsformate anscheinend nicht direkt vergleichen kann. Weiß also genauso viel wie vorher.

[MSfree]

Und laut der genannten Liste kommt der Fix erst mit 5.10.120.

Mit folgendem Befehl hättest du bereits gewußt, daß der neueste Kernel der 5.10.120 ist.

Code: Alles auswählen

uname -a
Linux holodeck 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64 GNU/Linux

und:

Code: Alles auswählen

zgrep nftables /usr/share/doc/linux-image-5.10.0-15-amd64/changelog.gz 
  * netfilter: nftables: avoid potential overflows on 32bit arches
  * netfilter: nftables: clone set element expression template
    - netfilter: nftables: skip hook overlap logic if flowtable is stale
    - netfilter: nftables_offload: VLAN id needs host byteorder in flow
    - netfilter: nftables_offload: special ethertype handling for VLAN
    - netfilter: nftables: Fix a memleak from userdata error path in new objects
    - netfilter: nftables: avoid overflows in nft_hash_buckets()
    - netfilter: nftables: report EOPNOTSUPP on unsupported flowtable flags
    - netfilter: nftables: allow to update flowtable flags
    - netfilter: nftables: fix possible UAF over chains from packet path in
    - netfilter: nftables_offload: set address type in control dissector
    - netfilter: nftables_offload: build mask based from the matching bytes
    - netfilter: nftables: fix netlink report logic in flowtable and genid
    - netfilter: nftables_offload: KASAN slab-out-of-bounds Read in

Der Fix für UAF (use after free) ist der, um den es sich im Heiseartikel handelt.

[Ano]

Und laut der genannten Liste kommt der Fix erst mit 5.10.120.

Mit folgendem Befehl hättest du bereits gewußt, daß der neueste Kernel der 5.10.120 ist.

Code: Alles auswählen

uname -a
Linux holodeck 5.10.0-15-amd64 #1 SMP Debian 5.10.120-1 (2022-06-09) x86_64 GNU/Linux

...

Wer die Zeile bis zu Ende liest, ist also klar im Vorteil!

Danke für den Tipp!

Das Verhalten von "unshare -Unr /bin/bash" hat sich aber anscheinend nicht geändert zu haben. Oder ist das auch wieder ein anderer Schuh?