Faille dans certains noyaux : détournement de stdio/stderr

Posté par Anonyme le 23 avril 2002 à 16:21. Modéré par Pascal Terjan.

Étiquettes :

avr.

2002

Une série de messages de Joost Pol (pine), James Youngman (FreeBSD) et Theo de Raadt (OpenBSD) fait état d'un grave problème dans plusieurs noyaux unix (testé et vérifié sur FreeBSD et Solaris) : les redirections standards (input, output et error) peuvent être détournées par un programme sans privilèges particuliers et ainsi permettre un élévation des droits.

Aller plus loin

securitybugware (3 clics)
L'annonce sur securitybugware (5 clics)

# Mise à jour

Posté par nemerid le 23 avril 2002 à 16:25. Évalué à 10.

Apparemment, ce n'est déjà plus un problème, puisque les patchs pour ces noyaux sont déjà fournis. Reste à savoir s'il en est de même avec le noyau linux ??? Ce n'est pas le cas, ou cela n'a tout bonnement pas encore été vérifié ?
- [^] # Re: Mise à jour
  
  Posté par oliv le 23 avril 2002 à 16:42. Évalué à 10.
  
  Il y a un thread sur la liste de diffusion du noyau (5 messages... par énorme) http://marc.theaimsgroup.com/?t=101948626200003&r=1&w=2 ceci dit, la news parle des noyaux unix, alors que l'annonce sur security bugware parle de posix. Il me semble qu'il y a des OS posix non unix, non? donc le problème pourrait bien aussi se poser à d'autres... (enfin je dis ça, c'est juste pour troller ;) ) hop -1
  - [^] # Re: Mise à jour
    
    Posté par rootix le 23 avril 2002 à 16:57. Évalué à 10.
    
    une petite liste de systèmes recensés pour ceux qui doutent : http://online.securityfocus.com/archive/1/268969/2002-04-20/2002-04-26/0
    - [^] # Re: Mise à jour
      
      Posté par Étienne le 23 avril 2002 à 17:30. Évalué à 10.
      
      D'ailleur l'explication de la faille est très bien faite dans le premier message de ce fil de discussion : http://online.securityfocus.com/archive/1/268932/2002-04-20/2002-04-26/1 Etienne
- [^] # Re: Mise à jour
  
  Posté par icyfemur le 23 avril 2002 à 17:21. Évalué à -3.
  
  >Apparemment, ce n'est déjà plus un problème, puisque les patchs pour ces noyaux sont déjà fournis. C'est normal, on a gardé le bug secret jusqu'a ce que ce soit patché ! Hein ? Comment ? Je sors ? Nooon... <PAF !> ...ah ben si en fait...-->[] -1, parce que je le vaux bien...
# Génant en effet

Posté par Sébastien Rohaut le 23 avril 2002 à 16:59. Évalué à 6.

