Une "faille" permettant de crasher un 2.6 a distance _sans_ avoir aucun compte ssh ou autre sur la machine vient d'être découverte. Elle se passe sous certaine condition ( règle iptable bien spécifique mais bcp utilisée ).
Elle est de type "char overflow". En effet, si on envoie un paquet d'une taille assez grand, on compteur fait un "overflow" ( pas vraiment, c'est juste un cast ) qui le fait passer à une taille négative. Ceci provoque une boucle infinie ...
Un patch "trivial" est déjà dispo.
Plus d'info la: http://lwn.net/Articles/91914/(...)
Journal Vulnérabilité dans les 2.6
30
juin
2004
# Une decription de la vulnérabilité facile à lire
Posté par Hardy Damien . Évalué à 6.
Dam
[^] # Re: Une decription de la vulnérabilité facile à lire
Posté par free2.org . Évalué à 2.
Quelqu'un l'utilise actuellement ? A quelle fin ?
Enfin tout ça pour dire que de nombreuses personnes ne sont pas affectées par cette faille.
[^] # Re: Une decription de la vulnérabilité facile à lire
Posté par Buto . Évalué à 1.
C'est ajouté dans une règle en entrée aux vérifications des flags des paquets.
[^] # Re: Une decription de la vulnérabilité facile à lire
Posté par free2.org . Évalué à 2.
En entrée et en sortie, je refuse quasiment tous les paquets ne vérifiant pas --state ESTABLISHED (à part des ouverture de connexions vers certains ports comme 80). Cela bloque donc tous les paquets anormaux/spoofed qui ne correspondent pas à une connexion déjà ouverte ou à une ouverture normale de connexion vers un port 80.
Dans ce cas --tcp-option m'apportera-t-il quelque chose ? (j'en doute)
# juste en cas de slashdottage
Posté par plagiats . Évalué à 10.
From: Adam Osuchowski <adwol-AT-polsl.gliwice.pl>
To: bugtraq-AT-securityfocus.com
Subject: Remote DoS vulnerability in Linux kernel 2.6.x
Date: Wed, 30 Jun 2004 12:57:17 +0200
1. Overview
-----------
There is a remotely exploitable bug in all Linux kernel 2.6 series due to
using incorrect variable type. Vulnerability is connected to netfilter
subsystem and may cause DoS. It's disclosed only when using iptables with
rules matching TCP options (i.e. --tcp-option). There is no difference
what action is taking up by matching rule.
Vulnerability was detected on i386 architecture. The other ones weren't tested
but it seems to be vulnerable too.
2. Details
----------
Problem lies in tcp_find_option() function (net/ipv4/netfilter/ip_tables.c).
There is local array `opt' defined as:
char opt[60 - sizeof(struct tcphdr)];
which contains TCP options extracted from packet. Function mentioned above
searches for specified option in this array.
Options in TCP packet, with some exceptions, are organized in the following
way:
Octet no. Length Field
-----------------------------
0 1 Opcode
1 1 Length of all option (N + 2)
2 N Params
The function iterates over options in array:
for (i = 0; i < optlen; ) {
if (opt[i] == option) return !invert;
if (opt[i] < 2) i++;
else i += opt[i+1]?:1;
}
moving counter by the option length.
But, in case the `length' value is greater than 127, the value of this octet
in `opt' is implicitly casted to char, which results in negative number and
the loop counter moving back. In some cases it is possible, that counter
cycles throught the contents of this array infinitely.
3. Impact
---------
After sending one suitably prepared TCP packet to victim host, kernel goes
into infinite loop consuming all CPU resources, rendering the box
unresponsable. Of course, there is no need to have a shell access to attacked
host.
4. Exploitation
---------------
Example of packet-of-death:
0x0000: 4500 0030 1234 4000 ff06 e83f c0a8 0001
0x0010: c0a8 0002 0400 1000 0000 0064 0000 0064
0x0020: 7000 0fa0 dc6a 0000 0204 05b4 0101 04fd
5. Fix
------
There is only need to change type of `opt' array from signed char to unsigned
(or, better to u_int8_t) as it was defined in 2.4 kernel or prior to version
1.16 of net/ipv4/netfilter/ip_tables.c file.
--- net/ipv4/netfilter/ip_tables.c.orig 2004-04-04 05:36:47.000000000 +0200
+++ net/ipv4/netfilter/ip_tables.c 2004-06-24 21:24:26.000000000 +0200
@@ -1461,7 +1461,7 @@
int *hotdrop)
{
/* tcp.doff is only 4 bits, ie. max 15 * 4 bytes */
- char opt[60 - sizeof(struct tcphdr)];
+ u_int8_t opt[60 - sizeof(struct tcphdr)];
unsigned int i;
duprintf("tcp_match: finding option\n");
6. Credits
----------
Vulnerability was discovered, identified and fixed by Adam Osuchowski
and Tomasz Dubinski.
--
## Adam Osuchowski adwol@polsl.gliwice.pl, adwol@silesia.linux.org.pl
## Silesian University of Technology, Computer Centre Gliwice, Poland
[^] # Re: juste en cas de slashdottage
Posté par ckyl . Évalué à 7.
[^] # Re: juste en cas de slashdottage
Posté par plagiats . Évalué à 5.
[^] # Re: juste en cas de slashdottage
Posté par RuleZ . Évalué à 1.
C'est marrant parce que dans mon esprit jusqu'à maintenant, LEN rimait avec "vos emails nous appartiennent" et autre "Big Brother is watching you". Et là, j'ai l'impression d'apprendre que l'arbre cachait une forêt .. mais j'ai beau cherché, je ne tombe que sur du blabla racoleur qui expose soit les bienfaits de la LEN, soit qui crient au scandale et qui exposent ô combien nos libertés sont bafoués sans exposé les détails croustillant ... Rien de bien convaincant dans les deux cas .. J'dois avoir perdu la main avec Google, j'trouve nulle part la version "Interdiction de sécurisé son OS"
[^] # Re: juste en cas de slashdottage
Posté par ckyl . Évalué à 4.
En gros pour la partie "cybercriminalité" c'est un patch "tres discret" pour celui dont ce n'est pas le boulot/passion (la sécu) et qui renforce la loi godfrain. En plus du patch qui augmente les peines a 5 ans de prison et 75000 euros d'amende il y a un petit paragraphe sympatique d'inséré :
--------
« Art. 323-3-1. - Le fait, sans motif légitime, d'importer, de détenir,
d'offrir, de céder ou de mettre à disposition un équipement, un instrument, un
programme informatique ou toute donnée conçus ou spécialement adaptés pour
commettre une ou plusieurs des infractions prévues par les articles 323-1 à
323-3 est puni des peines prévues respectivement pour l'infraction elle-même ou
pour l'infraction la plus sévèrement réprimée.
--------
(323-1 pour les maichant pirate qui DoS^wentrave le fonctionement d'un systeme de données, ou compromettent blahblahblah).
Donc la loi dit clairement
1/ Que tu ne peux pas avoir nessus, nmap, hping ou n'importe quel exploit sur ta machine
2/ Que tu ne peux evidement pas redistribuer de tels outils
3/ Que la publication d'adviso est illegal
4/ Que coder ou rendre publique un exploit est illegal
5/ Encore plein de chose.
Petit exemple perso ca donne ca : http://madchat.org/404(...)
Au total entre 1500 et 2500 fichiers qui ont du etre viré en attente de verification et dont la plupart resterons hors ligne jusqu' a ce que l'implication soit bien clair. De même tout ceux qui pleuraient pour les exploits rendus publiques vont etre content. Tout le monde va se les garder, pensez au bonheur qui nous attend a essayer de comprendre pendant 2 mois pourquoi nos fw explosent :-)
Voila la LEN c'est pas uniquement le blabla sur les courriers electroniques. Tu trouveras quelque ref sur bugtraq (les mecs de K-otik) et autres listes de diff. Ainsi que la plupart des sites offrant du contenu "litigieux" ont adopté l'attitude je vire et j'attend de voir de qu'elle maniere on va etre mangé.
[^] # Re: juste en cas de slashdottage
Posté par Denis Montjoie (site web personnel) . Évalué à 3.
DONC les exploits peuvent toujours etre expliqués, rendu publiques, etc... sur les sites autre que francais.
Ca cest si jai bien compris.
Cest décidé je m'exile en belgique.
[^] # Re: juste en cas de slashdottage
Posté par ckyl . Évalué à 2.
Et il reste encore la possession et le fait de rendre publique (ta ligne ADSL est bien en france). Donc bon ca c'est la reponse facile du genre disclaimer dans les zines des annees 90. Ca rassure le jeune mais je doute que si un juge vient te reveiller ca change quoi que ce soit.
[^] # Re: juste en cas de slashdottage
Posté par plagiats . Évalué à 2.
"Art. 323-3-1. - Le fait, sans motif légitime, bla bla bla"
veuillez m'en excuser monsieur le juge, mais il n'y a pas plus légitime que de mettre en avant une faille et d'en proposer le correctif.
# Crash
Posté par Frederic Bourgeois (site web personnel) . Évalué à 2.
http://linuxfr.org/~stealth/11614.html(...)
et je cherche encore ...
# Kernels mis a jour
Posté par FRLinux (site web personnel) . Évalué à 2.
Steph
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.