Reprise du message précédent :
dites, sur les macs on est affecté par le bug de bash ?
genre en drive-by dans un coffee-shop, mon apache est accessible, du coup ça me rend vulnérable ?

normalement oui, pour tester, colle ça dans un terminal

 
la question, a mon sens, ne porte pas sur l version de bash et sa vulnerabilité, mais sa capacité à être mise en oeuvre depuis le voisinnage réseau suivant le niveau d'ouverture

je devais voir mes sécuristes finlandais ce soir, ça m'a l'air compromis

nan, mais mon problème c'est pas de taper une commande dans bash, c'est de capter le lien avec apache.
Y'a un moyen pas trop chiant de l'ouvrir sur localhost ? Je sens qu'il va falloir aller dans /etc et ça me fait peur sous mac

ah, j'avais mal compris sa question, mais ouais, les problèmes s'ils doivent survenir viendront de là

 
mod_cgi permet de créer des variables/fonctions qui sont réutilisées plus tard

C'est quand même la fête du slip, le truc de mettre du code dans des variables d'environnements, pas de problème ça exécute

 
C'est libre

pendant 23ans

 
J'allais dire que c'est pas vraiment le problème ici, c'est juste complètement con
 

 
En effet

interesting
http://codingdelight.com/2014/05/0 [...] principle/

yeah, de toutes façons, les héritages ça marche pas dans les exemples de la vraie vie.
tu vas avoir un concept abstrait et des héritiers concrets.
Et en géométrie, c'est encore pire.
 
Pour l'anecdote, Liskov c'est une des rares femmes dont le nom reste un principe dans l'industrie. Y'a des célébrités, genre Ada Lovelace ou Grace Hoper, mais Liskov, elle a laissé son nom à un principe fondateur.

Ça va bouger... Mon N+1 a annoncé son départ.

Je suis le seul à penser que ce genre d'événements apportent tout sauf de la remise en question dans les organisations ?

http://www.parashift.com/c++-faq/p [...] tance.html   circle vs ellipse

Notes que le test encore plus utile c'est avec /bin/sh, pour savoir si le shell par défaut est vulnérable (genre sous debian/ubuntu le shell par défaut c'est dash depuis pas mal de temps)

Si c'est pas une question rhétorique: l'invocation CGI ça fout les paramètres dans l'environnement -> l'environ d'un script CGI est partiellement sous contrôle d'un tiers

Si tu as un script CGI en bash (lol) ou qui invoque bash indirectement via system() ou autres (beaucoup moins improbable):

- avec un bash pas patché, il est possible de définir une fonction *et de l'invoquer* via env
- avec un bash patché, il est toujours possible de définir une fonction via env, mais il faut ensuite qu'elle soit invoquée donc il faut avoir un script bash qui va appeler genre HTTP_COOKIE, ce qui est un poil moins probable.

Il y a d'autres vecteurs, ils n'ont pas l'air trivialement accessibles à des utilisateurs non loggés (ou alors c'est déjà un canal complètement pas secure genre telnet)

C'est une fitioure

Non, vraiment:

Bah on verra : au passage, mon n+1 a parle a mon n+2 de mes envies d'ailleurs.
Et aujourd'hui, c'était la réunion semestrielle du pôle (dont le responsable est mon n+2)... Je lui ai posé plein de questions un peu chiantes sur l'avenir, la stratégie, tout ça...

Je pense que je le verrais demain.

wtf

 
vous faites bien de fuir. Techno d'il y a 20 ans et interface graphique digne d'harko enrobées dans des bugs insupportables.

Coverage à 98%, 10loc pas testées dans un fichier => 2 bugs /o\

 
Intéressant (même si ça m'empêche pas de penser que c'est quand même con )

https://www.trustedsec.com/septembe [...] f-concept/

Vérifiez si vos nas ou routeurs sous linux ont bien busybox en sh

Oui mais pour un bol de riz, ils vous accueillent le matin avec le sourire  

