<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">fernando,<div>Me imagino que te referis a UDP....</div><div><br></div><div>Aca te mando una referencia que salió en NANOG sobre avisos de la vulnerabilidad en el 95...</div><div><br></div><div>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><span class="Apple-tab-span" style="white-space: pre; "> </span>With only 16 bits worth of query ID and 16 bits worth of UDP<br><span class="Apple-tab-span" style="white-space: pre; "> </span>port number, it's hard not to be predictable. A determined<br><span class="Apple-tab-span" style="white-space: pre; "> </span>attacker can try all the numbers in a very short time and can<br><span class="Apple-tab-span" style="white-space: pre; "> </span>use patterns derived from examination of the freely available<br><span class="Apple-tab-span" style="white-space: pre; "> </span>BIND code. Even if we had a white noise generator to help<br><span class="Apple-tab-span" style="white-space: pre; "> </span>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..."</div><div><br></div><div><br></div><div><br></div><div>slds</div><div>r.</div><div><br></div><div><div><div>On Jul 11, 2008, at 1:21 AM, Fernando Gont wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>-----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">https://mail.lacnic.net/mailman/listinfo/seguridad</a><br></div></blockquote></div><br></div></body></html>