Buffer overflow

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

se

en

un

guarda

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
que
escrito

ya
y

algo
estaba
por

lo

tanto lo que estaba escrito se pierde, y si resulta que lo qu estaba

escrito es la siguiente instruccin del programa?

Simple, al ya no

existir, el programa se cae.

Pero seamos ms negativos, que pasara si lo que se sobrescribiera
fuera la rutina de seguridad del programa y el ataque fuera 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 que realmente no
asignados, por ejemplo dentro de los lenguajes tenemos algunos
entre los que podemos observar cuales son Strongly Typed y que por lo
tanto son seguros y otros que no lo son.

Language/Environment
Java, Java Virtual Machine

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

(JVM)

https://www.owasp.org/index.php/Buffer_Overflows#General_Preventi
on_Techniques

Se denomina shellcode al cdigo ejecutable especialmente preparado

que se copie al host objeto del ataque para obtener los privilegios del
programa vulnerable.
As mismo dentro de los lenguajes, aquellos que no manejan
apropiadamente el acceso a la memoria y especficamente a los datos
dentro de esos espacios de memoria son vulnerables a este tipo de
error, en contrapunto aqu presentamos un listado de lenguajes 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.
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 especificamente 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