Quote of the GET: Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris. Larry Wall

cryptographic apocalypse

Well, maybe I was a little noisy with my first DSA. I will try to be quieter next time :)

I think that many people are being very unfair with the OpenSSL’s maintainers. They made (and are making) a really good job. Was an accident, that things happens.

What we need is a real auditory process of the Debian specific patches. It’s hard, but it’s necessary.

RSS feed

18 Comments

avatar
Comment by j_b
2008-05-13 18:28:14

Thanks for finding the bug!

 
avatar
Comment by anonymous
2008-05-13 23:00:37

pat just doesnt add unnecessary patches to the programs, right from upstream ;)

nacho

 
avatar
Comment by lbello
2008-05-13 23:12:10
 
avatar
Comment by anonymous
2008-05-14 01:14:36

Gracias Luciano por el dato y felicitaciones, un orgullo que sea argentino el que contribuyo alertando este problema.

Quiero expresar algunos comentarios sobre este incidente, por favor no interpretar como que quiero hacer lena del arbol caido…

Leyendo el infaltable post de slashdot sobre este tema [1] mi sensacion fue de estar viviendo algo irreal ….

Yo, que me considero un programador de cuarta, antes de comentar/eliminar cualquier codigo:

i) analizo cuidadosamente quien y como usa cada una de las variables a eliminar

ii) corro rigurosos tests que yo le llamo de “continuidad de normalidad” … es decir, que todo el codigo afectado por la modificacion se siga comportando como lo hacia antes

Y me falta algo que no hago pero que deberia hacer: que alguien mas revise lo que hice para tener una segunda( si fuera tercera, cuarta mejor ! ) opinion.

Yo, repito , que soy un “aprendiz” en comparacion a los programadores que hay en el mundo hago esto y hoy me entero que Kurt Roeckx, el “encargado de paquete”, de ni mas ni menos que openssl hace dos cambios al fuente md_rand.c , a saber:

i) comenta intencionalmente una linea de codigo con el objeto de que un debuggeador ( valgring ) no se “queje” , pero con el efecto secundario ( sabido por Kurt ) de que se disminuira la entropia en la generacion de claves criptograficas.

Me pregunto. Como puede ser que una persona decida tan facilmente que debian va a generar de golpe y porrazo claves criptograficas con menos entropia que las demas distribuciones linux? Como puede ser que la mayoria de los usuarios de Debian ni se hayan enterado de tamano cambio de comportamiento en un paquete tan pervasivo.

ii) comenta ( quiero creer inintencionalmente ) otra linea de codigo que tiene el efecto secundario de desactivar completamente la incorporacion de entropia efectiva a la generacion de claves criptograficas en openssl

Y no puedo dejar de preguntar: como puede ser que la reputacion, imagen e historia de una distribucion tan buena como Debian quede en las manos de una sola persona, que como todas puede cometer errores ( aun errores de programador amateur como estos ) ?

Leyendo el bug que motivo este desafortunado patch, no veo en ningun momento que el equipo debian de openssl haya “consensuado” el cambio , porque se commiteo el patch entonces ?

En el mismo sentido a lo que dijiste en tu post, creo que esto debe servir para que Debian incorpore politicas de testeo de codigo y auditorias tipo “peer review”, por lo menos en paquetes delicados y pervasivos como estos.

Un saludo desde cordoba

Orlando

[1] http://it.slashdot.org/article.pl?sid=08/05/13/1533212&from=rss

 
avatar
Comment by anonymous
2008-05-14 02:18:39

> I think that many people are being very unfair with the OpenSSL’s
> maintainers. They made (and are making) a really good job.

Thanks.

> What we need is a real auditory process of the Debian specific patches.
> It’s hard, but it’s necessary.

That’s undoubtedly a good idea, but any interference between the user of an application and that application’s author should be as strictly contained as necessary (to borrow from Ben Laurie’s apt turn of phrase). Even an application’s author can make cockups, and they know the code inside out. So maintainers should really be careful about changing anything that they know many orders of magnitude less well than the author. I think that stands to reason. OTOH, organising paths, environments, configurations, [...] is something that each application should avoid reinventing (badly) for all possible distributions, that is where distribution maintainers are essential.

But that’s *not* what occurred here, this was a patch to the low-level code that had no distribution- or usage-specific nature to it, and if the maintainer really did think he had found such a significant openssl bug, alerting the developers and checking the FAQs would have soon averted this issue. As can be seen from the posting to the mail list (and my response, and a couple of other emails in the thread), the discussion was standard FAQ fare as you see on many support lists when common questions come up;
http://marc.info/?l=openssl-dev&m=114651085826293&w=2
We did point out the misunderstanding (“build with -DPURIFY”) at that time, but there was no context to indicate that any mission-critical installation was actually going to get patched, let alone hundreds/thousands of installations getting patched via the packaging of a major linux distribution!!

