Algunas sorpresas revisando código

Un artículo que nos muestra lo truculentos que pueden llegar a ser los lenguajes de programación y sus características avanzadas. En particular, lo que podría pasársenos por alto haciendo revisiones de código. En SEC Consult Vulnerability Lab released a new whitepaper titled: “The Source Is A Lie” el resumen y un enlace para descargar el documento.

Seguridad y código de terceros

Una parte muy importante del desarrollo de programas tiene que ver con la reutilización del código (en sentido estricto o a través de bibliotecas) de otros. En Software [In]security: Third-Party Software and Security hablaban de cómo eso puede ser una fuente de inseguridad (o de seguridad, claro, que siempre hay quien lo haga mejor que nosotros).
Interesante.

Cómo pone Facebook el código en producción

Aunque no es un documento oficial de la compañía y en algunos casos se basa sólo en suposiciones o cosas que leyó/escuchó en alguna parte, me ha parecido interesante el documento How Facebook Ships Code. Cita citable:

Most engineers are capable of writing bug-free code. It’s just that they don’t have an incentive to do so at most companies. When there’s a QA department, it’s easy to just throw it over to them to find the errors

Diaspora: lecciones de seguridad

Diaspora es el autoproclamado proyecto de un sistema de redes sociales (como Facebook, por ejemplo) respetuoso con nuestra intimidad y privacidad. Se trata de un proyecto de código libre y recientemente liberaron las primeras muestras que ya han provocado algún comentario. En particular, en Security Lessons Learned From The Diaspora Launch muestran algunas pegas.

Es interesante porque, en este caso, contradice aquel aviso típico de que aunque se tenga el código fuente, no tiene porque mirarlo nadie, puesto que en este caso alguien ha mirado el código.
Naturalmente, el tratarse de software libre no le proporciona poderes mágicos y, en este caso, parece que los desarrolladores están más preocupados por la privacidad que por la efectividad de su código a la hora de salvaguardar los contenidos del sitio y esas cosas.
Vale la pena echarle un ojo porque son ejemplos de código con errores concretos que nos puede servir para aprender.

Alguien puso un troyano en mi servidor de IRC

Ya hemos hablado antes de estos temas: un programa de código libre no tiene por qué ser auditado por nadie externo y puede tener problemas de seguridad. En este caso el ejemplo es el UnrealIRCd Popular servidor de IRC troyanizado desde hace unos 8 meses.

A pesar de ser un programa veterano (desde 1999), un cambio en los archivos fuente de ciertos servidores ha pasado desapercibido durante unos 8 meses. Es uno de los periodos más largos que podemos recordar en los que un programa troyanizado ha pasado inadvertido. Los desarrolladores deberían haber realizado una mínima auditoría del estado de sus servidores y archivos. No se tiene información de cómo han conseguido entrar en los servidores.

Creemos que es irrelevante que la puerta trasera fuese “visible” en el código fuente descargado. Esto no ha “acelerado” su detección. Aunque ha sido compilado por (probablemente miles de) administradores, nadie ha detectado el problema (o nadie ha avisado). Esto es lógico en proyectos de cierta envergadura: simplemente, es muy poco probable que un usuario ocasional detecte algo “raro” en un código ajeno de miles de líneas. Mantenerlo a punto es responsabilidad de los desarrolladores principales, no de las personas que lo descargan.

Ya habíamos comentado sobre fallos añejos en Un fallo de 17 años y El mito de los miles de ojos.

Inyeción anti-descompiladores

Curiosa aproximación la que se relata en Decompilation Injection (pdf).

No controlo mucho las interioridades de .Net pero por lo que cuentan los autores la idea se basa en que dentro del ‘bytecode’ que genera el compilador las normas permiten aplicar algunos truquitos que harían el código fuente inutilizable cuando se utilice un descompilador: cambiar el nombre de una variable por ‘for’ (que al descompilar produce una palabra reservada donde no debe haberla); cambiar el nombre de una variable por el de otra del programa (con seguridad dentro del ejecutable por el espacio de nombres protegido pero con total confusión en el fuente descompilado) e incluso el cambio de nombres de variables por expresiones más complejas.

Los cambios propuestos son muy sencillos y no se llevan a sus últimas consecuencias pero la idea merece la pena explorarse y, seguramente, podría aplicarse también a programas desarrollados en Java.

Un paso más allá en la ofuscación de código necesaria cuando uno quiere ocultarlo y utiliza lenguajes que se basan en el ‘bytecode’ que no es tan complicado ni oscuro como el binario producido por los compiladores tradicionales. Para los que también hay herramientas, claro.

El mito de los miles de ojos

Uno de los avisos que siempre hay que dar sobre la seguridad del software libre es que hay que ser prudente: el hecho de poder mirar el código no significa que realmente alguien lo vaya a mirar; o que si lo mira, tenga los conocimientos adecuados para encontrar los problemas; o que mire en el sitio adecuado. Por eso viene bien este ejemplo Elevación de privilegios en el kernel Linux desde el año 2001.

Como el título indica, se trata de un fallo que estaba presente desde hace bastantes años, esperando a que cualquier auditor lo encontrara y que ha aparecido recientemente.

No estoy diciendo que eso pase frecuentemente, pero es algo que no debemos olvidar, sobre todo si nuestro proyecto no es uno de los ‘grandes’.

El código fuente de la misión Apollo 11

Empezamos suavecito y con una noticia no muy novedosa, pero que quiero tener en el ‘archivo’ (¿para qué sirve una bitácora si no le sirve al propio autor, aunque sea de memoria?). El 20 de julio se celebraba el cuarenta aniversario de que el hombre (la persona, poniéndonos modernos?) pisara la luna. Para celebrarlo el código fuente correspondiente al módulo de control y al módulo lunar ha sido transcrito (a partir de imágenes escaneadas) y publicado. Lo contaban en Apollo 11 mission’s 40th Anniversary: One large step for open source code y se puede visitar la página del proyecto, Virtual AGC — AGS — LVDC — Gemini y virtualagc donde se puede ver el código.

OWASP Security Code Review Guide v1.1

Anunciaban el otro día que OWASP acaba de publicar la versión 1.1 de su OWASP Code Review Project. Se trata de una guía que puede leerse en la web, pero también descargarse (por ejemplo, OWASP Security Code Review Guide (pdf), con 216 páginas).

Cuando hablamos de revisión del código ya no estamos hablando de desarrollo seguro (en todo caso, de una de sus partes) pero para gente que está aprendiendo puede ser muy bueno conocer estos aspectos para comprender mejor todo el contexto.