Sin embargo, los lenguajes de alto nivel dependen de sus sistemas de tiempo de ejecución para tener acceso a funcionalidad, como por ejemplo una interfaz con el procesador o acceso al sistema de ficheros o a funciones de red, que de otra forma no sería posible. Uno de los ejemplos más populares es Node.js para ejecutar Javascript en el lado servidor. Dichos sistemas de tiempo de ejecución están normalmente escritos en C/C++, lenguajes conocidos por no garantizar la seguridad de la memoria ni la seguridad de tipos, lo que quiere decir que son propensos a errores y un objetivo para los atacantes.

Para interactuar entre dos lenguajes de distinto nivel como Javascript y C++ que tienen distintas estrategias de gestión de la memoria, sistema de tipos, etc., es necesaria una capa intermedia encargada de transformar los tipos y la representación de los valores de forma adecuada para el lenguaje destino, además de propagar los errores producidos. Los problemas aparecen debido a que, en las funciones de la capa intermedia, se deben hacer comprobaciones tales como verificar el tipo de los parámetros, comprobar que los valores son «legales» (como que un índice se encuentre dentro de los límites de un array), que no se hacen en todos los casos, lo que conlleva que se produzcan errores que atentan contra la seguridad de la memoria y la seguridad de tipos.

Tomando como ejemplo la imagen anterior, podemos ver como en la capa superior se han introducido comprobaciones para asegurar que los valores de start y end se encuentran dentro de los límites del buffer antes de llamar a la implementación de fill en la capa intermedia. Por otra parte, el código C++ presupone que los valores de start y end recibidos por parámetros son enteros de 32 bits sin signo.

Esta situación se puede aprovechar pasando un objeto, en lugar de un número, como valor start que ejecute la función Symbol.toPrimitive definida cuando se intente obtener su valor númerico. De esta forma, la comprobación en la capa superior se hará sin ningún problema devolviendo un 0, pero al obtener el valor en la capa intermedia se devolverá un número negativo, dando lugar a un overflow

The post Problemas de comunicacion entre lenguajes appeared first on S3lab.

Sin embargo, la corrupción de memoria abarca todo tipo de alteración involuntaria que se produce en el contenido de una o varias direcciones de memoria, como sucede al operar con un array fuera de sus límites. Por otra parte, dentro de los errores de corrupción de memoria también se incluyen aquellos que producen comportamientos indefinidos o revelación de información al hacer un uso indebido de la propia memoria. Todos estos errores comúnmente se clasifican en dos tipos: espaciales y temporales.

Los errores espaciales son violaciones causadas al operar con un puntero que apunta a una dirección fuera de los límites, superiores o inferiores, de su referente. El buffer overflow/underflow se encuentra en esta categoría puesto que cualquier tipo de operación que resulte en un acceso de memoria fuera de los límites se considera un error espacial.

Los errores temporales se caracterizan por ser causados por el uso de un puntero cuyo referente no es un objeto válido debido a que no ha sido inicializado o ha sido liberado anteriormente (mediante una operación free). Los ejemplos más claros son el use-after-free, en el que se incluyen el double-free y la desreferencia de dangling pointers, y por otro lado el use-before-initialization, como son las lecturas no inicializadas.

Como se ha podido ver en la serie de hardening de binarios de este mismo blog, existen y se siguen desarrollando numerosas soluciones que tratan de mitigar este tipo de errores, ya que desencadenar un error de corrupción de memoria es el primer paso que toman gran cantidad de exploits.

The post Los errores de corrupción de memoria appeared first on S3lab.

1. Elegir un tema que no nos atrae demasiado. El mayor error que podemos cometer en una investigación (doctoral o no), es elegir un área y un tema que no nos guste. La investigación no es un trabajo (o no debería serlo) de 9 a 5, es algo que nos tiene que obsesionar y apasionar hasta el punto de perder la noción del tiempo. Si elegimos de antemano un tema del que lo más que pensamos está por debajo o igual de la expresión “No está mal”, hemos cometido un gravísimo error. Puede que, si somos estudiantes de doctorado, acabemos la tesis doctoral, pero no haremos investigación de primer nivel porque requiere un nivel de compromiso que sólo se puede obtener si hay vocación. Los motivos para hacer esto son variados y el más común es el de disponibilidad y no querer mudarse y hay que evitarlos.
2. No hablar/discutir/pelear con el director de tesis/supervisor. Como ya comentamos en la primera entrega, nuestro director de tesis tiene que reunir unas ciertas características que garanticen que se implique en nuestra investigación. Ahora bien, como doctorandos tenemos la obligación de tratar de aprovechar su experiencia y eso pasa por discutir y hablar todos los aspectos de nuestra investigación en curso. Y, desde luego, si en algo no estamos de acuerdo, no simplemente aceptarlo, explicar motivos y discutir. De esas discusiones van a surgir nuevas ideas, del silencio y la servidumbre, no.
3. No querer escribir. Es bastante común en Computer Science, que nos encante la parte más técnica, pero que odiemos las tareas de escritura. Sin embargo, como científicos, vamos a tener que escribir para comunicar nuestros resultado. De hecho, si en nuestra carrera conseguimos un puesto de faculty con un grupo, vamos a tener que escribir aún más: apuntes para clase, research grants, informes varios, etc.. Por esta razón, es importante que, desde el principio vayamos cogiendo soltura en la escritura y, quien sabe, hasta nos comience a gustar (o al menos no la odiemos). Suelo dar el consejo de que leer muchos artículos científico de nivel, pensando como un revisor porque así podemos ver aciertos y errores en la escritura que hacen que nos guste o no el artículo y, así, sepamos valorar una escritura clara y ordenada.
4. No llevar registro de lo que se está haciendo. Cuando estamos realizando una contribución de primer nivel, es normal realizar una gran cantidad de pasos y selecciones que luego en nuestro artículo científico tienen que estar justificados. Como, en ocasiones nos llevará mas de 8 meses de esfuerzo, es muy normal, que lo que nos parecía tan obvio hace 3 meses, ya no recordemos por qué lo hicimos. Por eso, hay que llevar registro de todo lo que se hace y la razón por la que se hace. Pese a todo, es probable que, aún llevando registro, alguna cosa se nos pase y tengamos que volver atrás.

Existen más errores que podemos cometer, pero éstos son los que nos llevarán al fracaso absoluto. En la siguiente entrega hablaremos de cómo escribir una contribución y de su estructura.

The post Investigación en seguridad (V) – 4 errores, 1 fracaso appeared first on S3lab.