C’est la vie. But I think it’s important to note that even more important than the audit process of the contents of patches, is the process by which patches are able to exist and continue to exist in the first place! IMHO it would be worth requiring that any patch like this (that by its nature presumes to fix an up-stream bug) be tied to a filed bug report that is monitored regularly. If you think that will be unworkable because of unresponsive up-stream projects, then either disable those packages or fork the up-stream projects, at least for security-sensitive packages like openssl. Allowing patches that have nothing to do with the distribution itself and that aren’t being actively pursed should be your first cause for alarm, irrespective of what those patches are alleged to fix.

 
avatar
Comment by lbello
2008-05-14 14:39:38

El problema no surge de los regression test. El bug original por las que aquellas lineas fueron comentadas es público, y el mantenedor preguntó en la lista de desarrolladores de OpenSSL sobre el tema y tuvo una respuesta ambigua.

El error no fue evidente y estuvo durante 2 años. A diferencia de lo que ocurre en RL, puede pasar que errores sencillos en cuanto a lineas pero no-triviales en cuanto a sus efectos lleven a catástrofes.

Debian tiene un compromiso con los usuario de no ocultar los problemas y, una vez más, cumplió. Los errores ocurren y lo importante es reaccionar bien ante ellos. Como submitter del problema, puedo decir que el proceso fue realmente corto y expeditivo. Eso habla muy bien de esta excelente distribución.

Un consejo, si no sos un gran programador (e incluso si lo fueses), no deberías tratar de “aprendices” a las personas. Es solo mi opinión.

 
avatar
Comment by alexav8
2008-05-14 20:50:42

eyy, tanto que tanto con el OpenSSl
me hablabas y me lo contabas…..era verdad!!!!!!
jajaa, lo tenías que haber usado para la tesis…..
besos y felicitaciones
pero y debian???
que hacemos ahora??
directo a la debconf…………………..

 
avatar
Comment by anonymous
2008-05-14 22:54:16

I found this post by Eric Schubert [0] very clear and the only one (that I found) who took the time to investigate a little.

Lucho, I’m gonna make a t-shirt that states: “Luciano Bello es mi amigo” and I will wear it proudly, for everyone else’s envy =P

Why do I see different comments when reading your post from RSS than when I see through a browser? =/

Todo mal con slashdot, they don’t mention you in the article.

Un abrazo!

tuxie_

[0] http://blog.drinsama.de/erich/en/linux/2008051401-debian-openssl-desaster.html

 
avatar
Comment by anonymous
2008-05-15 09:37:14

[[ post en dos partes, parte 1 /2 ]]

>El problema no surge de los regression test.

no me referia especificamente a un regression test. Me explico: si estas tocando el codigo que afecta el RNG y ademas *sabes* que estas tocando codigo que puede afectar la entropia en dicha generacion ( Kurt lo sabia ) o como cualquier toque puede meter algun efecto secundario no deseado ( esto, cualquier programador con experiencia lo sabe , el codigo es “traicionero” ;-), *tenes* que correr un test que asegure que el RNG *sique* funcionando igual que antes. Kurt no lo hizo.

Un test podria haber sido el siguiente ( extraido de http://mag.entropy.be/blog/2008/05/13/how-badly-debianubunutu-openssl-is-fscked-up ):

for i in `seq 100000`; do openssl rand -base64 40 >> test; done

$ wc -l test; cat test | sort| uniq -c | sort | tail

En debian no parchado ese tail final te muestra una cantidad grande de claves repetidas

>El bug original

AFAIK no habia ningun “bug” en md_rand.c . Solamente una asignacion de memoria no inicializada *intencional* y ademas comentada con un #ifdef PURIFY para permitir compilar sin esa asignacion para satisfacer debuggeadores quejosos. Una de las respuestas en la lista openssl-dev a Kurt fue clara al respecto

“There’s your first clue, build with -DPURIFY :-)

Cheers,
Geoff [Thorpe] ” ( http://marc.info/?l=openssl-dev&m=114654760312453&w=2 )

>y el mantenedor preguntó en la lista de desarrolladores de OpenSSL
>sobre el tema y tuvo una respuesta ambigua.

veo dos problemas aca, ambos graves:

i) el mantenedor debian de openssl pregunta y admite en una lista publica que no sabe que efecto va a causar comentar esas lineas ( “But I have no idea what effect this really has on the RNG” ). Mi respuesta para Kurt es: si no sabes analizar el codigo de openssl, *no toques* mas codigo openssl, el riesgo es demasiado grande. Deja a los upstream hacer este tipo de modificaciones, que se supone que ellos si saben.

ii) tal como vos decis, Kurt recibio una respuesta “ambigua” en openssl-dev, por lo tanto _con mas razon_ no deberia haber committeado ningun cambio y asegurar un total consenso, pre-analisis de impacto y peer review de un cambio tan importante

