La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Logiciels => Discussion démarrée par: Polynesia le 25 septembre 2014 à 15:27:09
-
Encore une méga faille dans linux et MacOS : http://bit.ly/1rvHw9F (http://bit.ly/1rvHw9F)
J'espère que le serveur de vivien est patcher ?
-
Il est à jour et la faille a été corrigée.
Bash n'était pas l'interprétateur par défaut et je ne sais pas si cela impactait aussi ses cousins...
Sinon pas d’accès depuis des scripts apache et je suis le seul à me connecter.
(https://lafibre.info/testdebit/ubuntu/201409_bash_mise_a_jour_securite.png)
-
Encore une méga faille dans linux et MacOS : http://bit.ly/1rvHw9F (http://bit.ly/1rvHw9F)
J'espère que le serveur de vivien est patcher ?
Il y a faille si un serveur lance un shell avec la valeur d'une variable d'environnement choisie par un attaquant.
Lancer un shell est lourd et inefficace, j'espère que les serveurs ne lancent pas des shell pour rien!
Il peut y avoir faille sur les shells restreints en ssh.
-
Ce sont surtout les serveurs web qui hébergent des scripts CGI bash qui sont affectés (user-agent transposé directement en variable d'environnement -> boum). Ceux écrits dans d'autres langages peuvent aussi être affectés, à partir du moment où des fonctions de type system() sont utilisées.
Ça ne semble clairement pas être le cas de Lafibre.info (forum SMF, PHP).
Un Google dork : https://www.google.com/search?q=inurl%3Acgi-bin+filetype%3Ash (https://www.google.com/search?q=inurl%3Acgi-bin+filetype%3Ash) (on remarque que la plupart des sites de la première page sont down).
Pour surfer en s'amusant : https://x.com/JZdziarski/status/515135854436962304 (https://x.com/JZdziarski/status/515135854436962304)
-
Il est à jour et la faille a été corrigée.
Sauf que la correction de la faille consiste à introduire un bug : la valeur des variables est altérée dans certains cas. C'est inacceptable. On voit la médiocrité du monde "libriste" dans l'acceptation de ce genre de bidouilles au nom de "c'est une mauvaise pratique de programmation que de faire ça".
Si je lance un shell avec X="() {:;} ; echo toto" alors je dois pouvoir compter sur le fait que "echo $X" imprimera bien "() {:;} ; echo toto".
J'ai toujours pensé que les shells étaient des merdes, notamment bash.
Sinon, quelqu'un pour m'expliquer pourquoi diable le shell interprète cette syntaxe dans une variable d'environnement?
-
On voit la médiocrité du monde "libriste" dans l'acceptation de ce genre de bidouilles au nom de "c'est une mauvaise pratique de programmation que de faire ça".
Pourquoi une telle généralisation devrait-elle être appliquée au monde du libre plutôt qu'à par exemple l'informatique en général ?
-
Je trouve que très souvent le monde libre refuse la critique.
Par exemple, un FS qui fait perdre des fichiers : ça passe.
Un compilateur qui casse des programmes : ça passe.
Il y a toujours des gens pour défendre le n'importe quoi. Presque autant que les windowsfan!
-
Heu... non, ça passe pas. Pas plus qu'en proprio , et sur ce sujet je suis d'accord avec Marin.
Après, la seule question, c'est qu'un code de cochon, dans le monde libre, on va te répondre : "retrousse-toi les manches et envoie des patchs" (Ce qui revient à dire "va te faire foutre" à 99.99% des utilisateurs du programme, je suis bien d'accord).
Dans le monde proprio, de toute façon tu ne vois pas le code: Tu n'en voit que les conséquences (les bugs, failles de sécu,...). Après, c'est un rapport de force: Va essayer de faire condamner Microsoft pour leurs failles critique sortie chaque 1er mardi du mois: Bon courage, sauf si tu représente un état ou l'EU. Par contre, un petit éditeur de logiciel utilisé par une énorme boite, c'est pas la même chose: Le petit éditeur, si il veux survivre, il va corriger la faille vite fait bien fait, ramper par terre & filer des pénalités.
A la fin des fins, je sais pas quel est le mieux pour prévenir / éviter les failles telles que celle découverte aujourd'hui. Perso, mon biais me fait penser que "simplement" les logiciels proprio en sont truffé, & que simplement on les connais pas (pas encore).
-
Si je lance un shell avec X="() {:;} ; echo toto" alors je dois pouvoir compter sur le fait que "echo $X" imprimera bien "() {:;} ; echo toto".
C'est bien le cas :
pi@raspberrypi ~ $ X="() {:;} ; echo toto"
pi@raspberrypi ~ $ echo $X
() {:;} ; echo toto
Edit : Ah ok, tu pensais probablement à cette situation :
pi@raspberrypi ~ $ env x='() {:;} ; echo toto' bash -c "echo $x"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
-
intéressante cette conversation même si je ne suis pas programmeur... :-[
Toujours euh peur de rien n'y comprendre et de n'avoir pas le cerveau fait pour çà ::)
-
Heu... non, ça passe pas. Pas plus qu'en proprio , et sur ce sujet je suis d'accord avec Marin.
Après, la seule question, c'est qu'un code de cochon, dans le monde libre, on va te répondre : "retrousse-toi les manches et envoie des patchs" (Ce qui revient à dire "va te faire foutre" à 99.99% des utilisateurs du programme, je suis bien d'accord).
Non, deux exemples réels de ça passe, c'est pas un bug, circulez y a rien à voir :
- le FS qui efface les fichiers ouverts non modifiés quand il n'est pas démonté correctement
- le compilo qui invente sa propre sémantique C qui casse les programmes (parlez-en à Linus)
Dans le monde proprio, de toute façon tu ne vois pas le code:
Alors qu'avec le libre style OpenSSL, tu le vois, tu le comprends pas.
-
Non, deux exemples réels de ça passe, c'est pas un bug, circulez y a rien à voir :
- le FS qui efface les fichiers ouverts non modifiés quand il n'est pas démonté correctement
Bah, après, faut pas généraliser, hein : Dans le libre ya ptet des gens qui pensent que c'est pas un bug , mais d'autre personnes oui. Pour moi, c'est _clair_ que ce que tu dis ci-dessus c'est un énorme bug.
De toute façon, qui décide que c'est un bug ou une fonctionnalité ? Les codeurs du soft, quoi.
- le compilo qui invente sa propre sémantique C qui casse les programmes (parlez-en à Linus)
Oui, et t'a vu la réaction de Linus ?
J'ai vu récemment sur linuxfr un article qui m'a fait bondir sur la suppression de fonctionnalités parcequ'ils arrivaient pas à le faire correctement.... bref, pour moi , c'est pas parce qu'un gus dit "c'est pas un bug" que se n'en est pas un.
Alors qu'avec le libre style OpenSSL, tu le vois, tu le comprends pas.
Tout à fait d'accord. Mais ça change rien au problème - c'est le vieux code avec plein d'intervenants qui est sale , qu'il soit libre ou proprio. En proprio on le voit juste pas.
-
Ah ben maintenant que tout le monde a trouvé ma backdoor, ça va etre moins tranquille.....
Oups, je pense tout haut :D
-
Bon, j'ai trouvé la "doc" :
Internally, for forking, Bash stores the function definitions in environment variables. Variables with the content "() ….".
Something like the following works without "officially" declaring a function:
$ export testfn="() { echo test; }"
$ bash -c testfn
test
$
Just informational(2):
It is possible to set function names containing slashes:
/bin/ls() {
echo LS FAKE
}
http://wiki.bash-hackers.org/syntax/basicgrammar (http://wiki.bash-hackers.org/syntax/basicgrammar)
Quelqu'un m'explique ce que signifie "forking" en langage normal?!!
-
P.S. l'ERL est touche :-(
-
Edge routeur lite d'ubnt, on l'aime bien ici :-)
-
Debian a fait une mise a jour pour bash, cela devrait suivre pour l'erl...
-
'forking' vient de fork(2) (https://fr.wikipedia.org/wiki/Fork_(programmation)) qui consiste a creer un autre processus en copiant l'actuel.
C'est tres courant en programmation unixienne.
-
root@ubnt:~# apt update
Reading package lists... Done
root@ubnt:~# apt install bash
Reading package lists... Done
Building dependency tree... Done
bash is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
version 1.6 beta 3
root@ubnt:~# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
-
https://www.debian.org/security/2014/dsa-3032.fr.html (https://www.debian.org/security/2014/dsa-3032.fr.html)
-
Il parait qu'il fait tester avec :
env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
-
root@xxxxxxxx:~# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test
-
Et
env X='() { (a)=>\' bash -c "echo date"; cat e
?
-
Date: Wed, 24 Sep 2014 18:36:16 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com
CC: chet.ramey@...e.edu
Subject: Re: CVE-2014-6271: remote code execution through bash
On 09/24/2014 04:05 PM, Florian Weimer wrote:
> Stephane Chazelas discovered a vulnerability in bash, related to how
> environment variables are processed: trailing code in function
> definitions was executed, independent of the variable name.
It was pointed out to me off-list that a patched bash will still import
functions from the environment, including from variable names which
override shell commands. This is not an immediate vulnerability because
it requires setting environment variables under *specific* names. If
you can do that, there are already many variables which can affect the
execution of shell scripts, and some of them offer direct code execution
because they are subject to command substitution (BASH_ENV, for
example). The current vulnerability mainly exists because the name of
the environment variable does not matter at all.
My main concern with the current patch is that still exposes the bash
parser and function definition printer to attacks from the network. Bugs
in those fairly large components could cause another critical issue.
For hardening against such issues, I proposed a separate environment
variable with a well-known name, say BASH_FUNCDEFS, which lists the
names of environment variables which are to be imported as functions.
This would bring the attack requirements to the level which we have with
BASH_ENV now.
Removing the functionality completely is difficult because it is
actually used (search for �export -f�).
(If you find additional bugs, please do not discuss them here, but
follow the usual disclosure procedures. Thanks.)
--
Florian Weimer / Red Hat Product Security
http://www.openwall.com/lists/oss-security/2014/09/24/20 (http://www.openwall.com/lists/oss-security/2014/09/24/20)
-
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
-
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.
-
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...
-
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!
-
Pour l'ERL : http://community.ubnt.com/t5/EdgeMAX/About-bash-quot-Shellshock-quot-vulnerability-CVE-2014-6271-and/m-p/1027857#U1027857 (http://community.ubnt.com/t5/EdgeMAX/About-bash-quot-Shellshock-quot-vulnerability-CVE-2014-6271-and/m-p/1027857#U1027857)
-
Ils sont vraiment bien ;-)
upgrade de l'alpha 3 a la beta 1 sans pb, tests à faire...
-
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 (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 (http://unix.stackexchange.com/questions/157381/when-was-the-shellshock-cve-2014-6271-7169-bug-introduced-and-what-is-the-pat/157495#157495)
-
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 :
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 (http://www.gnu.org/software/bash/manual/bashref.html#Bourne-Shell-Builtins)
et sur les variables d'environnement en général :
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 (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!!!!!!!!!!!!!!!
-
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 :
-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 (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Optimize-Options.html)
-
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.)
-
(Et puis les CGI, ça pue c'est pas beau.)
Merci pour Smokeping ::)
Cdt
Bensay
-
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?
-
Haha
Ok.
Prenons un exemple bateau. Tu sais lire le PHP ?
$query = "select * from machin where bidule = $_GET['bidule']";
mysql_query(bidule truc machin chose);
Ce code est mauvais.
Est-ce la faute de PHP ?
Est-ce que la doc de PHP permet de prévoir ça?
Mieux, est-ce qu'une vache parfaitement sphérique fait du lait? Combien?
-
Heu... non, ça passe pas. Pas plus qu'en proprio , et sur ce sujet je suis d'accord avec Marin.
Après, la seule question, c'est qu'un code de cochon, dans le monde libre, on va te répondre : "retrousse-toi les manches et envoie des patchs" (Ce qui revient à dire "va te faire foutre" à 99.99% des utilisateurs du programme, je suis bien d'accord).
Non, on va te dire que c'est normal et attendu. Je l'ai vu plein de fois de la part de petit merdeux qui répète ce qu'il a entendu dans un forum :
- machin ne marche pas en multithread : c'est normal les threads ne sont pas conformes ANSI C
- truc casse le programme : c'est normal cet usage est interdit par xxxx
- "ça marchait par accident"
- "c'est un mauvais style de programmation, normal que ça casse"
On voit ça tout le temps.
Exemple de ce genre de ramassis de conneries par un bouffon ignorant et prétentieux qui cite une norme auquel il ne comprend rien :
"An object shall have its stored value accessed only by an lvalue
expression that has one of the following types: ... an aggregate
or union type that includes one of the aforementioned types among its
members (including, recursively, a member of a subaggregate or
contained union), or ..."
doesn't mean that you can get such an aggregate or union lvalue by
union u { int x; } *pu = (union u*)&i;
because the rules about pointer conversions only allow the result of
(union u*)&i
to be converted back to an (int*). They do not allow you to dereference
that pointer as a (union u*):
"6.3.2.3
"A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type. If the resulting
pointer is not correctly aligned for the pointed-to type, the
behavior is undefined. Otherwise, when converted back again, the
result shall compare equal to the original pointer."
This is *all* you are allowed to do with the converted pointer. You
may not dereference it.
This is the core rule that governs C's aliasing.
Andrew.
https://gcc.gnu.org/ml/gcc/2010-01/msg00031.html
C'est signé "Andrew Haley <aph at redhat dot com>"
RedHat emploie des types de ce calibre.
(Je ne dis pas que M$ n'emploie pas des bouffons au service réclamation.)
-
J'ai supprimé toutes les attaques et messages hors sujet.
Vu les nombreux dérapages, je bloque le sujet [édit : ré-ouvert].
Copie d'écran du correctif pour Ubuntu :
(https://lafibre.info/testdebit/ubuntu/201409_bash_mise_a_jour_securite.png)
-
(Merci aux trolls de ne pas pourrir ce topic)
September 27, 2014
Bash bug: apply Florian's patch now (CVE-2014-6277 and CVE-2014-6278)
OK, rebuild bash and deploy Florian's unofficial patch or its now-upstream version now. If you're a distro maintainer, please consider doing the same.
My previous post has more information about the original vulnerability (CVE-2014-6271). It also explains Tavis' and my original negative sentiment toward the original upstream patch. In short, the revised code did not stop bash from parsing the code seen in potentially attacker-controlled, remotely-originating environmental variables. Instead, the fix simply seeks to harden the parsing to prevent RCE. It relies on two risky assumptions:
That spare for this one bug we're fixing now, the process of parsing attacker-controlled functions is guaranteed to have no side effects on the subsequently executed trusted code.
That the underlying parser, despite probably not being designed to deal with attacker-supplied inputs, is free from the usual range of C language bugs.
From the very early hours, we have argued on the oss-security mailing list that a more reasonable approach would be to shield the parser from remotely-originating strings. I proposed putting the function export functionality behind a runtime flag or using a separate, prefixed namespace for the exported functions - so that variables such as HTTP_COOKIE do not go through this code path at all. Unfortunately, we made no real progress on that early in the game.
Soon thereafter, people started to bump into additional problems in the parser code. The first assumption behind the patch - the one about the parsing process not having other side effects - was quickly proved wrong by Tavis, who came up with a code construct that would get the parser in an inconsistent state, causing bash to create a bogus file and mangle any subsequent code that /bin/sh is supposed to execute.
This was assigned CVE-2014-7169 and led to a round of high-profile press reports claiming that we're still doomed, and people assigning the new bug CVSS scores all the way up to 11. The reality was a bit more nuanced: the glitch demonstrated by Tavis' code is a bit less concerning, because it does not translate into a universally exploitable RCE - at least not as far as we could figure it out. Some uses of /bin/sh would be at risk, but most would just break in a probably-non-exploitable way. The maintainer followed with another patch that locked down this specific hole.
The second assumption started showing cracks, too. First came a report from Todd Sabin, who identified an off-by-one error when parsing more than ten stacked redirects. The bug, assigned CVE-2014-7186, would cause a crash, but given the nature of the underlying assignment, it wasn't particularly clear if this created an immediately exploitable security risk. Another similarly ambiguous one-off issue with line counting in loops cropped up shortly thereafter (CVE-2014-7187).
The two latter issues do not have an officially released upstream patch at that point, but they prompted Florian Weimer of Red Hat to develop an unofficial patch that takes a seemingly more durable approach that we argued for earlier on: putting function exports in a separate namespace. Florian's fix effectively isolates the function parsing code from attacker-controlled strings in almost all the important use cases we can currently think of.
(One major outlier would be any solutions that rely on blacklisting environmental variables to run restricted shells or restricted commands as a privileged user - sudo-type stuff - but it's a much smaller attack surface and a a very dubious security boundary to begin with.)
Well... so, to get to the point: I've been fuzzing the underlying function parser on the side - and yesterday, bumped into a new parsing issue (CVE-2014-6277) that is almost certainly remotely exploitable and made easier to leverage due to the fact that bash is seldom compiled with ASLR. I'll share the technical details later on; for now, I sent the info to the maintainer of bash and to several key Linux distros. In general terms, it's an attempt to access uninitialized memory leading to reads from, and then subsequent writes to, a pointer that is fully within attacker's control. Here's a pretty telling crash:
bash[3054]: segfault at 41414141 ip 00190d96 ...
Soon after posting this entry, I also bumped in the sixth and most severe issue so far, essentially permitting very simple and straightforward remote code execution (CVE-2014-6278) on the systems that are patched against the first bug. It's a "put your commands here" type of a bug similar to the original report. I will post additional details in a couple of days to give people enough time to upgrade.
At this point, I very strongly recommend manually deploying Florian's patch unless your distro is already shipping it. (Florian's patch has been also finally included upstream shortly after I first posted this entry.)
From within the shell itself, the simplest way to check if you already have it installed would be:
foo='() { echo not patched; }' bash -c foo
If the command shows "not patched", you don't have the patch and you are still vulnerable to a (currently non-public) RCE, even if you applied the original one (or the subsequent upstream patch that addressed the issue found by Tavis).
Oh, and if it shows "command not found", you're good.
http://lcamtuf.blogspot.ro/2014/09/bash-bug-apply-unofficial-patch-now.html (http://lcamtuf.blogspot.ro/2014/09/bash-bug-apply-unofficial-patch-now.html)
COMMENTAIRE
Il va de soi que je suis d'accord sur le fait de supprimer la fonctionnalité "() {" de bash, à la base de la faille-scandale "shellshock".
-
Merci corrector.
J'avoue que j'ai suivi ça de loin, et j'ai tj pas compris comment c'était exploitable en remote sur un serveur qui ne fait pas tourner de CGI, ni comment on peut élever des privilèges avec. Dans le doute, j'ai patché . et ton dernier message m'a montré l'un de mes serveur non patché alors que je pensait que c'était fait, donc merci bcp !
-
Il n'y a pas UNE mais une série de failles dans bash.
-
J'avoue que j'ai suivi ça de loin, et j'ai tj pas compris comment c'était exploitable en remote sur un serveur qui ne fait pas tourner de CGI, ni comment on peut élever des privilèges avec. Dans le doute, j'ai patché . et ton dernier message m'a montré l'un de mes serveur non patché alors que je pensait que c'était fait, donc merci bcp !
C'est exploitable quand un shell bash est lancé :
- explicitement : /bin/bash
- implicitement : /bin/sh pointant sur bash (mais pas sur Debian, puisque sh = dash)
ce que peut se produire :
- explicitement exec ("/bin/bash", blah)
- exec ("un-script") qui est un script #!/bin/bash
- implicitement notamment avec les commandes comme system et popen (par opposition à exec)
dans un contexte où le contenu d'une variable d'environnement est fourni par un tiers qui n'est pas autorisé à exécuter des commandes dans le contexte d'exécution du /bin/bash en question, par exemple :
via le réseau :
- client HTTP (User-agent fabriqué) lançant un programme en CGI sur le serveur (variables "HTTP_machinchose") => accès en tant qu'utilisateur "www" ou "apache"
- serveur DHCP (options DHCP) transmises à un script par le client => accès en tant qu'utilisateur root
- client SSH ayant la possibilité de login SSH mais pas d'exécution d'un shell (utilisateur restreint)
- envoi d'email (qmail avec une adresse destination fabriquée : accès avec les droits du "facteur")
en local :
potentiellement tout programme qui s'exécute avec des droits que tu ne peux pas obtenir régulièrement :
- tout programme Set-quelque chose (SUID, SGID, Set-capability)
- tout programme périodique (comme crontab)
- tout programme de gestion hotplug démarré quand tu branches un périphérique USB ou autre
(ce sont les programmes que tu ne peux pas installer une version perso en remplacement de la version du système)
qui lancerait un script bash de la façon décrite.
Je n'ai pas étudié la question; les programmes s'exécutant automatiquement peuvent être ou ne pas être vulnérables. Il est évident qu'étudier la question est un très gros boulot et qu'il faudrait étudier chaque variante de script dans chaque distrib.
Donc :
- sur serveur HTTP, les systèmes de "scripts" qui sont plus efficaces que CGI ne sont pas concernés : pour être plus efficaces ils ne lancent pas un "script CGI" à chaque requête HTTP donc les variables d'environnement ne peuvent pas être utilisé pour transmettre des informations venant de la requête HTTP;
- le client SSH qui a le droit de lancer un shell sur un serveur n'est pas concerné parce que tout le qu'il peut faire c'est exploiter bash pour exécuter le programme qu'il peut lancer normalement; tu ne peux pas élever tes privilèges avec l'exploit dans ce cas là : au moment où bash est lancé, les droits sont ceux de ton utilisateur SSH.
Pour étudier la question, je suggère d'instrumenter /bin/bash pour qu'il logue toute les utilisations qui ne sont pas un shell interactif.
-
Ah ben maintenant que tout le monde a trouvé ma backdoor, ça va etre moins tranquille.....
Je pense que le terme est approprié!
Pour donner une analogie facile à comprendre, c'est comme si MySQL décidait que si dans une requête SQL quelconque la valeur d'un champs commence par "'(fun)" alors
- tout ce qui suit peut définir une fonction SQL (feature)
- et qu'en fait le code permette d'exécuter une requête SQL quelconque (bug)
alors toute personne ayant la possibilité de fabriquer le contenu d'un champs d'une requête SQL quelconque aurait un accès à la base avec les droits du programme : par exemple, je pense que tout utilisateur de ce forum contrôlerait parfaitement la base. Et même un utilisateur non enregistré.
Et la seule façon de se protéger a priori de ce type de "feature" serait d'encoder (mettons en base 64) ou de chiffrer intégralement les données textuelles des utilisateurs avant de les mettre en BDD.
Bien sûr a posteriori (une fois la feature annoncée sur FD) on peut filtrer la commande '(fun) mais si une version différente de MySQL décide qu'en fait la syntaxe est "()'" ou "'`$^*" on l'a dans l'baba!
-
- tout programme de gestion hotplug démarré quand tu branches un périphérique USB ou autre
(ce sont les programmes que tu ne peux pas installer une version perso en remplacement de la version du système)
J'ai trouvé ça :
Hotplug event variables:
========================
Every hotplug event should provide at least the following variables:
ACTION
The current hotplug action: "add" to add the device, "remove" to remove it.
The 2.6.22 kernel can also generate "change", "online", "offline", and
"move" actions.
DEVPATH
Path under /sys at which this device's sysfs directory can be found.
SUBSYSTEM
If this is "block", it's a block device. Anything other subsystem is
either a char device or does not have an associated device node.
The following variables are also provided for some devices:
MAJOR and MINOR
If these are present, a device node can be created in /dev for this device.
Some devices (such as network cards) don't generate a /dev node.
[QUESTION: Any reliable way to get the default name?]
DRIVER
If present, a suggested driver (module) for handling this device. No
relation to whether or not a driver is currently handling the device.
INTERFACE and IFINDEX
When SUBSYSTEM=net, these variables indicate the name of the interface
and a unique integer for the interface. (Note that "INTERFACE=eth0" could
be paired with "IFINDEX=2" because eth0 isn't guaranteed to come before lo
and the count doesn't start at 0.)
FIRMWARE
The system is requesting firmware for the device. See "Firmware loading"
below.
https://www.kernel.org/doc/pending/hotplug.txt (https://www.kernel.org/doc/pending/hotplug.txt)
Les variables qui prennent des valeurs parmi un ensemble limité de symboles "add", "remove", "change", "online", "offline", "move" (variable ACTION) ne sont évidemment pas exploitables, ni celles qui sont des valeurs numériques (variables MAJOR et MINOR), ni celles qui contiennent un chemin complet donc commençant par "/" (variable DEVPATH).
-
Chose intéressante : la manière dont les constructeurs jugent la faille.
Exemple: Cisco et F5
- Cisco embarque une version de bash vulnérable dans NX-OS (pour les switches Nexus) -> des correctifs sont disponibles pour certaines versions (car toutes ne sont pas vulnérables). Ce qui est intéressant c'est que pour accèder à bash, il faut déjà etre connecté en ssh au matériel...
- F5 embarque bash dans ses appliances BigIP. Je l'ai testé, la faille est présente. Mais pour F5, pas de correctif car pas vulnérable. Pourquoi ? Sans doute parce qu'ils ont estimé que puisqu'il faut etre connecté en ssh sur l'appliance, la faille ne présente aucun intéret.
-
Il n'y a aucun service réseau autre que ssh?
-
Sur F5, l'admin est distinct des interfaces de prod. Mais l'admin se fait aussi via une interface web en HTTPS.
Sur NX-OS, hormis SNMP, y'a pas grand chose de possible.
Donc l'un (F5) est plus exposé que l'autre (Cisco NX-OS) en apparence. Et pourtant sur l'évaluation des risques, c'est le contraire :)
-
Il n'y a pas que les serveurs écoutant sur le réseau, il y a aussi les scripts qui lisent des données venant de l'extérieur; par exemple, un script lisant un fichier de log. S'il utilise à un moment donné des variables d'environnement pour passer des informations à un autre programme...
-
Sauf que dans un cas comme dans l'autre, on n'a pas ce genre de service sur ces équipements.
Le truc rigolo c'est que bash est directement accessible sur un F5 alors que sur NX-OS, c'est pas directement accessible. Pire, son accès n'est possible que sur certaines plateformes ! (Nexus 7000)
-
Directement accessible de quelle manière?
-
Ben dès que tu te connectes en ssh sur un F5, t'arrives sur un bash. Un F5 BigIP c'est une distrib Linux standard avec une application embarquée, ils ne se sont pas foulé.
Sur un Cisco Nexus, t'arrive sur la ligne de commande NX-OS. Pour avoir accès à bash, il faut les bons privilèges et passer dans un mode pas bien documenté.
EDIT: sur le F5, t'as qu'un user en plus : root. Sur un Cisco, on l'aura relié à un TACACS. Donc le type qui se connecte, on le verra tenter d'y accèder. On peut meme lui interdire l'accès.
-
Ben quand tu as un shell interactif, qu'est-ce que peux vouloir de plus? Pourquoi (pour quoi) shellshocker?
-
C'est là où c'est drole.
Ce cas de figure existe aussi pour des firewalls et pourtant ils ont publié une mise à jour :)