Malheureusement, bash est tellement tordu et complexe que je crains que ça ne soit que le premier d'une longue série d'exploits du même genre. Et si ce n'est pas bash, potentiellement n'importe quel shell peut présenter des exploits similaires à Shellshock.  
 
D'ailleurs http://www.reddit.com/tb/2hehiz
 
Pour moi, ce truc est une nouvelle classe de trous de sécurité qui est pire que ce que l'on a connu jusque là (d'ailleurs, je trouve assez irresponsable que l'annonce ait été rendue publique avant qu'une solution aux divers vecteurs aient été trouvés).
Le problème, c'est qu'il me parait très difficile, voire illusoire, de répertorier tous les exploits possibles des divers interpréteurs shell existants. Contrairement à du C, où l'on connait à peu près les divers modes d'injection de code, j'imagine que les divers shells présentent des myriades de possibilités de ce coté-là, dont la plupart ne sont vraisemblablement pas connues. A mon sens, le seul moyen de se prémunir contre l'ensemble de ces exploits est d'interdire tout bonnement l'appel à system() ou autre commande similaire qui exécute du shell arbitraire comme popen(). C'est d'ailleurs une recommandation de sécurité bien connue.
 
Le Apple Secure Coding Guide recommande, dans le chapitre "Avoiding Injection Attacks and XSS":

 
J'ai toujours pensé, comme j'imagine pas mal d'autres gens, qu'il était plus que temps de remplacer le shell par un interpréteur plus sain par défaut sous Linux, et sous Unix en général. Ce n'est pas les langages qui manquent: Python, Lua, etc.

 
Mon expérience me fait dire que non tu n'es pas seul. Ou pas avant que tout le monde soit parti.

moi j'en ai pas ecrit ni installe volontairement de script CGI en shell, mais est-ce que la machine est livree avec, est-ce que apache joue avec ca dans la config par defaut du mac ?

C'était prévu entre nous.

Je vois pas le problème, c'est son boulot

Je pense aussi qu'il y a une partie du boulot qui consiste à sentir partir les employés. Effectivement si la personne en parle explicitement, il est aussi normal d'évoquer le fait que ça va remonter (notamment aussi pour essayer de trouver des solutions à ses frustrations).

Un bon manager, il doit effectivement remonter ce genre d'alertes. Moi, j'ai alerte mon n+1 qui est un mec en qui ai confiance, parce qu'il l'avait vu venir en entretien annuel, et m'avait demande de l'avertir si j'en avais vraiment plein le cul.
Il remonte l'info, il se trouve que ça coïncide avec l'annonce de son départ, c'est un bon moyen de mettre une forme de pression au dessus... Après, on verra ce qu'ils vont proposer : je suis pas contre une évolution dans la boite, j'arrive même avec une proposition d'organisation. mais je voudrais un minimum de garanties.
Mais il peut aussi m'envoyer chier, on verra bien.

NP : Sum 41 - Heart Attack
 
Ils étaient quand même pas mauvais ces cons là.

 
Par contre ce code malicieux, il s'exécute avec quels privilèges ?
 

Ceux du process qui appelle bash

Sinon, une idée pour vérifier facilement si une livebox, par exemple, est vulnérable ?

BAH quoi? il est pas tenu par un quelconque secret

Ca dépend si l'entretien se fait sur un sofa en cuir.

Y'a une data structure qui permet de faire un truc du genre:
 

if (x, y) in structure: #Matches (x, y) or (y, x)
     return True

if (x, y) in structure: #Matches (x, y) or (y, x)
     return True

Je sais pas mais

if (x, y) in structure or (y, x) in structure: #Matches (x, y) or (y, x)
     return True

ça va pas ?

if (x, y) in structure or (y, x) in structure: #Matches (x, y) or (y, x)
     return True

Petite précision, (x,y) et (y,x) c'est la même chose dans mon code. En tout cas, je ne veux pas de doublon.
Autre chose, il faut que la structure soit implémentable en js