La mise à jour, lors d'urgences frénétiques, de logiciels
critiques, est une occupation courante sur
l'
Annoncée le 28 juillet par
l'ISC, cette faille, spécifique à BIND (contrairement à la
faille Kaminsky), vient
d'une mauvaise analyse des requêtes de mise à jour dynamique
(
Jul 29 09:10:57 lilith named[2428]: db.c:619: \
REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Jul 29 09:10:57 lilith named[2428]: exiting (due to assertion failure)
(On note que l'
Pour que le serveur soit vulnérable, il faut aussi qu'il fasse
autorité pour au
moins une zone DNS de type
L'exploitation de cette faille a été rendue publique et peut-être
aussi simple que
Domain Name System (query)
Transaction ID: 0x6142
Flags: 0x2800 (Dynamic update)
0... .... .... .... = Response: Message is a query
.010 1... .... .... = Opcode: Dynamic update (5)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Zones: 1
Prerequisites: 1
Updates: 1
Additional RRs: 0
Zone
localhost: type SOA, class IN
Name: localhost
Type: SOA (Start of zone of authority)
Class: IN (0x0001)
Prerequisites
localhost: type ANY, class IN
Name: localhost
Type: ANY (Request for all records)
Class: IN (0x0001)
Time to live: 0 time
Data length: 0
Updates
localhost: type ANY, class ANY
Name: localhost
Type: ANY (Request for all records)
Class: ANY (0x00ff)
Time to live: 0 time
Data length: 0
On peut examiner le paquet complet sur pcapr.net.
La solution la plus propre est de mettre à jour BIND vers une
version sûre, et d'urgence, en suivant la
liste donnée par l'
% dig @ns1.EXAMPLE.net CH TXT version.bind.
et vous obtenez le numéro de version que vous pouvez comparer
à la liste des versions sûres.
Si cette mise à jour est
difficile, pour une raison ou pour une autre,
le plus simple est de « démasteriser », c'est-à-dire de supprimer les
zones de type
Une des raisons pour lesquelles on n'a pas toujours la possibilité
de faire une mise à jour est que les fournisseurs réagissent plus
ou moins rapidement. À l'heure où j'écris,
Une dernière solution pour protéger votre serveur est de demander
au
iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'
Mais cela n'empêche pas tout : comme le filtre ci-dessus travaille
avec des
Si vous voulez capturer les requêtes DNS de mise à jour dynamique,
pour analyse ultérieure, et que vous utiliser dnscap, une requête
comme :
# dnscap -w updates -mu -i eth0
conviendra (