Buffer overflow attacks

Por: Lenin Tenecela

En pocas palabras el buffer overflow es el desbordamiento de la
memoria preasignada a un buffer de datos, esto quiere decir que
sobrescribimos el espacio asignado a un buffer de datos con ms
datos de los asignados y por lo tanto lo que est de ms se escribe en
un espacio de memoria no asignado, pero Por qu puede resultar
esto peligroso? Cmo y quienes explotan este error de software? y
adems si es peligroso Cmo lo podemos prevenir?
Detallemos, buffer es un espacio de memoria temporal que se asigna
para guardar informacin que va a ser usada por hardware o software
y as agilitar uno o varios procesos, al no tener que estar cargando
dicha informacin varias veces cuando se la necesita usar varias
veces, o para que en este espacio de memoria se guarde informacin
que se va usando de a poco.
Hasta ah ningn problema pero, qu pasa si yo asigno un buffer de 4
espacios de memoria y al guardar los datos en el buffer cargo 5
espacios de memoria, resulta que el proceso se ejecuta y guarda los
datos, pero el 5 espacio de memoria se desborda, es decir se sale
del espacio asignado y se guarda en un espacio de memoria no
asignado. Ac la palabra clave para ir entendiendo por qu esto
puede resultar negativo es sobrescribir, ya que al sobrescribir
estaramos escribiendo algo que ya estaba escrito y por lo tanto lo
que estaba escrito se pierde, y si resulta que lo qu estaba escrito es
la siguiente instruccin del programa?
programa se cae.

Simple, al ya no existir, el

Pero

seamos

negativos,

ms
que

pasara

si

sobrescribir

al
la

siguiente
instruccin

del

programa

se

ejecutar

una

nueva
de

instruccin

un

elemento

externo

del

programa original y
este

burlara

la

rutina de seguridad
del

programa,

implicara que el ataque fuese a propsito para evadir la seguridad

del programa y entrar a partes del programa no permitidas al usuario
comn, esto causara una vulnerabilidad en el programa y por este
motivo es que resulta peligroso y es considerado un error de
programacin.
Este es el motivo por el cual el buffer overflow puede ser muy
peligroso y un ataque a propsito bajo eta modalidad, puede ser
resultar nefasto como sucedi el 2 de noviembre de 1988 cuando se
dio el primer ataque bajo esta modalidad y afect al 10% de los
servidores de aquella poca. Pero, por qu es posible estos ataques
o estos errores?, resulta que existen lenguajes y sistemas operativos
que permiten el acceso directo a memoria sin restricciones y esto
provoca que se acceda a espacios de memoria realmente no
asignados, dentro de los lenguajes tenemos algunos que son Strongly
Typed y que por lo tanto son seguros, pero hay otros que no lo son.

Language/Environment
Java, Java Virtual Machine
(JVM)

Compiled or

Strongly

Direct Memory

Safe or

Interpreted

Typed

Access

Unsafe

Both

Yes

No

Safe

.NET

Both

Yes

No

Safe

Perl

Both

Yes

No

Safe

Python - interpreted

Intepreted

Yes

No

Safe

Ruby

Interpreted

Yes

No

Safe

C/C++

Compiled

No

Yes

Unsafe

Assembly

Compiled

No

Yes

Unsafe

COBOL

Compiled

Yes

No

Safe

https://www.owasp.org/index.php/Buffer_Overflows#General_Prevention_Tec
hniques

Por otra parte, hay ciertos sistemas operativos que adolecen de un

