1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
Titre: RFC 8021: Generation of IPv6 Atomic Fragments Considered Harmful
Auteur:
Date: Sat 07 Jan 2017 01:00:00 +0100
Lien: https://www.bortzmeyer.org/8021.html
C'est quoi, un « fragment atomique » ? Décrits dans le RFC 6946, ces charmants
objets sont des datagrammes IPv6 qui sont des fragments... sans en être. Ils
ont un en-tête de fragmentation sans être fragmentés du tout. Ce RFC estime
qu'ils ne servent à rien, et sont dangereux, et devraient donc ne plus être
générés.
Le mécanisme de fragmentation d'IPv6 (assez différent de celui d'IPv4) est
décrit dans le RFC 2460, sections 4.5 et 5. Que se passe-t-il si un routeur
génère un message ICMP Packet Too Big (RFC 4443, section 3.2) en indiquant une
MTU inférieure à 1 280 octets, qui est normalement la MTU minimale d'IPv6 ? (Le
plus beau, c'est que ce routeur n'est pas forcément en tort, cf. RFC 6145, qui
décrivait leur utilisation pour être sûr d'avoir un identificateur de
datagramme.) Eh bien, dans ce cas, l'émetteur du datagramme trop gros doit
mettre un en-tête « Fragmentation » dans les datagrammes suivants, même s'il ne
réduit pas sa MTU en dessous de 1 280 octets. Ce sont ces datagrammes portant
un en-tête « Fragmentation » mais pas réellement fragmentés (leur bit M est à
0), qui sont les fragments atomiques du RFC 6946.
Malheureusement, ces fragments atomiques permettent des attaques contre les
machines IPv6 (section 2 du RFC). Il existe des attaques liées à la
fragmentation (RFC 6274 et RFC 7739). Certaines nécessitent que les datagrammes
soient réellement fragmentés mais ce n'est pas le cas de toutes : il y en a qui
marchent aussi bien avec des fragments atomiques. Un exemple d'une telle
attaque exploite une énorme erreur de certaines middleboxes, jeter les
datagrammes IPv6 ayant un en-tête d'extension, quel qu'il soit (y compris,
donc, l'en-tête Fragmentation). Ce comportement est stupide mais hélas répandu
(cf. RFC 7872). Un attaquant peut exploiter cette violation de la neutralité du
réseau pour faire une attaque par déni de service : il émet des faux messages
ICMP Packet Too Big avec une MTU inférieur à 1 280 octets, la source se met à
générer des fragments atomiques, et ceux-ci sont jetés par ces imbéciles de
middleboxes.
Le RFC décrit aussi une variante de cette attaque, où deux pairs BGP jettent
les fragments reçus (méthode qui évite certaines attaques contre le plan de
contrôle du routeur) mais reçoivent les ICMP Packet Too Big et fabriquent alors
des fragments atomiques. Il serait alors facile de couper la session entre ces
deux pairs. (Personnellement, le cas me parait assez tiré par les cheveux...)
Ces attaques sont plus faciles à faire qu'on ne pourrait le croire car :
* Un paquet ICMP peut être légitimement émis par un routeur intermédiaire et
l'attaquant n'a donc pas besoin d'usurper l'adresse IP de la destination
(donc, BCP 38[1] ne sert à rien).
* Certes, l'attaquant doit usurper les adresses IP contenues dans le message
ICMP lui-même mais c'est trivial : même si on peut en théorie envisager des
contrôles du style BCP 38 de ce contenu, en pratique, personne ne le fait
aujourd'hui.
* De toute façon, pas mal de mises en œuvres d'IP ne font aucune validation
du contenu du message ICMP (malgré les recommandations du RFC 5927).
* Un seul message ICMP suffit, y compris pour plusieurs connexions TCP, car
la MTU réduite est typiquement mémorisée dans le cache de l'émetteur.
* Comme la seule utilisation légitime connue des fragments atomiques était
celle du RFC 6145 (qui a depuis été remplacé par le RFC 7915), on pourrait
se dire qu'il suffit de limiter leur génération aux cas où on écrit à un
traducteur utilisant le RFC 6145. Mais cela ne marche pas, car il n'y a pas
de moyen fiable de détecter ces traducteurs.
Outre ces problèmes de sécurité, le RFC note (section 3) que les fragments
atomiques ne sont de toute façon pas quelque chose sur lequel on puisse
compter. Il faut que la machine émettrice les génère (elle devrait, mais la
section 6 du RFC 6145 note que beaucoup ne le font pas), et, malheureusement,
aussi bien les messages ICMP Packet Too Big que les fragments sont souvent
jetés par des machines intermédiaires.
D'ailleurs, il n'est même pas certain que la méthode du RFC 6145 (faire générer
des fragments atomiques afin d'obtenir un identificateur par datagramme) marche
vraiment, l'API ne donnant pas toujours accès à cet identificateur de fragment.
(Au passage, pour avoir une idée de la complexité de la mise en œuvre des
fragments IP, voir cet excellent article sur le noyau Linux[2].)
En conclusion (section 4), notre RFC demande qu'on abandonne les fragments
atomiques :
* Les traducteurs du RFC 7915 (la seule utilisation légitime connue)
devraient arrêter d'en faire générer.
* Les machines IPv6 devraient désormais ignorer les messages ICMP Packet Too
Big lorsqu'ils indiquent une MTU inférieure à 1 280 octets.
Liens:
[1]: http://www.bortzmeyer.org/bcp38.html (lien)
[2]: https://github.com/NICMx/Jool/wiki/nf_defrag_ipv4-and-nf_defrag_ipv6 (lien)
|
