PDF de programación - ¿Oscuridad o transparencia?

¿Oscuridad o transparencia?

http://www.death-master.tk/

¿Oscuridad o transparencia?

Todas las mañanas, para matar el tiempo que consume el largo camino a la facultad, me entretengo
ojeando la prensa gratuita (aquí en Madrid es habitual acumular hasta tres y cuatro periódicos al entrar al
metro). Una mañana de hace unas cuantas semanas leí una noticia que, de no estar totalmente seguro que
no era 28 de Diciembre, me habría parecido una inocentada: una conocida marca de automóviles ha
diseñado “el primer coche sólo para mujeres” que además ha sido diseñado por un equipo formado
íntegramente por mujeres.

Podéis hacer una visita a nuestro bien amado google y buscar el término “Volvo YCC” (no había manera de
no mencionar la marca... publicidad gratis xD) para saber cuál es la idea que esas mujeres han tenido de lo
que ha de ser un “coche para mujeres”. Seguramente, si eres mujer, desearías ver las cabezas de estas
“diseñadoras” (http://imgserv.ya.com/images/9/8/982e8235131ca7bi3.jpg) en una pica... no te culpo, si yo
fuera mujer desearía lo mismo.

Ahora (y antes de iniciar otra guerra de sexos), vamos a imaginar que alguien compra ese coche. Para dejar
de martirizar a las féminas (que bastante tienen con ver su género como apellido de ese pseudocoche),
imaginemos que yo mismo me lo compro. Sé que imaginar que tengo el dinero para comprar un coche -más
aún de esa marca- es un gran esfuerzo, pero confío en que tengáis la suficiente imaginación. ;-)

Bien, pongamos que me he comprado mi nuevo y flamante YCC y decido salir a dar una vuelta a probarlo.
Todo va de maravilla hasta que, de buenas a primeras el coche se para y me deja tirado. ¿Qué ha pasado?
Bien, no perdamos la calma, vamos a abrir el capó a ver si veo algo a simple vista... ¡¿Qué!? ¡Este coche no
tiene capó! (Nota: no, no es broma, ese coche NO tiene capó). Yo no soy un hacha de la mecánica, pero
algo sé, y en cualquier caso tengo amigos que sí son bastante buenos con la mecánica... pero no podré
hacer nada ni pedir a ningún amigo que lo haga. La única solución es llevar el coche al taller, donde sabrán
cómo quitar la pieza completa que recubre el motor.

En ese momento empieza a funcionar la parte más pragmática de mi cerebro: ¿qué necesidad real había de
negar el acceso al capó? ¿no sería mejor proporcionar el acceso al mismo y que cada usuario decida por sí
mismo si desea abrirlo e intentar repararlo, o bien llevarlo a un taller y confiar en profesionales? Así se ha
hecho toda la vida y no nos ha ido mal. El que quería aprender mecánica lo hacía y el que no, o buscaba un
taller económico o le pedía un favor a un amigo que entendiera y luego le invitaba a algo (o no, que
caraduras los han habido siempre :-P).

Traslademos ahora esta pequeña parábola al campo del software. Como hace mucho que dejamos de creer
en los cuentos de hadas, sabemos que no existe el software perfecto, y que todos los programas -en mayor
o menor medida- tienen fallos. Pues bien, en el mundo de la seguridad informática existen dos tendencias a
la hora de manejar las situaciones críticas que suponen la aparición de bugs en el software.

La primera tendencia es la de ofrecer toda la información posible sobre el fallo: en qué consiste, cómo
explotarlo, cómo solucionarlo... esta tendencia de “capó abierto” permite al usuario decidir por sí mismo si
desea corregir el problema o esperar a que los profesionales (los responsables del software) lo corrijan. A
esta tendencia se le conoce en este mundillo como “full disclosure” (completamente destapado).

La otra tendencia consiste en intentar que sea conocida la mínima información posible sobre el fallo.
Generalmente se saca un parche para un fallo que ni siquiera ha sido anunciado con antelación. A esta
tendencia se le conoce como “security through obscurity” (seguridad a través de oscuridad) y viene a ser el
equivalente a no poner capó a nuestro coche.

Podéis encontrar más información sobre ambas tendencias en la wikipedia:

http://en.wikipedia.org/wiki/Security_through_obscurity
http://en.wikipedia.org/wiki/Full_disclosure

Death Master, 2005 (GFDL)

Página 1

¿Oscuridad o transparencia?

http://www.death-master.tk/

Dejando de lado las implicaciones legales de este asunto (un tema del que ya habla AZIMUT en su artículo
de opinión) podemos observar que en la comunidad internacional dentro del campo de la seguridad
informática, tanto empresas como particulares se decantan por una u otra tendencia (raramente por un
término medio).

Generalmente, las grandes empresas de software prefieren que la seguridad de sus productos recaiga en la
seguridad por oscuridad, mientras que los expertos independientes (los “hackers”, si es que esa palabra
significa algo hoy en día) suelen preferir el full disclosure.

Pero técnicamente, ¿qué diferencias reales hay entre una y otra tendencia?

