<html>
<body>
<font size=3>Hola Roque,<br><br>
Si, sorry. Me referia a UDP.<br><br>
Obviamente, el comentario de Vixie es acertado.<br><br>
Pero esta clarisimo que, si uno considera que 16 bits del query ID + 16
bits del source port permiten de manera bastante simple los ataques de
fuerza bruta, dejar fijo el source port es un tanto... ridiculo, por asi
decirlo.<br><br>
Si el source port es aleatorio, entonces la cantidad de paquetes
requerida para un ataque de fuerza bruta pasa de 2^16 a 2^32. No es el
cielo, pero... al menos no es tan trivial como 2^16 paquetes.<br><br>
Saludos,<br>
Fernando<br><br>
<br><br>
<br>
<blockquote type=cite class=cite cite="">fernando,<br>
Me imagino que te referis a UDP....<br><br>
Aca te mando una referencia que salió en NANOG sobre avisos de la
vulnerabilidad en el 95...<br><br>
Paul<br>
Vixie described it in 1995 at the Usenix Security Conference<br>
(<a href="http://www.usenix.org/publications/library/proceedings/security95/vixie.html">
http://www.usenix.org/publications/library/proceedings/security95/vixie.html</a>
)<br>
-- in a section titled "What We Cannot Fix", he wrote:<br><br>
With only 16 bits worth of query ID and 16 bits worth of UDP<br>
port number, it's hard not to be predictable. A determined<br>
attacker can try all the numbers in a very short time and can<br>
use patterns derived from examination of the freely available<br>
BIND code. Even if we had a white noise generator to help<br>
randomize our numbers, it's just too easy to try them all.<br><br>
The ISC web page on the attack notes "DNSSEC is the only
definitive<br>
solution for this issue. Understanding that immediate DNSSEC
deployment<br>
is not a realistic expectation..."<br><br>
<br><br>
slds<br>
r.<br><br>
On Jul 11, 2008, at 1:21 AM, Fernando Gont wrote:<br><br>
<blockquote type=cite class=cite cite="">-----BEGIN PGP SIGNED
MESSAGE-----<br>
Hash: SHA256<br><br>
Estimados,<br><br>
Algunos comentarios sobre los alertas recientes sobre la vulnerabilidad
de<br>
"cache poisoning". Es interesante destacar que la
vulnerabilidad reportada<br>
no es propia del protocolo DNS, sino que, si bien es sufrieda por
una<br>
variedad de implementaciones, dicha vulnerabilidad reside en un error
de<br>
*implementación*, y no de protocolo.<br><br>
Básicamente, el problema en cuestión es que las implementaciones<br>
efectadas envían sucesivas peticiones DNS utilizando un mismo TCP
source<br>
port, por lo cual se facilita notablemente la realización del llamado
"DNS<br>
cache poisoning". Ninguna de las especificaciones de DNS requieren
esto.<br><br>
De hecho, la implementación de DNS djbdns no es vulnerable a este
ataque.<br><br>
Pese a la publicidad que ha recibido esta vulnerabilidad en los
últimos<br>
días, esta vulnerabilidad ya había sido discutida publicamente en
detalle<br>
por D. J. Berstein al menos en el año 2001<br>
(<a href="http://groups.google.com/group/mailing.unix.bind-users/msg/92f94d2f940cdfa">
http://groups.google.com/group/mailing.unix.bind-users/msg/92f94d2f940cdfa</a>
<br>
b).<br><br>
(At the risk of sounding our own horn ;-) ), la vulnerabilidad en
cuestión<br>
podría haber sido prevenida implementando aleatorización de puertos<br>
("port randomization") de acuerdo a alguna de las técnicas
descriptas en<br>
nuestro Internet-Draft de la IETF<br>
(<a href="http://www.gont.com.ar/drafts/port-randomization/index.html">
http://www.gont.com.ar/drafts/port-randomization/index.html</a>),
publicado<br>
hace cuatro años atrás. Dicho draft es el resultado de discusiones
con<br>
una<br>
variedad de implementadores, incluyendo algunos de FreeBSD.<br><br>
Dicho eso, está claro que es recomendable que aquellos que se
encuentren<br>
utilizando alguna de las implementaciones vulnerables actualicen las
mismas<br>
de forma urgente. Y también me interesa aclarar que lo anterior no
le<br>
quita crédito a Kaminsky. Está claro que su trabajo a llevado a que
se<br>
parcheen numerosas implementaciones, lo cual es mas que interesante
y<br>
rescatable.<br><br>
Fernando Gont<br><br>
<br><br>
<br><br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: PGP Desktop 9.5.3 (Build 5003) - not <br>
licensed for commercial use:
<a href="http://www.pgp.com">www.pgp.com</a><br><br>
wsBVAwUBSHbfI2l+Jnd3SMmAAQiHEwf/QNgkjiIYmyfvYFipVp13ovVKSJeNHEhn<br>
Y2B05AToqzD7lJM725O1MW7Z+0KVDU1iwLtspDpLjz60nzyiK8b8R+484tE0TAXl<br>
VkTfhbXgOUKuzprUM8Wtx0uV2hfaR7r4ftfC6aXMz8wMU22A/GeY1jsdCyM9y+gf<br>
ofdIqzyA6tZhExIUxbQDutpdDqAROClM7AXTVkMgWoZ0XO5/oCBnGRMBv+txvRn3<br>
zb/DnviA/k/Rg8v0x1Ny3RloyYWebjaCDKgfAymBsYksbUDICRka2jGo9B7vHV1i<br>
ySHQg8NvXAt1Yv70rokUDuHUSF9ROboFaHaH1KFN5lnXIb39Uq+FvA==<br>
=71Vf<br>
-----END PGP SIGNATURE-----<br><br>
<br>
--<br>
Fernando Gont<br>
e-mail: <a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a> ||
<a href="mailto:fgont@acm.org">fgont@acm.org</a><br>
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
FFF1<br><br>
<br><br>
<br>
_______________________________________________<br>
Seguridad mailing list<br>
<a href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/seguridad" eudora="autourl">
https://mail.lacnic.net/mailman/listinfo/seguridad</a></blockquote><br>
<br>
_______________________________________________<br>
Seguridad mailing list<br>
Seguridad@lacnic.net<br>
<a href="https://mail.lacnic.net/mailman/listinfo/seguridad" eudora="autourl">
https://mail.lacnic.net/mailman/listinfo/seguridad</a></blockquote>
<x-sigsep><p></x-sigsep>
--<br>
Fernando Gont<br>
e-mail: fernando@gont.com.ar || fgont@acm.org<br>
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
FFF1<br><br>
<br><br>
</font></body>
</html>