{"id":29880,"date":"2019-10-31T21:32:27","date_gmt":"2019-10-31T18:32:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux\/"},"modified":"2019-10-31T21:32:27","modified_gmt":"2019-10-31T18:32:27","slug":"milliony-binarnikov-spustya-kak-ukreplyalsya-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/milliony-binarnikov-spustya-kak-ukreplyalsya-linux","title":{"rendered":"Millones de binarios despu\u00e9s. C\u00f3mo se fortaleci\u00f3 Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"MillonesTL;DR<\/b>. En este art\u00edculo, exploramos los esquemas de endurecimiento (hardening schemes) que funcionan de f\u00e1brica en cinco distribuciones populares de Linux. Para cada una, tomamos la configuraci\u00f3n predeterminada del n\u00facleo, cargamos todos los paquetes y analizamos los esquemas de protecci\u00f3n en los binarios anidados. Se consideran las distribuciones OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 y 7, as\u00ed como Ubuntu 14.04, 12.04 y 18.04 LTS. <\/p>\n

Los resultados confirman que incluso los esquemas b\u00e1sicos, como las canarias en la pila y el c\u00f3digo independiente de la posici\u00f3n, a\u00fan no son utilizados por todos. La situaci\u00f3n es a\u00fan peor para los compiladores cuando se trata de protegerse contra vulnerabilidades como el choque de pila (stack clash), que llegaron al centro de atenci\u00f3n en enero tras la publicaci\u00f3n de informaci\u00f3n sobre vulnerabilidades en systemd<\/a><\/noindex>. Pero no todo est\u00e1 perdido. En una parte significativa de los binarios se implementan m\u00e9todos b\u00e1sicos de protecci\u00f3n, y su n\u00famero aumenta de versi\u00f3n en versi\u00f3n. <\/p>\n

La verificaci\u00f3n mostr\u00f3 que la mayor cantidad de m\u00e9todos de protecci\u00f3n se implement\u00f3 en Ubuntu 18.04 a nivel de sistema operativo y aplicaciones, seguido de Debian 9. Por otro lado, OpenSUSE 12.4, CentOS 7 y RHEL 7 tambi\u00e9n implementaron esquemas b\u00e1sicos de protecci\u00f3n, y la protecci\u00f3n contra el choque de pila se aplica de manera a\u00fan m\u00e1s extensa con un conjunto de paquetes predeterminados mucho m\u00e1s denso.
\n<\/a><\/noindex><\/p>\n

Introducci\u00f3n<\/h1>\n

\nEs dif\u00edcil asegurar la alta calidad del software. A pesar de la gran cantidad de herramientas avanzadas para el an\u00e1lisis est\u00e1tico del c\u00f3digo y el an\u00e1lisis din\u00e1mico en tiempo de ejecuci\u00f3n, as\u00ed como del significativo progreso en el desarrollo de compiladores y lenguajes de programaci\u00f3n, el software moderno sigue sufriendo de vulnerabilidades que son constantemente explotadas por delincuentes. La situaci\u00f3n es a\u00fan peor en los ecosistemas que incluyen c\u00f3digo obsoleto. En tales casos, no solo enfrentamos el eterno problema de encontrar posibles errores explotables, sino que tambi\u00e9n estamos limitados por estrictos marcos de compatibilidad hacia atr\u00e1s que a menudo requieren conservar c\u00f3digo limitado, y a\u00fan peor, vulnerable o defectuoso.<\/p>\n

Aqu\u00ed es donde entran en juego los m\u00e9todos de protecci\u00f3n o endurecimiento de programas (hardening). Algunos tipos de errores no podemos prevenir, pero podemos dificultar la vida de los delincuentes y resolver parcialmente el problema, previniendo o interrumpiendo. la operaci\u00f3n<\/i> estos errores. Esta protecci\u00f3n se utiliza en todos los sistemas operativos modernos, aunque los m\u00e9todos difieren en gran medida en complejidad, eficacia y rendimiento: desde canarias de pila (stack canaries) y ASLR<\/a><\/noindex> hasta protecciones completas CFI<\/a><\/noindex> y ROP<\/a><\/noindex>. En este art\u00edculo, examinaremos qu\u00e9 m\u00e9todos de protecci\u00f3n se aplican en las distribuciones de Linux m\u00e1s populares en su configuraci\u00f3n predeterminada, as\u00ed como tambi\u00e9n estudiaremos las propiedades de los binarios que se distribuyen a trav\u00e9s de los sistemas de gesti\u00f3n de paquetes de cada distribuci\u00f3n.<\/p>\n

CVE y seguridad<\/h3>\n

\nTodos hemos visto art\u00edculos con t\u00edtulos como \u00abLas aplicaciones m\u00e1s vulnerables del a\u00f1o\u00bb o \u00abLos sistemas operativos m\u00e1s vulnerables\u00bb. Normalmente, ah\u00ed se presenta estad\u00edsticas sobre el n\u00famero total de registros de vulnerabilidades del tipo CVE (Common Vulnerability and Exposures)<\/a><\/noindex>, obtenidas de la Base Nacional de Vulnerabilidades (NVD)<\/a><\/noindex> desde NIST<\/a><\/noindex> y otras fuentes. Posteriormente, estas aplicaciones o sistemas operativos se clasifican seg\u00fan la cantidad de CVE. Desafortunadamente, aunque los CVE son muy \u00fatiles para rastrear problemas e informar a proveedores y usuarios, dicen poco sobre la verdadera seguridad del software.<\/p>\n

Por ejemplo, consideremos el n\u00famero total de CVE en los \u00faltimos cuatro a\u00f1os para el n\u00facleo de Linux y cinco de las distribuciones de servidor m\u00e1s populares, a saber, Ubuntu, Debian, Red Hat Enterprise Linux y OpenSUSE.<\/p>\n

\"Millones
\nFig. 1<\/i><\/p>\n

\u00bfQu\u00e9 nos dice este gr\u00e1fico? \u00bfSignifica que una mayor cantidad de CVE indica que una distribuci\u00f3n es m\u00e1s vulnerable que otra? La respuesta es no. Por ejemplo, en este art\u00edculo ver\u00e1s que Debian implementa mecanismos de protecci\u00f3n m\u00e1s estrictos en comparaci\u00f3n con, digamos, OpenSUSE o RedHat Linux, y aun as\u00ed, Debian tiene m\u00e1s CVE. Sin embargo, esto no necesariamente significa que la seguridad est\u00e9 debilitada: incluso la presencia de CVE no indica si la vulnerabilidad es explotable<\/i>. Los puntajes de gravedad dan una idea de cu\u00e1n probable<\/i> es la explotaci\u00f3n de la vulnerabilidad, pero en \u00faltima instancia, la explotabilidad depende en gran medida de la protecci\u00f3n presente en los sistemas afectados, as\u00ed como de los recursos y capacidades de los atacantes. Adem\u00e1s, la ausencia de informes de CVE no dice nada sobre otras vulnerabilidades no registradas o desconocidas<\/i> Las vulnerabilidades. La diferencia en CVE puede explicarse no por la calidad del software, sino por otros factores, incluidos los recursos asignados a las pruebas o el tama\u00f1o de la base de usuarios. En nuestro ejemplo, un mayor n\u00famero de CVE en Debian puede simplemente indicar que Debian ofrece m\u00e1s paquetes de software. <\/p>\n

Por supuesto, el sistema CVE proporciona informaci\u00f3n \u00fatil que permite crear defensas adecuadas. Cuanto mejor comprendamos las causas del fallo de un programa, m\u00e1s f\u00e1cil ser\u00e1 identificar posibles m\u00e9todos de explotaci\u00f3n y desarrollar mecanismos correspondientes. de detecci\u00f3n y respuesta.<\/i>En la Fig. 2 se muestran las categor\u00edas de vulnerabilidades para todas las distribuciones en los \u00faltimos cuatro a\u00f1os (fuente<\/a><\/noindex>). Es evidente que la mayor\u00eda de los CVE caen en las siguientes categor\u00edas: denegaci\u00f3n de servicio (DoS), ejecuci\u00f3n de c\u00f3digo, desbordamiento, corrupci\u00f3n de memoria, fuga (exfiltraci\u00f3n) de informaci\u00f3n y escalamiento de privilegios. Aunque muchos CVE se registran varias veces en diferentes categor\u00edas, en general, los mismos problemas persisten a\u00f1o tras a\u00f1o. En la siguiente parte del art\u00edculo, evaluaremos el uso de varios esquemas de defensa para prevenir la explotaci\u00f3n de estas vulnerabilidades.<\/p>\n

\"Millones
\nFig. 2<\/i><\/p>\n

Tareas<\/h3>\n

\nEn este art\u00edculo, tenemos la intenci\u00f3n de responder las siguientes preguntas:<\/p>\n