Auteur Sujet: La faille «Shellshock» de Bash  (Lu 14285 fois)

0 Membres et 1 Invité sur ce sujet

PacOrly

  • Abonné Free fibre
  • *
  • Messages: 1 226
  • FTTH 850/350 Orly (94)
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #24 le: 26 septembre 2014 à 22:43:11 »
Et
 
env X='() { (a)=>\' bash -c "echo date"; cat e

?

root@xxxxxxxx:~# env X='() { (a)=>\' bash -c "echo date"; cat e
date
cat: e: Aucun fichier ou dossier de ce type

  • Invité
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #25 le: 27 septembre 2014 à 00:21:11 »
Passing executable code in environment variables is an incredibly bad idea.
The parsing bug is a red herring; there are probably ways to exploit the feature even when it doesn't have the bug.
The parsing bug means that the mere act of defining the function in the child bash will execute the attacker's code stored in the environment variable.
But if this problem is closed, the issue remains that the attacker controls the environment variable; the malicious code can be put inside the function body. Even though it will not then be executed at definition time, perhaps some child or grand-child bash can be nevertheless goaded into calling the malicious function.
Basically this is a misfeature that must be rooted out, pardon the pun.


https://news.ycombinator.com/item?id=8362126

Je suis d'accord. Le problème fondamental n'est pas la faille ni le bug qui cause la faille, c'est cette fonctionnalité : le contenu d'une variable (quel que soit son nom!) peut être exécuté par bash au démarrage, et cela n'est documenté qu'en passant.

C'est le genre de chose qui fait que tout le monde déteste les shell.

BadMax

  • Client Free adsl
  • Expert
  • *
  • Messages: 3 479
  • Malissard (26)
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #26 le: 27 septembre 2014 à 14:22:37 »
Je vois pas le rapport avec le sujet.

Pour l'execution de commandes, bash créé un fils, c'est lui qui executera la commande. Pour passer les arguments, ils utilisent les variables d'environnement. Et dans ces dernières, on peut mettre tout et n'importe quoi. Surtout n'importe quoi...


  • Invité
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #27 le: 27 septembre 2014 à 15:27:04 »
OK, j'ai compris (finalement) :

C'est lié à la fonctionnalité export -f de bash (que ne propose pas sh).

Et le "fork", c'est quand on tape bash dans bash.

Ouf!

PacOrly

  • Abonné Free fibre
  • *
  • Messages: 1 226
  • FTTH 850/350 Orly (94)

tivoli

  • Toulouse (31)
  • Abonné Bbox fibre
  • *
  • Messages: 1 940
  • Toulouse (31)
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #29 le: 27 septembre 2014 à 15:58:03 »
Ils sont vraiment bien ;-)

upgrade de l'alpha 3 a la beta 1 sans pb, tests à faire...

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 795
  • 73
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #30 le: 27 septembre 2014 à 17:03:13 »
Une collection de PoC (proof of concept) qui montrent comment le bug peut être exploité autrement que sur HTTP : https://github.com/mubix/shellshocker-pocs

Sinon, quelqu'un pour m'expliquer pourquoi diable le shell interprète cette syntaxe dans une variable d'environnement?
Une explication avec le contexte : http://unix.stackexchange.com/questions/157381/when-was-the-shellshock-cve-2014-6271-7169-bug-introduced-and-what-is-the-pat/157495#157495

corrector

  • Invité
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #31 le: 28 septembre 2014 à 16:56:42 »
C'est tout à fait acceptable. Acceptable s'il s'agit du comportement définit.
Je n'ai pas lu la norme "shell", mais peut-être est-il normal de soumettre le contenu des variables d'environnement à interprétation. Pourquoi pas ?
Sources ?
Ce n'est pas la documentation.
Lit le manuel.
VOICI LE MANUEL OFFICIEL :

Sur la builtin export :
Citer
export [-fn] [-p] [name[=value]]
Mark each name to be passed to child processes in the environment. If the -f option is supplied, the names refer to shell functions; otherwise the names refer to shell variables. The -n option means to no longer mark each name for export. If no names are supplied, or if the -p option is given, a list of exported names is displayed. The -p option displays output in a form that may be reused as input. If a variable name is followed by =value, the value of the variable is set to value.