( me hace acordar de una pelicula “Carlito Way”, donde el personaje que hacia Sean Penn era instado por Al Pacino en joda a prepear a unos mafiosos y Sean Penn se lo cree en serio y sale a prepearlos y casi lo matan … es una conducta tipo exceso-de-cafeina-y-confianza-en-uno-mismo muy peligrosa … salvando las distancias y valga la analogia )

>El error no fue evidente

porque la correccion no fue evidente … este tipo de correcciones *tienen* que ser evidentes . Como sabras, no todos las modificaciones de codigo provocan problemas evidentes … como decis mas adelante hay bugs muy oscuros provocados por cambios “sencillos”; justamente este tipo de errores es mas facil prevenirlos analizando cuidadosamente lo que se modifica, haciendo tests, consensuando los cambios y peer reviewing

 
avatar
Comment by anonymous
2008-05-15 09:37:51

[[ post en dos partes, parte 2 /2 ]]

>Debian tiene un compromiso con los usuario de no ocultar los problemas y,
>una vez más, cumplió.

por supuesto y eso es una de las cosas que nos diferencian del software propietario, no estoy para nada criticando eso, pero lamentablemente , eso no le quita gravedad a lo que paso

> Los errores ocurren

pero pueden no ocurrir, o por lo menos tenemos que tratar de que no sea cierta la frase que escuche decir a alguien en slashdot ( estupendo slogan para la gente de marketing de Microsoft ):
“el software abierto es tan bueno y seguro como lo sea el ultimo programador de la cadena”

En Debian no tiene que haber un unico ultimo programador en la cadena. Repitiendo lo que dije antes: “como puede ser que la reputacion, imagen e historia de una distribucion tan buena como Debian quede en las manos de una sola persona, que como todas puede cometer errores”

>Un consejo, si no sos un gran programador (e incluso si lo fueses),

no , justamente si lees mi comentario me considero un aprendiz ( en relacion a “la media” de programadores en el mundo )

>no deberías tratar de “aprendices” a las personas.

en este caso, me trate a mi mismo de aprendiz :-) y siempre fui modesto

Si te referis a Kurt Roeckx, mi opinion con respecto a esa persona ( y seria la misma opinion si fuera yo el que cometio el “accidente” ) es que

————————
Kurt Roeckx no tiene que hacer committ de ninguna linea mas de codigo en debian ( por lo menos en paquetes pervasivos y core como openssl ) hasta que (esperemos) se fijen politicas que manden el testeo previo de impacto , regresion test, claro consenso del cambio en el equipo de mantencion, peer review , firma obligatoria del patch de por lo menos una persona mas ademas del originador del patch y una clara publicacion en debian de los cambios debian-particulares en paquetes upstream sensibles.
————————

>Es solo mi opinión.

gracias por contestar y te pido que no tomes mi respuesta como un ataque a debian. En mi casa tengo 3 ubuntus instalados, y en server siempre admire a Debian. ( aunque ahora no estoy en mi casa y esto lo estoy escribiendo en un puppy linux fire hydrant :-)

Un saludo

orlando

 
avatar
Comment by lbello
2008-05-15 19:46:30

Es realmente mucho lo analizable acá y entenderás que son días complejos.

Si no te molesta, voy a tomarte el tiempo para responderte con detalle en un par de días, cuando baje el agua. Mandame un correo así te aviso cuando te tenga la respuesta.

saludos, luciano

 
avatar
Comment by anonymous
2008-05-16 10:47:09

Terremotos, Tornados, Huracanes, Tsunamis, Volcanes … ahora esto … Revelación planetaria????

Un exito lo suyo.

 
avatar
Comment by anonymous
2008-05-16 14:44:39

Lucho, felicitaciones por el descubrimiento. Con él lograste prevenirnos de posibles problemas mayores.
Un orgullo tenerte en la comunidad de Software Libre de Argentina.

Seba Criado

 
avatar
Comment by anonymous
2008-05-16 18:37:58

Felicitaciones Luciano!!!

F. Martinez

 
avatar
Comment by anonymous
2008-05-17 21:38:21

En ubuntu casi estan que les da infarto.

http://www.gtlib.gatech.edu/pub/ubuntu-releases/kubuntu/hardy/

Muchas gracias por estudiar lo importante.

Julian.

 
avatar
Comment by anonymous
 
avatar
Comment by anonymous
2008-05-27 23:19:46

Hola… me gustaría que me ayudaran en conocer exactamente que versiones de Openssl han sido afectadas, por ejemplo tengo instalada en mis máquina debian las versiones 0.9.8d, 0.9.8c y 0.9.7e … existira alguna lista de las versiones afectadas?

 
avatar
Comment by anonymous
2008-06-03 16:46:00

Luciano excelente trabajo.

Saludos
Marcelo Barreto

 

Sorry, the comment form is closed at this time.