Apple y "goto fail", un fallo de seguridad en SSL/TLS y su posible relación con la NSA

El viernes pasado, Apple lanzaba una actualización urgente para iOS 7. La razón: una vulnerabilidad en el sistema SSL/TLS. Y no una vulnerabilidad cualquiera, sino un fallo muy grave. La librería de Apple no verificaba correctamente la autenticidad de la conexión, de tal forma que alguien podría escuchar sin problemas conexiones aparentemente seguras. La misma vulnerabilidad se ha descubierto también en OS X, y además se ha detectado una enorme coincidencia sobre las fechas en las que ese fallo apareció.

[#3 Desactivado]

No había visto un "goto" desde el año 1984

[#4 Desactivado]

#3 1984 es ahora.

[#10 Desactivado]

#4 Muy bueno

[#5 Desactivado]

#3, tienes que leer más código de kernel (o de aplicaciones RT).

[#41 pys]

#5 Lectura ligera para antes de acostarse

[#25 Or3]

#3 Pues para jugar al MSX era de lo más común durante todos los 80.

[#44 Xtampa2]

#25 Hombre, para jugar precisamente no creo que fuera común, lo sería para programar en el Basic que traían la máquinas en ROM. Para jugar valía con LOAD, BLOAD o CLOAD, dependiendo de lo que quisieras cargar de la cinta. O enchufar un cartucho de Konami y te olvidabas de todo eso

[#50 Or3]

#44 Nosotros es que éramos piratillas ya por aquellos días y para localizar el juego entre los varios que cabían en
la cinta de cassette hacía falta el "goto".

[#61 Xtampa2]

#50 ¿Me puedes explicar cómo lo hacías si lo recuerdas? Yo para hacer eso directamente apuntaba el contador de vueltas del cassette. Y el único control que se tenía sobre él desde el ordenador era encenderlo y apagarlo, no avanzarlo rápidamente.

[#62 Or3]

#61 Nosotros no teníamos nada tan refinado como contar las vueltas. No lo recuerdo exactamente porque fue hace más de veinte años pero creo recordar que ponías la cinta y el ordenador encontraba los juegos. Según los encontraba decidías si jugar o no. Eso si no estaba el dueño del MSX.

Mi primo era el que lo controlaba y recuerdo que usaba el "goto" para dejar pasar los juegos hasta encontrar el que buscaba. Mientras merendábamos y tal.

[#63 Xtampa2]

#62 Joer, en una cinta de 45 mins por cara ya podíais merendar bien si el juego estaba al final

[#64 Or3]

#63 Era un soberano coñazo. Lo de merendar era porque la mayoría de las veces los juegos no cargaban bien o directamente no cargaban. Así que daba igual saber la vuelta en la que estaba el juego, los 15 min de espera no te los quitaba nadie.

[#65 Xtampa2]

#64 Joer, yo cuando grababa un juego o me llegaba una cinta de intercambio lo primero que hacía era "medirla" con el cuenta vueltas y apuntar donde comenzaba cada juego. Luego para cargar no había más que poner el contador a cero y darle al FF hasta que llegara al punto que llegara. Eran unos segundos y luego ya le podía darle a cargar.

[#59 outofmemory]

#25 Teníamos el ON ERROR GOTO xxx, que curiosamente es similar al mecanismo del código que comentamos con los gotos, pero con algo muy similar al control de excepciones. Si es que el MSX es muy grande...

[#26 RubenC]

#3 ¿Y qué te piensas que es el ensamblador? "gotos" a punta pala. Que en los lenguajes de alto nivel (y no tan alto) puedas prescindir de él, vale. Pero cuando bajas del todo, es lo que queda, inevitablemente.

[#55 KimDeal]

#3 a mi me amenazaban con el hambre, la miseria y el ostracismo en el mundo informático si ponía un solo goto... y ya ves, no había para tanto

[#17 Desactivado]

Historia de algunos al respecto:
- Suponer la NSA es demasiado...
- Magufo
- Conspiranoico...

Aparece un Snowden con información:
- Pero esto ya lo sabíamos, ¿no?

[#6 anacard]

¿No creéis que está un poco cogida con pinzas la relación con la NSA? ¿En serio lo relaciona solo porque se parecen la fecha de origen del fallo con la fecha en la que se incluye a Apple en el programa PRISM?

Supongo que tendrán mejores métodos para extraer información que la de dejar una puerta abierta para todo el mundo, si no menudos chapuzas.

[#9 Avantasia]

#6 Una puerta abierta para todo el mundo puede pasar desapercibida como un error de programación, el día que se descubre "uy, que tontos, una linea dos veces, je je" y a otra cosa, pero mientras no se ha descubierto, el que lo puso ahí tiene la exclusividad del 0-day.

Sin embargo algo más personalizado tiene que obligatoriamente tener algo que si se descubre pringue o al programador o al beneficiario: una clave, una lista de ips, nombres, etc..

Un backdoor no siempre es lo que la gente se piensa, no es un troyano, es precisamente de lo que se habla aquí, fallos (o debilidades) puestos deliberadamente en programas y conocidos solo por unos pocos.

[#11 Desactivado]

#6 Más bien esta comentando como lo han relacionado otros, el no apuesta por esa relación.

[#1 gilipipas]

Muy interesante la explicación del error, una línea duplicada que en una revisión descuidada es muy fácil de pasar por alto.

[#7 Mordisquitos]

Yo de programación sé muy poco, pero a simple vista veo que si siguiesen a rajatabla el uso de llaves ( ) para encasillar el bloque de código de cada if, la duplicación del goto sería o benigna (si cae dentro de un bloque) o perfectamente visible como fallo (si cae fuera de un bloque if, donde sí tendría efecto).

¿Algún programador me puede explicar si hay algún buen motivo para no usar llaves después del if cuando sólo se quiere ejecutar una expresión, más allá de "se puede hacer sin llaves y me da pereza ponerlas/me parece feo/va contra mi religión"?

[#8 meneillo]

#7 la respuesta la tienes en la guía de estilo del kernel (enlazada en la noticia):

"Do not unnecessarily use braces where a single statement will do.
if (condition)
action();"

https://www.kernel.org/doc/Documentation/CodingStyle

Es para ahorrar líneas de código.

[#18 gilipipas]

#8 Pues a mi personalmente no me gusta, me gustan mucho más las llaves con su indentación y todo, más fácil de leer luego.

[#57 Desactivado]

#35 En Go las llaves suponen una orden completamente diferente.

http://tour.golang.org/#18

Igual te interesa. Todo binario se compila estáticamente, ergo rula en cualquier sitio, sin dependencias.

[#19 chochis]

#7 #8 Yo siempre intento que la gente ponga las llaves aunque el if sea con una sola condición dentro, ayuda a leer y a encontrar errores mas fácilmente

[#27 Desactivado]

#7 #8 Hay varios estilos, yo personalmente usaría siempre llaves tras un if, ayuda muchísimo y evita este tipo de errores, que vemos que ocurren hasta en los altos niveles.
De la misma manera que para escribir condicionales hay gente escribe:
if ( x ) else

y no así
if ( x )

else


En el articulo de La excepcional belleza del código fuente de Doom 3 [ENG]

La excepcional belleza del código fuente de Doom 3...

, por ejemplo, ellos tienen como estilo escribir las llaves siempre aunque sea para un sola linea de código, aunque al mismo tiempo prefieren esas llaves mas compactas.

[#43 apetor]

#7, #8 Yo os puedo dar una razón por la que SÍ usar llaves siempre, haya una sentencia o más: las macros multiline.

Y si, si veis codigo de kernel -o de usuario, da igual- un poco bueno ( no digo bueno, si no que al menos sea facil de leer ) veréis mucho goto. Un goto ( hacia abajo ) es bueno para salir a cleanups, errors, exits... la arborescencia del código quedará muy académica pero generalmente no es muy mantenible ( y no me salgáis con lo de que con factorizar y separar en funciones hasta el tuetano evita que la arborescencia compleja se haga legible, eso es "es peor el remedio que la enfermedad" ).

[#31 crafton]

#7 ¿Algún programador me puede explicar si hay algún buen motivo para no usar llaves después del if cuando sólo se quiere ejecutar una expresión, más allá de "se puede hacer sin llaves y me da pereza ponerlas/me parece feo/va contra mi religión"? Python, Coffeescript, Ruby...

[#33 hexion]

#31
Hmmm... déjame que piense.... ¿si haces code reviews por SMS, te ahorras 4 caracteres?

[#34 Mordisquitos]

#31 Hombre, ya. Iba implícito que me refería a lenguajes estilo C y no a lenguajes donde simplemente no se usan llaves (Python, etc) o donde las llaves son obligatorias aunque el bloque contenga una sola línea de código (Perl).

[#35 Desactivado]

#31 Python y amigos es la mayor aberración que existe en cuanto a estilo obligatorio por parte del lenguaje. Si escribo código de una forma o de otra, es porque así va a resultar más legible. Claro, hay gente que no entiende eso, y la solución es no permitirles escribir mal... adiós llaves y ¿solucionado? Pues no, luego pasan estas cosas.

#7 La explicación es simple: al escribir código, lo más importante es la legibilidad. Si no, estaríamos todos picando bits en ensamblador. Para facilitar esa legibilidad, hay casos en los que viene bien usar llaves, y añadir comentarios, y avisos, y advertencias... y hay casos en los que un if "poco importante" está mejor un poco menos visible para que no estorbe a la legibilidad del trozo de código entero.

[#39 crafton]

#35 Te he votado positivo por equivocación. No estoy de acuerdo, y menos con lo de aberración. Precisamente lo de la legibilidad es uno de sus argumentos. Si no te gusta no lo uses, pero lo de aberración es una opinión subjetiva y irrelevante frente a una comunidad de cientos de miles de programadores.

[#46 Desactivado]

#39 Oh, ¿y me ibas a votar "racismo/insulto/spam" por llamarlo una aberración, frente a unos cientos de lenguajes con unos cientos de millones de programadores en los que no existe nada parecido? Pos muchas gracias, oye.

La relevancia está clara, y tu comentario la pone aún más en evidencia: el segundo "goto fail;" del código de Apple estaría dentro de la condicional según las normas de Python y amigos, mientras que según las normas de C y la gran mayoría de lenguajes, está fuera.

No verlo solo me hace pensar que ver "Python" en el curriculum de alguien debería ser motivo para descalificarle para cualquier puesto de programación, salvo en Python.

[#47 crafton]

#46 no, simplemente no quería votarte positivo.

en cuanto a lo de las claves, no estoy en contra, cada lenguaje tiene sus propiedades.
Eso no es culpa de no-colons languages, es simplemente despiste/error del programador.

En python, por ejemplo, si no identas petada en ejecución.

No quiero discutir que paradigma es mejor, siempre depende de usos y gustos, por tanto es subjetivo. Simplemente defiendo que no es justo atacar de aberración a los lenguajes sin llaves. Just saying

[#48 crafton]

#46 #47 ...y bueno me discutirás ahora lo de "si no identas petada en ejecución", con razón, ya que no es del todo cierto, pero está pensado para que haga el condicional solo si está identado.

[#54 Desactivado]

#48 En Python el mismo fallo podría haber sido a la inversa: se te olvida indentar (o des-indentas sin querer) la última línea de un bloque condicional, y se ejecuta como si nada. Con el problema añadido de que si copias y pegas el código de un sitio a otro (ej: en un comentario de Menéame), toda la indentación se va al carajo.

Pero ese no es el problema que le veo a Python, que fallos puede tener cualquiera en cualquier lenguaje. El problema gordo es haber cogido una "buena práctica" como es la indentación de bloques, y convertirla en "imprescindible, y al mismo tiempo suficiente" para definir lo que está dentro de una condicional y lo que no. Convertir una "buena práctica" en "ley suprema", ese es el problema.

PD: y eso que sintácticamente Python me gusta bastante, pero el tema de la indentación me parece horrible. Python con llaves, eso sí que molaría... pero como son bastante talibanes al respecto, pos qué le vamos a hacer.

[#60 crafton]

#54
PD: y eso que sintácticamente Python me gusta bastante, pero el tema de la indentación me parece horrible. Python con llaves, eso sí que molaría.. http://writeonly.wordpress.com/2010/04/01/whython-python-for-people-who-hate-whitespace/

[#52 Desactivado]

#46 "[...] el segundo "goto fail;" del código de Apple estaría dentro de la condicional según las normas de Python y amigos, mientras que según las normas de C y la gran mayoría de lenguajes, está fuera."

Exacto, y como en Python estaría dentro no habría problema; nunca se ejecutaría el segundo goto, mientras en C se convierte en un bug del tamaño de un A380.

[#45 Desactivado]

#7 Esto es un tira y afloja entre muchos factores que afectan a la legibilidad del código. El problema está en que al generalizar y/o imponer una norma, en muchos casos va bien, y en otros va mal.
Por ejemplo, en pos de la legibilidad yo puedo decir que un código si es breve, es más legible y, desde luego, se lee antes. Pero claro eso se puede convertir en una aberración, haciendo nombres de funciones demasiado cortos, metiendo llamadas a funciones dentro de llamadas a funciones dentro de llamadas a funciones todo en la misma linea. Luego está lo contrario, nombres de funciones super largos, llaves para todo en lineas separadas... Lo seguro es que sigas la norma que sigas de estilo, nunca estaremos todos contentos.

[#13 Desactivado]

"yo estoy libre de virus y de trojanos, uso mac" dicho por un guardia civil de delitos informaticos

[#14 GoDie]

#13 ¿y que escondía para tener tanta preocupación?

[#15 Desactivado]

#14 yo creo que queria fardar de que tenia un mac mas que nada

[#16 outofmemory]

Evidentemente es intencionado, porque el compilador debe dar un warning al ver que hay código muerto debajo del goto. También cualquier herramienta de lint. Y está claro que en un código que tenga que ver con la seguridad siempre se mira si hay warnings.

[#29 Desactivado]

#16 Pues va aser que no es tan evidente la cosa. SI buscas por internet verás que ni GCC ni Clang daban warnings en ciertos casos. Por ejemplo: https://www.imperialviolet.org/2014/02/22/applebug.html

[#30 outofmemory]

#29 Pues sí: http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html , han quitado la opción del warning por código muerto a partir de la versión 4.4 de gcc
La versión 4.4 aparece el 21 de abril de 2009 y el bug es en 2012, así que tienes razón, gcc no lo detectaría. Aun así, me parece muy sospechoso.

[#2 Nova6K0]

Eso puede pasar, por copiar y pegar código para no volverlo a escribir.

Salu2

[#37 vinola]

Sin con ese "fallo de seguridad" podían escucharlo todo, con el que lleva incrustado esta actualización os vais a cagar!

[#38 Naiyeel]

#37 Ahora directamente lleva un COPY TO NSA.COM

[#51 sauron34_1]

Apple debe leer Meneame, porque acaba de salir una actualización de Mavericks que, entre otras cosas, arregla este fallo.

[#32 hexion]

Noticias como ésta refuerzan los argumentos de nosotros, los nazis de la indentación
_{P.D.: Viva Python!}

[#56 frankiegth]

Regla número de una de NSA : 'Una vez destapada la 'feature' se corrige el fallo.'

[#58 frankiegth]

Edit #56. Regla número uno de la NSA. (Ese tiempo de edición!)

[#23 Desactivado]

¿Se sabe quién descubrió el error/problema? Porque el disponer del código fuente* seguro que ha facilitado encontrarlo...

* http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c

[#36 Desactivado]

Ultradupe http://www.meneame.net/go.php?id=2123093

[#22 Desactivado]

Me parece un método elegantísimo de lograr un MitM.

No sólo el usuario en su día a día no detectará nada, sino que si hay otro intentando hacerle un MitM por el tradicional método de cambiar el certificado del servidor "on the fly", entonces sí que le saltará una advertencia.

Demasiado perfecto para ser casual...

[#24 Varlak_]

La conexion con el NSA me parece un poco cogida por los pelos, pero desde luego con esta gente no te puedes confiar, es perfectamente posible,,, como dice #22 es demasiado elegante como para ser casual

[#28 outofmemory]

Menudo desastre de código, por cierto. Se montan todo ese tinglado del fail para liberar memoria si algo va mal, y te encuentras con líneas como "if ((err = SSLFreeBuffer(&hashCtx)) != 0) goto fail;" que te llevan a una etiqueta que hace un SSLFreeBuffer de lo mismo (!). No digo que no les funcione, pero es chapucero.

[#12 M_M]

goto NSA fail

[#42 Amandy]

Todavía no entiendo la relación de este fallo con la NSA. Está de moda generar visitas encontrando una inexplicable relación entre cualquier cosa y la NSA, Facebook o WhatsApp. Más ética, por Dios.

[#20 Desactivado]

ademas evita estas meteduras de pata..
no se si sera que soy un paquete, pero ami me ha pasado alguna vez de no poner llaves porque solo iba a poner una linea, pero acabar poniendo dos y claro funcionar mal porque la segunda se ejecutaba siempre.

[#21 outofmemory]

#20 Eso con Python no pasa

[#40 esparta]

#21 Podría pasar si no se aplica bien el PEP-8:

[#49 Desactivado]

Claro, van de pros y hace los if sin llaves... Las llaves son una forma que visualmente ayuda a organizar el código...

[#53 conb]

Buenísimo el apunte sobre la guía de estilo, pero creo que #49 tiene razón