Journal des vulns des vulns des vulns! libc, curl, tout ça!!

Posté par  . Licence CC By‑SA.
Étiquettes :
38
4
oct.
2023

Bon, bin bimbamboum après exim, voilà que la libc est dangereuse!!

https://www.qualys.com/2023/10/03/cve-2023-4911/looney-tunables-local-privilege-escalation-glibc-ld-so.txt

Vous avez pas le temps de lire c'est trop long: en résumé, s'il y a un binaire SUID (bon, pas n'importe lequel non plus) sur votre distribution, un attaquant ayant un shell sur votre machine peut passer root! BIM! So much for the security.

Comment savoir si je suis impacté? C'est turbo-easy:

$ env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --help
Erreur de segmentation
$

Là, vous êtes vulnérable. Heureusement, les security guys de vos distros sont rapides et compétents, et si vous avez fait un update, normalement vous avez ça:

$ env -i "GLIBC_TUNABLES=glibc.malloc.mxfast=glibc.malloc.mxfast=A" "Z=`printf '%08192x' 1`" /usr/bin/su --help

Usage:
 su [options] [-] [<user> [<argument>...]]
(...)
$

Et voilà. Merci les mainteners, merci qualys, merci le monde \o/

Et demain? Eh bin le 11 octobre il va falloir patcher curl qui est lui aussi tout pété!

https://twitter.com/bagder/status/1709104796790083606

Pour ceux qui n'ont pas l'app:

  • Daniel Stenberg (le super developpeur de curl, merci Daniel) : "We are cutting the release cycle short and will release curl 8.4.0 on October 11, including a fix for a severity HIGH CVE. Buckle up."

  • Un random sur twitter : "Same score as the theoretical ddos? 🙃"

  • Daniel: "pretty much, yes. But this time actually the worst security problem found in curl in a long time."

Donc voilà, accrochez vos ceintures, tenez fermement vos claviers, et cramponnez vous qu'un zozo ne trouve pas la vuln avant le fix et aille tout casser le nain ternet!

  • # nitter

    Posté par  . Évalué à 3.

    https://nitter.net/bagder/status/1709104796790083606

    Merci pour le turbo-easy
    Ce fût rapide

  • # alternatives à curl

    Posté par  (Mastodon) . Évalué à 10. Dernière modification le 04 octobre 2023 à 12:40.

    En attendant si vous n'avez pas besoin d'avoir toutes les fonctionnalités de curl (je ne dois pas en utiliser 10%) et que vous voulez juste un outil pour taper sur des api, vous pouvez utiliser httpie (le logiciel libre en ligne de commande, pas la version desktop proprio), rurl ou gurl.

    https://github.com/httpie/cli/
    https://github.com/kujenga/rurl
    https://github.com/kujenga/gurl

  • # User space

    Posté par  . Évalué à 3.

    Attendez, je comprends pas bien. Je vais peut etre raconter n'importe quoi, mais il me semble que la libC est loade a l’exécution du programme dans le user space. Qu'est ce qui empêche l'attaquant de prendre la lib trouée et de l’exécuter sur la machine qu'il souhaite attaquer ?

    Autrement dit, comment est-ce que ce bug peut être résolu par autre chose qu'un fix kernel ?

    • [^] # Re: User space

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 04 octobre 2023 à 15:04.

      Je m'avance peut être, mais je pense que la glibc doit avoir un setuid bit ou un truc comme ça. Avec un binaire à côté, t'auras pas le setuid bit et le kernel ne passera pas ta glibc en root.

      • [^] # Re: User space

        Posté par  (Mastodon) . Évalué à 3.

        je pense que la glibc doit avoir un setuid bit ou un truc comme ça.

        En fait, si j'ai bien compris, c'est ld.so qui est setuid.

    • [^] # Re: User space

      Posté par  . Évalué à 10. Dernière modification le 04 octobre 2023 à 15:17.

      Qu'est ce qui empêche l'attaquant de prendre la lib trouée et de l’exécuter sur la machine qu'il souhaite attaquer ?

      C'est pas la libc qui a les droits root. La libc trouée a un problème de nettoyage d'environnement des binaires SUID.

      Le bit SUID il est sur le binaire (/usr/bin/su en l'occurence). Et le binaire, il va pas chercher des libs n'importe où, hein. La libc, il va la chercher dans quelques endroits bien précis. Ces endroits sont généralements own par root. Genre si t'es root, tu peux modif la libc du système et abuser de la vuln pour défoncer un programme suid (mais bon faut déjà être root haha).

      Dans la vraie vie, ouais tu peux load des bibliothèques ailleurs que dans /lib /usr/lib etc… genre avec LD_PRELOAD… Sauf que les binaires SUID ne suivent justement pas LD_PRELOAD pour des raisons évidentes de sécurité. Donc bon, tu as beau copier la lib trouée sur un système sain, tu ne peux pas l'utiliser avec les binaires suid du système.

      • [^] # Re: User space

        Posté par  . Évalué à 5.

        Sauf que les binaires SUID ne suivent justement pas LD_PRELOAD pour des raisons évidentes de sécurité.

        Top, merci pour l'explication. Je ne savais pas que c'était pas possible de jouer avec LD_PRELOAD dans ce cas là. J'imagine que c'est pareil pour LD_LIBRARY_PATH.

        J'ai l'impression que ce petit détail est documenté ici: https://man7.org/linux/man-pages/man8/ld-linux.so.8.html#ENVIRONMENT

  • # Tous en chœur

    Posté par  . Évalué à 0.

    ♪ des milliers de vulns vont en farandole, une vuln vuln vole ♫

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.