C'est un problème d'autant plus génant que la maitrise des redirections en programmation système n'est pas innée (au début on y va un peu au petit bonheur la chance). D'où un risque agravé. A bien y penser, c'est surprenant que ce gouffre de sécurité soit trouvé maintenant. Si j'ai bien compris, de cette manière un utilisteur lambda peut modifier le contenu d'un fichier pour lequel il n'a pas d'acces possible. Je serais curieux de savoir si ça marche sur Linux...
- [^] # Re: Génant en effet
  
  Posté par furai (site web personnel) le 23 avril 2002 à 17:22. Évalué à 10.
  
  This is a simple test, executing a setuid process with filedescriptor 2 closed, and then opening a file and seeing what fd it gets. Linux 2.2.16 RedHat AXP Not vulnerable (thanks fets) Linux 2.5.6 Debian `Woody' Not vulnerable Linux 2.4.18 Debian `Potato' Not vulnerable OpenBSD 2.9 Not vulnerable (thanks dim) OpenBSD 3.0 Not vulnerable (thanks sateh) OpenBSD 3.1 Not vulnerable (thanks dim) OS X 10.1.4 Not vulnerable (thanks sateh) NetBSD 1.4.2 Not vulnerable (thanks bounce) Solaris 2.5.1-2.5.8 Vulnerable Code on http://ds9a.nl/setuid-fd-2.tar.gz cf lien + haut (Christophe Guilloux)
  - [^] # Re: Génant en effet
    
    Posté par Val Erie le 23 avril 2002 à 17:42. Évalué à 2.
    
    hum ...
    
    proprio 0 - open source 8
    
    ... non ???
    - [^] # Re: Génant en effet
      
      Posté par oliv le 23 avril 2002 à 18:47. Évalué à 4.
      
      Bizarre. FreeBSD est vulnérable mais pas OSX, qui est basé sur FreeBSD...
      
      OSX, c'est quand même un peu propriétaire, non?
      - [^] # Re: Génant en effet
        
        Posté par Gaël Le Mignot le 24 avril 2002 à 10:25. Évalué à 1.
        
        MacOS X utilise les outils et une partie de la libc de FreeBSD, mais le noyau est un micro-noyau Mach donc cela n'a rien à voir avec le noyau de FreeBSD
    - [^] # Re: Génant en effet
      
      Posté par Benoît Sibaud (site web personnel) le 23 avril 2002 à 18:52. Évalué à 5.
      
      Debian Woody 2.2.20-udma100-ext3 : non vulnérable
      Debian Potato 2.2.20-smp : non vulnérable
      Debian Potato 2.2.19-ide : non vulnérable
      Solaris 2.6 : vulnérable
      Solaris 2.7 : vulnérable
      Solaris 2.8 : vulnérable
    - [^] # Re: Génant en effet
      
      Posté par pasBill pasGates le 23 avril 2002 à 21:05. Évalué à 3.
      
      Non.
      
      Solaris est open-source (mais pas libre)
      
      D'autre part, freeBSD qui est open-source ET libre, est vulnerable
    - [^] # Re: Génant en effet
      
      Posté par pllevy le 24 avril 2002 à 09:49. Évalué à 2.
      
      Après test, ma petite pierre à ce recensement qui met en avant un affrontement proprio/libre :
      AIX 4.3.3.0 Not vulnerable
      - [^] # Re: Génant en effet
        
        Posté par quad le 24 avril 2002 à 17:28. Évalué à 1.
        
        Suite aux tests que je viens d'effectuer, HP-UX version 11 est vulnérable.
        Cet OS n'a vraiment aucune chance : je l'aime pas et je considère que c'est un vrai danger de l'avoir.
        Je ne voterai pas pour lui.
        
        "Toute ressemblance ... etc etc"
        --
        Ecid
# j'ai teste pour vous sous linux

Posté par lhardy philippe (site web personnel, Mastodon) le 23 avril 2002 à 17:46. Évalué à -5.

sur ma version de linux il y a bien le probleme.
copiez le trois fichiers compromised.c exploit.c et Makefile dans un repertoire...

#compromised.c
#include <stdio.h>

int main( int argc, char* argv[]) {
FILE * f = fopen("root_owned_file", "r+");
if(f) {
fprintf(stderr, "%s: fopen() succeeded\n", argv[0]);
fclose(f);
}

}

#exploit.c
#include <unistd.h>
#include <stdio.h>

/*
argv[1] should contain global path to compromised program.
*/
int main(int argc, char* argv[]) {
/*
uhm this defeat execl...
while(dup(1) != -1);
*/
close(2);
execl(argv[1],
"this text will endup in the root_owned_file", 0);

}

#Makefile
doit:
gcc compromised.c -o compromised
gcc exploit.c -o exploit
rm -f root_owned_file
touch root_owned_file
./exploit compromised

#test it
make doit

verifiez le contenu de root_owned file !
- [^] # Re: j'ai teste pour vous sous linux
  
  Posté par Epsos le 23 avril 2002 à 17:57. Évalué à 10.
  
  Heuh tu l'as chope ou ton exemple la ?
  Parce que oui, c'est normal que ca marche, c'est la norme POSIX qui veut ca ...
  Si je comprend bien, dans exploit.c, tu ferme le canal 2 (stderr), puis tu fais un exec avec comme parametre {compromised, "this text ... root_owned_file"}.
  Dans compromised, tu ouvres un fichier. Puisque il n'y a plus de canal 2, le fichier s'ouvre donc sur le canal 2. Du coup, ecrire dans le canal 2 revient a ecrire dans le fichier juste ouvert ...
  Rien de neuf sous le soleil.
  
  La le bug qu'on a trouve, c'est que ca marchait aussi dans le cas ou le programme que tu executais (ici, compromised) etait suid.
  
  Je ne vois aucune trace dans ton makefile de :
  1 - execution de exploit en user non root
  2 - droits suid sur compromised
  
  Avec ces deux cas la reunis, tu pourrais conclure ... Mais pour l'instant ...
  
  A+
  - [^] # Re: j'ai teste pour vous sous linux
    
    Posté par lhardy philippe (site web personnel, Mastodon) le 23 avril 2002 à 18:16. Évalué à 9.
    
    Je l'ai fait un peu vite.
    Ce test ne vaut effectivement rien.