The return status is zero unless an invalid option is supplied, one of the names is not a valid shell variable name, or -f is supplied with a name that is not a shell function.
http://www.gnu.org/software/bash/manual/bashref.html#Bourne-Shell-Builtins

et sur les variables d'environnement en général :
Citer
3.7.4 Environment

When a program is invoked it is given an array of strings called the environment. This is a list of name-value pairs, of the form name=value.

Bash provides several ways to manipulate the environment. On invocation, the shell scans its own environment and creates a parameter for each name found, automatically marking it for export to child processes. Executed commands inherit the environment. The export and ‘declare -x’ commands allow parameters and functions to be added to and deleted from the environment. If the value of a parameter in the environment is modified, the new value becomes part of the environment, replacing the old. The environment inherited by any executed command consists of the shell’s initial environment, whose values may be modified in the shell, less any pairs removed by the unset and ‘export -n’ commands, plus any additions via the export and ‘declare -x’ commands.

The environment for any simple command or function may be augmented temporarily by prefixing it with parameter assignments, as described in Shell Parameters. These assignment statements affect only the environment seen by that command.

If the -k option is set (see The Set Builtin), then all parameter assignments are placed in the environment for a command, not just those that precede the command name.

When Bash invokes an external command, the variable ‘$_’ is set to the full path name of the command and passed to that command in its environment.
http://www.gnu.org/software/bash/manual/bashref.html#Environment

ET C'EST TOUT CE QUE LE MANUEL OFFICIEL DE GNU BASH RACONTE.

Si avec ça tu arrives à saisir l'histoire de () { alors tu as des dons de voyance!!!!!!!!!!!!!!!
« Modifié: 29 septembre 2014 à 01:10:54 par corrector »

  • Invité
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #32 le: 28 septembre 2014 à 17:23:12 »
Sources ?
Ce genre de choses :

int foo (float *f, int *i) {
  int j = *i;
  *f = 0;
  return j;
}
GCC a tendance à considérer que (void*)i != (void*)f et que donc cela revient à faire :
int foo (float *f, int *i) {
  *f = 0;
  return *i;
}
et à optimiser agressivement.

Mais rien n'interdit d'utiliser la même adresse successivement pour deux types incompatibles, ce qui est interdit en C est :
int float_to_int(float f) {
  return *(int*)&f;
}
parce que float et int ne sont pas compatibles au niveau de la représentation, et qu'on ne peut pas lire un objet d'un type avec un valeur-g d'un autre type.

La doc :
Citer
-fstrict-aliasing
Allow the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an unsigned int can alias an int, but not a void* or a double. A character type may alias any other type.
Pay special attention to code like this:

          union a_union {
            int i;
            double d;
          };
         
          int f() {
            union a_union t;
            t.d = 3.0;
            return t.i;
          }
The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type. So, the code above works as expected. See Structures unions enumerations and bit-fields implementation. However, this code might not:

          int f() {
            union a_union t;
            int* ip;
            t.d = 3.0;
            ip = &t.i;
            return *ip;
          }
Similarly, access by taking the address, casting the resulting pointer and dereferencing the result has undefined behavior, even if the cast uses a union type, e.g.:

          int f() {
            double d = 3.0;
            return ((union a_union *) &d)->i;
          }
The -fstrict-aliasing option is enabled at levels -O2, -O3, -Os.
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html

  • Invité
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #33 le: 28 septembre 2014 à 17:42:50 »
Bash n'était pas l'interprétateur par défaut et je ne sais pas si cela impactait aussi ses cousins...
C'est spécifique à bash.

Il vaut mieux que /bin/sh soit un shell minimaliste plutôt que bash.

(Et puis les CGI, ça pue c'est pas beau.)

Bensay

  • Technicien Orange ADSL / FTTH / MIC
  • Abonné Orange Fibre
  • *
  • Messages: 686
  • Val D'oise
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #34 le: 28 septembre 2014 à 17:50:49 »
(Et puis les CGI, ça pue c'est pas beau.)
Merci pour Smokeping  ::)

Cdt

Bensay

  • Invité
Sécurité: la mégafaille «Shellshock» secoue le monde Linux et Mac OS
« Réponse #35 le: 28 septembre 2014 à 18:39:14 »
Pour l'execution de commandes, bash créé un fils, c'est lui qui executera la commande. Pour passer les arguments, ils utilisent les variables d'environnement.
Peux-tu donner un exemple?