O440Manuel Software segurocorr. (1)

Opinión
O440Manuel Software seguro
5500 caracteres
( T ) Software seguro “Buffer overflow”
( C) Manuel Dávila Sguerra
mdavila@uniminuto.edu
En otra columna, planteábamos que la problemática de la seguridad no se
centra solamente en las redes de computadores, es decir, en lo que se
denomina la seguridad perimetral, sino que las debilidades en el desarrollo de
software conforman un hueco de seguridad que casi no se tiene en cuenta.
En esa ocasión, hablamos de la metodología propuesta por Gary McGraw que
sugiere adicionar unas fases más al ciclo de desarrollo de software, que
aseguren la creación de aplicaciones que se autoprotejan.
Lo delicado del riesgo es la falta de consciencia en la ingeniería de software,
que permite que las aplicaciones puedan quedar en manos de los atacantes.
En algunos casos, se trata de gente muy sofisticada técnicamente, como
sucede en el caso del software inseguro y, en otros, simplemente de personas
que usan lo que se denomina la ingeniería social, es decir estrategias
centradas en las debilidades de las personas responsables de la seguridad de
quienes, a través de las relaciones personales o descuidos, se puede obtener
información confidencial. Por ejemplo, lograr averiguar contraseñas para entrar
a los sistemas con roles de administrador.
Gary McGraw, filósofo y experto en Computer Science, es el autor de dos libros
en esta área de la seguridad: Building Secure software y Software security. En
su libro Building Secure software hace una interesante exposición sobre los
modos en que la inseguridad en el software se evidencia y hemos querido traer
a esta columna algunos apartes de sus planteamientos.
Como siempre lo hacemos, cuando hablamos de seguridad informática,
aclaramos que la terminología que usamos para referirnos a las personas que
lideran estos procesos, es la de darle al hacker la identidad de un apasionado
ético de la tecnología y al cracker la de aquellos que se han saltado la línea de
la ética para hacer daño a terceros.
Los crackers no siempre tienen que tener el código fuente en sus manos para
poder hacer un ataque al software. Basta con hacer repetidas observaciones al
comportamiento de un programa para que se evidencien las fallas que lo hacen
abortar antes de que ocurra una terminación controlada. Estas terminaciones
anormales dejan al programa sin su propio control y, por lo tanto, se abre la
posibilidad de leer, con otros programas, los contenidos de la memoria en que
estaban trabajando y poder revisar los datos que quedan en las memorias que
estaba usando el programa abortado. De esa manera, se pueden descubrir
datos confidenciales que estén almacenados en la memoria, contraseñas,
entre otros, que facilitarán ataques o suplantaciones.
Muchos suponen que tener compilado un programa, es decir en representación
binaria, es suficiente garantía para que no sea vulnerado. Pero esto no es así
porque con un conocimiento del lenguaje de máquina y aplicando Ingeniería
reversa se puede desensamblar un programa, de tal manera que se obtenga un
código fuente en lenguaje assembler que es fácilmente manipulable por un
programador que tenga el conocimiento. El resultado es equivalente a tener el
código fuente original, que hasta podría trasladase a lenguaje C u otro lenguaje
en la medida en que se conozcan la gramática del lenguaje y los modos como
los compiladores convierten a binario los programas fuentes.
Según Gary McGraw, y otros autores de publicaciones especializadas, uno de
los problemas más comunes y, de cierta manera, más misteriosos para los
legos debido al nivel de conocimientos que se requiere, es el llamado Buffer
Overflow o Desbordamiento de pila.
Su origen tiene que ver con el manejo de la memoria de los programas donde
se almacenan datos y que conforman los buffers de memoria. Estas áreas
tienen tamaños predeterminados y es de esperarse que en ellas se almacenen
los datos con los tamaños esperados. Sin embargo, si por error, o de manera
consciente, se almacenan cadenas de datos más grandes que los buffer, el
programa, dependiendo del lenguaje y del compilador, sobreescribirá más allá
del área de memoria reservada, afectando posiciones de la memoria que no
deberían ser tocadas por el programa.
La mayoría de la veces estos errores terminan abortando la ejecución del
programa con el riesgo, como ya se dijo, de que un atacante lea la memoria y
extraiga datos confidenciales. El otro peligro radica en que en las áreas
sobrepuestas se introduzca código malicioso que tome el control del programa,
lo que en manos criminales se convierte en un peligro. Este tema puede
aparecer lejano de las posibilidades racionales debido a que encierra un gran
conocimiento, pero dentro del mundo de los desarrolladores no trae grandes
complicaciones.
Hace años trabajé con un antivirus colombiano que fue muy exitoso y que era
capaz de proteger de virus desconocidos. Los antivirus tradicionales lo que
hacían era almacenar las marcas que dejaban los virus en las memorias de los
programas atacados y, de esa manera, reconocer si por ahí había actuado un
virus ya clasificado. El antivirus que menciono no trabajaba así. Él se introducía
en los programas compilados que estaban en lenguaje de máquina y cuando
atacaba un virus, el código inyectado detectaba el ataque y recomponía el
programa a su estado inicial.
Para finalizar, debemos mencionar la existencia de herramientas de software
(Análisis estático) que revisan el código fuente para detectar riesgos en el uso
de instrucciones que abran una brecha de seguridad. Se puede consultar
http://www.cigital.com/ que es la página de contacto con Gary McGraw.