manejo no apropiado al acceso a la memoria y especficamente a los
datos dentro de esos espacios de memoria, por lo que son
vulnerables a este tipo de error, en contrapunto aqu presentamos un
listado de sistemas operativos que hacen un manejo apropiado de
esto.
1. AMD and Intel x86-64 chips with associated 64-bit operating
systems
2. Windows XP SP2 (both 32- and 64-bit)
3. Windows 2003 SP1 (both 32- and 64-bit)
4. Linux after 2.6.8 on AMD and x86-64 processors in 32- and 64bit mode
5. OpenBSD (w^x on Intel, AMD, SPARC, Alpha and PowerPC)
6. Solaris 2.6 and later with the noexec_user_stack flag enabled
Ya mencionado las causas que permiten este tipo de error y
conociendo lo vulnerable que puede hacer esto a un programa es
conveniente que detallemos las tcnicas convenientes para evitar un
buffer overflow, pero debemos antes definir que es shellcode. Se
denomina shellcode al cdigo ejecutable especialmente preparado
que se copie al host objeto del ataque para obtener los privilegios del
programa vulnerable. En otras palabras es el cdigo que inserta el
atacante, al programa vulnerable para tomar el control del programa,
del sistema, y de todo.

Primero mencionaremos las tcnicas generales y luego haremos

hincapi en caractersticas especficas de los diferentes tipos de
buffer overflow y sus correspondientes mecanismos para evitar estos
ataques.
Tcnicas Generales de Prevencin
Luego de leer varias pginas especializadas en este tema como por
ejemplo

http://owasp.org,

http://www.eecis.udel.edu,

ensayos

referentes al tema he resumido una lista de tcnicas de prevencin

que incluira:
1. Elegir adecuadamente un sistema operativo y un entorno web
a. Soporte para Non-executable stacks.
b. Parches
2. Elegir un programa seguro
a. Usar funciones seguras
b. Herramientas de compilacin
3. Ser un programador seguro
a. Hacer auditoras al cdigo
b. Entrenamiento a los desarrolladores
c. Peridicamente escanear el software
Ahora ya hablando especficamente y particularmente de los buffer
overflow, tendramos que hablar sobre los diferentes tipos de overflow
conocidos
Stack Overflow
Estos son los ms conocidos y ms comunes tipos de desbordamiento
que se presentan en las aplicaciones y su forma de ejecucin o
trabajo realmente es muy simple, se da por dos escenarios, primero
en la parte de la aplicacin el buffer de entrada de la informacin es
demasiado pequeo para los datos que realmente van a ingresar a
travs de la aplicacin y segundo en el stack de la memoria, como en
esta parte de la memoria se asigna de manera contigua el espacio de
memoria para los datos que se van a leer y la direccin de registro a
donde se debe guardar, entonces al regresar la informacin supuesta
de la stack esta no devuelve el control a la parte del programa que se

esperaba sino a un cdigo arbitrario elegido por el atacante, hacker,

para que d inicio al ataque en s.
Pero como podemos saber si nuestro programa puede estar expuesto
a esto, si nuestro programa ha sido escrito en un lenguaje que
permite buffer overflow, adems deberamos conocer si nuestro
programa revisa y controla el que al enviar informacin o datos al
stack no sobrepase los tamaos por nosotros especificados.
Estos mismos conceptos son los que permitirn que podamos
protegernos, es decir cuando programamos debemos elegir un
lenguaje de programacin lo menos vulnerable posible y adems
podemos usar herramientas compilacin para evitar eso, as como
controlar que cuando se enva datos al stack no sobrepase los
tamaos determinados, esto mediante validaciones.
Heap Overflow
Estos se dan en cambio en la memoria heap, para entender su
funcionamiento y por lo tanto, cmo podemos evitarlo, debemos
recordar que en el rea de memoria heap se alojan las aplicaciones
en tiempo de ejecucin para almacenamiento de datos. Entonces bajo
el mismo concepto de desbordamiento, el heap overflow se dar
cuando se produzca el overflow en el heap y eso tambin se presenta
debido a que nuestro sistema operativo lo permite, as mismo que
para el stack overflow se puede prevenir comprobando los tamos de
los buffer asignados a travs de validaciones y con herramientas para
la compilacin, funciones seguras, auditora del cdigo, etc.
Ahora, estos dos tipos de overflow son en cuanto al espacio de
memoria asignado dentro de la memoria RAM, pero en cuanto al tipo
de overflow, o mejor sea dicho en cuanto al tipo de dato que puede
permitir un overflow, debemos primero y principalmente hablar de los
datos string, cadenas de texto, por qu?, simple, porque estos tipos
de datos no se especifica por parte del sistema, sino por parte del