- [^] # Re: j'ai teste pour vous sous linux
  
  Posté par DaFrog le 23 avril 2002 à 18:05. Évalué à 6.
  
  > sur ma version de linux il y a bien le probleme.
  
  Et c'est quoi comme "version" (distrib? noyau?)?
  
  Au fait, si tu fais juste "make doit" ça marche car "root_owned_file" est a toi et pas a root! ;)
  
  "touch root_owned_file" doit etre éxecuté par root (qui devrait avoir un umask tel que le fichier ne soit pas accessible en ecriture pour les autres utilisateurs), alors que "./exploit compromised" doit etre éxecuté par un utilisateur non-privilégié...
  
  DaFrog.
  
  P.S. Chez moi ça ne marche nulle part (diverses Mandrake, Debian et OpenBSD).
# Aucun rapport avec le noyau

Posté par j le 23 avril 2002 à 21:03. Évalué à 10.

Ce n'est en aucun cas une faille du _noyau_. Le noyau fait son boulot dans la plus stricte logique.

Si un programme setuid ne s'assure pas que les descripteurs correspondent bien a ce qui est attendu, _ces programmes_ sont buggues.

Le fait qu'un noyau (OpenBSD) ou la libc (GlibC de Linux, FreeBSD maintenant) prenne le soin de garantir des descripteurs corrects permet de limiter les degats avec les applications mal ecrites. Mais l'OS n'est absolument pas cense effectuer cette operation. Le probleme devrait etre fixe a la base.

Le noyau de Solaris n'est pas "vulnerable" a quoi que ce soit. Si les applications setuid livrees avec Solaris sont bien programmees, il n'y a pas de risque.
- [^] # Re: Aucun rapport avec le noyau
  
  Posté par quad le 24 avril 2002 à 10:19. Évalué à 2.
  
  Franck (tu permets que je t'appelle franck ? :) )
  
  Comme tu l'as bien écrit : le problème doit être
  fixé à la base.
  
  Au même titre que certains (bons) un*x interdisent l'exécution de script shell en mode setuid, je trouve que l'OS doit se blinder des conneries^H^H^H^H^H^H^H^H^H erreurs de programmation des applications qui lui sont connexes, sinon c'est "la porte ouverte à toutes les fenêtres". Un OS ne doit jamais faire confiance aux applications : c'est pour ça qu'on a créé la mémoire protégée; pour qu'un soft pondu avec les moufles se plante tout seul sans entraîner le système avec lui.
  
  Bon, je sais, ça rajoute des batteries de tests
  dans l'OS, mais la sécurité est à ce prix.
  
  Ecid.
- [^] # Re: Aucun rapport avec le noyau
  
  Posté par PLuG le 24 avril 2002 à 10:34. Évalué à 1.
  
  effectivement,
  
  Comment une application (suid ou pas d'ailleur) peut elle se premunir contre cela ?
  
  A priori quand elle ouvre un fichier il obtient le plus petit descripteur disponible (posix), donc eventuellement stderr ou stdout si c'est libre.
  du coup tout "printf" est fait dans le fichier, c'est le probleme d'aujourd'hui.
  
  pour s'en premunir, elle pourrait tester que lors de l'ouverture elle obtient bien un id>2 ...
  ou ne rien ecrire/lire dans les descripteur par defaut si elle ne fait pas le test.
  
  le plus simple c'est quand meme pour une fois de tester dans le noyau. C'est pas pareil que "la pile non executable" ou le patch ne garanti pas que les exploits n'auront pas lieu.
  Ici la correction noyau est efficace, par contre le test dans le kernel devrait peut etre (en plus) sortir un gros warning dans les logs de manière a attirer l'attention des developpeurs ...
  - [^] # Re: Aucun rapport avec le noyau
    
    Posté par j le 24 avril 2002 à 21:09. Évalué à 2.
    C'est pas bien dur de verifier ca dans les applis : il suffit d'ouvrir /dev/null pour les descripteurs que l'on utilise pas. Par exemple pour la commande pure-ftpwho de pureftpd (qui peut etre mise en setuid), je fais comme ca pour ne laisser que le descripteur 1 ouvert (si la fonction renvoit -1 => exit du programme avant d'avoir ecrit quoi que ce soit) :
```
static int closedesc_but1(void)

{

    int fodder;



    (void) close(0);

    if ((fodder = open("/dev/null", O_RDONLY)) == -1) {

        return -1;

    }

    (void) dup2(fodder, 0);

    if (fodder > 0) {

        (void) close(fodder);

    }

    if (fcntl(1, F_GETFD) == -1) {

        return -1;

    }

    if (fcntl(2, F_GETFD) != -1) {

        if ((fodder = open("/dev/null", O_WRONLY)) == -1) {

            return -1;

        }

        (void) dup2(fodder, 2);

        if (fodder > 2) {

            (void) close(fodder);

        }

    }

    return 0;

}
```

Suivre le flux des commentaires

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