A raíz de la publicación de la noticia del lanzamiento del Kernel 4.12 de Linux, el cual trae por primera vez activada por defecto la característica KASLR, y casi simultáneamente la publicación de esta otra noticia sobre la implementación de una característica llamada KARL en OpenBSD me ha parecido que sería interesante aclarar las diferencias entre estas técnicas de seguridad, pues pienso que la combinación de ambas va a ser muy importante de cara al futuro de la seguridad de los sistemas, pues van a impedir explotar vulnerabilidades relacionadas con la corrupción de memoria (buffer-overflow).
Pero antes de entrar a detallar las características de KASLR y KARL echemos un vistazo ASLR.
ASLR
El término ASLR hace referencia a Address Space Layout Randomization, que quiere decir Distribución Aleatoria del Espacio de Direcciones de memoria. Se trata de una técnica dirigida a prevenir que un atacante que sabe previamente que una función de un programa es vulnerable y puede ser explotada, pueda acceder a ella impidiéndole conocer la dirección de memoria que ocupa dicha función dentro del proceso en ejecución. Y no puede conocerla porque ASLR consiste fundamentalmente en distribuir de forma aleatoria las partes fundamentales del proceso (base del ejecutable, punteros a pila, librerías, etc.) dentro del espacio de direcciones de memoria que le ha sido asignado por parte del sistema operativo.
Error: Your Requested widget " ai_widget-6" is not in the widget list.
- [do_widget_area above-nav-left]
- [do_widget_area above-nav-right]
- [do_widget_area footer-1]
- [do_widget id="wpp-4"]
- [do_widget_area footer-2]
- [do_widget id="recent-posts-4"]
- [do_widget_area footer-3]
- [do_widget id="recent-comments-3"]
- [do_widget_area footer-4]
- [do_widget id="archives-4"]
- [do_widget_area logo-bar]
- [do_widget id="oxywidgetwpml-3"]
- [do_widget_area menu-bar]
- [do_widget id="search-3"]
- [do_widget_area sidebar]
- [do_widget id="search-4"]
- [do_widget id="ai_widget-2"]
- [do_widget id="categories-5"]
- [do_widget id="ai_widget-3"]
- [do_widget id="ai_widget-4"]
- [do_widget id="ai_widget-5"]
- [do_widget_area sub-footer-1]
- [do_widget id="text-4"]
- [do_widget_area sub-footer-2]
- [do_widget_area sub-footer-3]
- [do_widget_area sub-footer-4]
- [do_widget_area upper-footer-1]
- [do_widget id="search-2"]
- [do_widget id="recent-posts-2"]
- [do_widget id="recent-comments-2"]
- [do_widget id="archives-2"]
- [do_widget id="categories-2"]
- [do_widget id="meta-2"]
- [do_widget_area upper-footer-2]
- [do_widget_area upper-footer-3]
- [do_widget_area upper-footer-4]
- [do_widget_area widgets_for_shortcodes]
- [do_widget id="search-5"]
- [do_widget id="ai_widget-6"]
- [do_widget_area wp_inactive_widgets]
- [do_widget id="wpp-2"]
- [do_widget id="text-1"]
- [do_widget id="recent-posts-3"]
- [do_widget id="categories-3"]
- [do_widget id="archives-3"]
- [do_widget id="icl_lang_sel_widget-3"]
Así, un atacante no sabrá nunca con certeza cómo saltar a la función en cuestión y no podrá explotarla, y si trata de hacerlo mediante ensayo y error lo más probable es que lo único que consiga es bloquear el proceso provocando que éste muera, y no poder por tanto continuar con su ataque.
La técnica ASLR tiene ya bastante tiempo y fue introducida en Linux como un parche en 2001 y en el kernel en 2005, en Windows Vista y Mac OS X 10.5 (Leopard) en 2007 y, finalmente en iOS y Android en 2011.
KASLR
KASLR lo que hace es simplemente añadir la K de kernel a la técnica ASLR vista anteriormente, es decir, aleatorizar la ubicación del código del propio kernel en memoria cuando arranca el sistema. KASLR se introdujo en el kernel de Linux hace ya algún tiempo con la versión 3.14 (2014), pero es ahora en 2017 con la reciente liberación de la versión 4.12 cuando se ha activado por defecto.
Lamentablemente, su efectividad ha sido puesta en entredicho y aún hoy es objeto de debate. Esto se debe a que para poder salvar la protección que ofrece la técnica ASLR y conseguir que un ataque se materialice se requiere tener éxito en alguna de las siguientes operaciones:
- Probar mediante fuerza bruta hasta encontrar las direcciones aleatorias que persigue el atacante, lo cual requerirá volver a ejecutar el proceso de la aplicación cada vez que se cuelgue y pondrá sobre aviso al administrador del sistema.
- Obtener ciertos punteros clave que proporcionen información sobre la distribución del proceso en memoria.
La segunda opción es bastante factible en el caso de los sistemas operativos, ya que debido a algunas limitaciones de la configuración del hardware pueden tener limitado el espacio de direcciones disponible, pero sobre todo porque el kernel no puede cambiar su distribución en memoria durante todo su ciclo de funcionamiento, es decir, que hasta la próxima vez que se reinicie el sistema no se volverá a aplicar una nueva distribución aleatoria en memoria.
Error: Your Requested widget " ai_widget-6" is not in the widget list.
- [do_widget_area above-nav-left]
- [do_widget_area above-nav-right]
- [do_widget_area footer-1]
- [do_widget id="wpp-4"]
- [do_widget_area footer-2]
- [do_widget id="recent-posts-4"]
- [do_widget_area footer-3]
- [do_widget id="recent-comments-3"]
- [do_widget_area footer-4]
- [do_widget id="archives-4"]
- [do_widget_area logo-bar]
- [do_widget id="oxywidgetwpml-3"]
- [do_widget_area menu-bar]
- [do_widget id="search-3"]
- [do_widget_area sidebar]
- [do_widget id="search-4"]
- [do_widget id="ai_widget-2"]
- [do_widget id="categories-5"]
- [do_widget id="ai_widget-3"]
- [do_widget id="ai_widget-4"]
- [do_widget id="ai_widget-5"]
- [do_widget_area sub-footer-1]
- [do_widget id="text-4"]
- [do_widget_area sub-footer-2]
- [do_widget_area sub-footer-3]
- [do_widget_area sub-footer-4]
- [do_widget_area upper-footer-1]
- [do_widget id="search-2"]
- [do_widget id="recent-posts-2"]
- [do_widget id="recent-comments-2"]
- [do_widget id="archives-2"]
- [do_widget id="categories-2"]
- [do_widget id="meta-2"]
- [do_widget_area upper-footer-2]
- [do_widget_area upper-footer-3]
- [do_widget_area upper-footer-4]
- [do_widget_area widgets_for_shortcodes]
- [do_widget id="search-5"]
- [do_widget id="ai_widget-6"]
- [do_widget_area wp_inactive_widgets]
- [do_widget id="wpp-2"]
- [do_widget id="text-1"]
- [do_widget id="recent-posts-3"]
- [do_widget id="categories-3"]
- [do_widget id="archives-3"]
- [do_widget id="icl_lang_sel_widget-3"]
Por tanto, en el momento que consiga obtener un puntero a la tabla de distribución de memoria del kernel el atacante habrá conseguido saltarse esta barrera de defensa. Y eso es exactamente lo que la convierte en una técnica muy débil y el principal motivo de controversia, ya que mientras ASLR es una técnica muy interesante para la seguridad de las aplicaciones, muchos autores afirman que no es adecuada aplicarla a nivel de kernel.
KARL
Y es entonces cuando la implementación de KARL (Kernel Address Randomized Link) que se ha realizado recientemente en OpenBSD surge como una solución prometedora a los problemas anteriores, aunque hay que tener en cuenta que son de naturaleza distinta, ya que KARL no se fundamente en una distribución aleatoria en memoria (ASLR) y sigue ubicándose en las mismas direcciones fijas del KVA (Kernel Virtual Address Space).
Esta posición fija hacía que antes de KARL el kernel fuera siempre el mismo y estuviera en el mismo sitio para todos los usuarios. La novedad que introduce KARL es que los ficheros binarios del kernel se generan distribuyendo los ficheros internos del kernel en un orden aleatorio cada vez que el sistema se reinicia o se actualiza, con lo cual cada sistema funcionará cada vez que se reinicie con un kernel único totalmente distinto al de otros sistemas a nivel binario. Esto dificulta considerablemente la tarea de un atacante a la hora de explotar funciones internas del kernel, punteros y objetos.
Por tanto, la diferencia principal entre KASLR y KARL es que KARL carga un kernel diferente a nivel binario cada vez y lo ubica en el mismo sitio, mientras que KASLR carga siempre el mismo binario pero cada vez en una ubicación distinta y aleatoria de memoria. Se trata así del mismo objetivo, pero siguiendo enfoques diferentes.
Por tanto, hasta aquí no parece que KARL suponga una gran mejora respecto a las limitaciones que ya tenía KASLR, pues una vez conocida la distribución en memoria de este kernel aleatorio se podrían explotar igualmente vulnerabilidades del mismo hasta el siguiente reinicio. La verdadera novedad es que por primera vez se podrán combinar ambas técnicas de forma que aunque un atacante obtenga la dirección aleatoria de memoria donde comienza el kernel (proceso dificultado por KASLR), no podrá usarla para saber dónde se encuentran determinadas funciones ya que su ubicación también será aleatoria y diferirá de un sistema a otro.
Esperemos que pronto podamos ver una implementación de KARL en Linux y en Windows, lo cual ayudará sin duda a mejorar la seguridad de estos sistemas operativos.
Más detalles sobre la reciente implementación de KARL en OpenBSD aquí:
Deja una respuesta