La política de seguridad por oscuridad significa en la práctica que dependemos totalmente de la empresa o
particular que ha programado el software para poder corregir fallos. Y esto estaría bien si esos fallos se
siguieran corrigiendo eternamente y se hiciera de forma eficiente, pero... ¿es así?

Hace unos meses Microsoft, el mayor gigante del software hoy en día, anunció que retiraba el soporte de
Windows NT 4.0. En la práctica significa que no se van a desarrollar mejoras ni correcciones para el mismo
nunca más... y que al primer fallo grave que se descubra, todo aquel con ese sistema estará completamente
desprotegido. Dado que el entorno NT casi siempre se ha elegido como solución en empresas o entornos
de producción, no creo que nadie en esas circunstancias se arriesgue a un fallo de semejante magnitud.
¿Solución? Actualizar, previo paso por caja para renovar tooodas las licencias que tuvieras.

En Microsoft los coches no tienen capó. Y cuando ellos deciden que debes cambiar de coche (sin importar
que siga funcionando o no), en el taller te responden que no van a reparar más coches de ese modelo.
Como el “plan renove” pero al revés y poniendo tú la pasta.

Pero voy más allá: ¿de qué me serviría conocer todos los detalles sobre un fallo de diseño en la junta de la
trócola del modelo X del último coche de Microsoft? Aunque ese modelo de coche tuviera capó, al abrirlo
descubriría que no tengo ni idea de cómo ha sido diseñado ese motor ni, por supuesto, de dónde está la
junta de la trócola ni de cómo interactúa con su entorno para trabajar.

No sé si habréis leído los boletines de seguridad de Microsoft, pero a mí es que me da la risa. Parecen
haber sido redactados con la intención de que no los comprendan ni sus ingenieros, y al final lo único que
se entiende es “Descargar el parche”. Pues vale. Por no mencionar las descripciones de las actualizaciones
que podemos encontrar en Windows Update... a mí a veces me da una sensación terrible de dejà vu y no sé
si estoy viendo la misma actualización por enésima vez o si las descripciones se asignan por el método de
“ctrl+c; ctrl+v”.

Por ello, creo que aún cuando las grandes corporaciones del software optaran por el full disclosure, éste no
tendría sentido de ser sin tener acceso al código fuente del software en cuestión. ¡Y ojo! Que no estoy
abogando por el software libre (que también, los que me conocen saben que soy firme defensor del mismo),
simplemente pido derecho a saber en qué estoy poniendo mi confianza.

No sé vosotros, pero si el fabricante de mi coche de vez en cuando enviara cartas a sus clientes diciendo:

“Cuidado, se ha descubierto un fallo de diseño en su automóvil que puede causar que explote sin previo
aviso.”

Yo, cada vez que escuchara un ruido extraño, por más que el mecánico insistiera en que no es nada, no me
arriesgaría a ir a ningún sitio con ese riesgo con ruedas. No hablemos de hacer viajes de 500 kilómetros con
pasajeros.

Últimamente hago bastantes compras online, y consulto los movimientos de mis cuentas desde la página
web de las entidades bancarias correspondientes, por falta de tiempo más que nada (ya se sabe, la vida a la
que nos obliga el stress). Y por el mismo motivo por el que no usaría ese coche sin capó, no uso software
“sin capó” del que no me fío.

Death Master, 2005 (GFDL)

Página 2

¿Oscuridad o transparencia?

http://www.death-master.tk/

Es un hecho que las vulnerabilidades se descubren, por más que las empresas de software pretendan que
no sea así. En muchas ocasiones son avisadas de esos fallos de seguridad y hacen caso omiso de los
avisos. Recuerdo el caso, hará quizá un año o más, de una grave vulnerabilidad en hotmail (aquí es donde
todos los script-kiddies agudizan sus cinco sentidos xD) que permitía resetear el password de cualquier
usuario: el webmaster de “Zone H” avisó en repetidas ocasiones al personal de MSN y no le hicieron caso.
Al final, cansado de la situación, decidió publicar el fallo, lo que obligó al personal de MSN a trabajar a
destajo para corregirlo en una noche y evitar el desastre que se avecinaba (lo siento, script-kiddies, otra vez
será...).

¿No sería mejor haber agradecido la información y haber solucionado con tiempo (semanas) el fallo que
haberlo hecho deprisa y corriendo en una noche? En el colegio, todos hacíamos los deberes el día antes,
pero creo que una empresa como Microsoft no puede permitirse hacer los deberes el día antes. Eso ya no
es “security through obscurity”... eso es “security through idiocy”.

Ahora imaginemos que se descubre una vulnerabilidad crítica en el software X y que el descubridor tiene
otras intenciones bastante más dañinas. Nadie (ni el desarrollador) conoce el fallo, pero todos empiezan a
observar los ataques y sus consecuencias. Con el código fuente disponible, y una política de full disclosure,
es posible que cualquiera encuentre el fallo auditando el código y proponga una solución, mientras que si el
código no está disponible, se hace bastante más complicado el encontrar el pun