usuario o programador, y esto se debe a que las cadenas de texto no

son datos primitivos.
El concepto de overflow siempre existi y as mismo se conoca que
por los lmites de espacio de memoria solo se podan hacer hasta
ciertas cosas, lo que no se haba determinado es que el poco
espacio pueda resultar nefasto, porque siempre hasta antes del worn
morris, se hablaba acerca de la falta de espacio numrico y esto que
si est determinado y solventado en la mayora de sistema operativos
y lenguajes de programacin, solo impeda que se haga ciertos
clculos de ciertas maneras.
Pero cuando se dio el ataque mencionado, se demostr y comprob
que al sobrescribir la memoria se puede derivar en ejecuciones no
autorizadas ni por el programador original ni por el sistema y es ah
en donde est el problema.
Para este caso en particular si es necesario hacer hincapi en el uso
de funciones adecuadas ya que por ejemplo las funciones originales
de c en cuanto al manejo de cadenas de caracteres no tenan, ni
tienen, ningn control en cuanto al desbordamiento de buffer debido
a que ninguna de ellas controla de manera natural el tamao de las
variables asignadas aunque el usuario y/o programador hubiera
asignado un tamao especfico.
Por este motivo es que la mayora de los buffer overflow attack se dan
a travs de este tipo de variables. En general si usamos una funcin
que permita al usuario ingresar informacin que finalmente es
manejada por la funcin en s, estamos seguramente expuestos ante
un buffer overflow.
Conclusiones
Si bien es cierto que se ha hecho mucho para evitar los buffer
overflow attack desde su aparicin hasta hoy, tambin es cierto que

se siguen dando rplicas de ese primer ataque y esto no es lo

preocupante, lo preocupante es que se sigan dando a pesar de todo lo
que se ha hecho, por esto implica que definitivamente no es
suficiente.
Pero, por qu no es suficiente?, porque la mayor puerta abierta a los
ataques de esta ndole se dan debido a las ineficiencias de los
cdigos, y esto depende de los programadores, mientras hayan
programadores que sigan haciendo software y no validemos todo
seguramente habr alguien que encuentre una variable o dato que no
sea validado y explote nuestra vulnerabilidad, en esta misma escala
de seguridad pero en la otra parte, mientras existan programadores
que sigan usando lenguajes y/o versiones de lenguajes vulnerables
principalmente en C, se seguirn dando este tipo de cosas, ya que si
el programador no valida debera ser el lenguaje el que nos brinde el
soporte para este tipo de error, por lo menos previniendo como el
caso del canary value.
Subiendo de nivel de seguridades, si todos los programadores
hiciramos

programas

en

lenguajes

no

vulnerables

todos

validramos, la segunda puerta abierta son los sistemas operativos y

el hardware en s, ya que a nivel de lenguaje mquina y memoria RAM
y/o cache, si se pueden dar estos ataques y esto a pesar de que la
mayora de sistemas operativos actualmente tienen protectores de
memoria para evitar esto, pero solucionar esto en cambio sera muy
caro y pienso que por ese motivo no se ha avanzado en ese aspecto,
ya que siempre igual se necesitarn sistemas rpidos, baratos
aunque puedan estar expuestos a estos ataques, pero eso ya ser
anlisis de otro paper.

Bibliografa
http://www.sans.org/readingroom/whitepapers/securecode/buffer-overflow-attackmechanism-method-prevention-386
http://www.eecis.udel.edu/~bmiller/cis459/2007s/readings/buffoverflow.html
https://www.owasp.org/index.php/Buffer_Overflows#General_Pr
evention_Techniques
http://www.tutorialspoint.com/compile_c_online.php
https://es.wikipedia.org/wiki/Robert_Tappan_Morris
http://en.citizendium.org/wiki/Canary_value