{"id":25609,"date":"2022-12-15T22:59:47","date_gmt":"2022-12-16T04:59:47","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=25609"},"modified":"2022-12-15T22:59:47","modified_gmt":"2022-12-16T04:59:47","slug":"the-long-road-to-memory-safety","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/the-long-road-to-memory-safety\/25609\/","title":{"rendered":"El largo camino hacia una gesti\u00f3n segura de la RAM"},"content":{"rendered":"

En noviembre de 2022, la Agencia de Seguridad Nacional de EE. UU. lanz\u00f3 un informe<\/a> sobre la seguridad en la gesti\u00f3n de la memoria RAM. Si miras otros informes<\/a> de la NSA sobre el tema, notar\u00e1s que se centran en el cifrado de datos o la protecci\u00f3n del ciclo de producci\u00f3n y dem\u00e1s problemas de organizaci\u00f3n, por lo que dirigirse directamente a los desarrolladores de software es un movimiento inusual para la agencia. Esto podr\u00eda dar a pensar que se trata de algo particularmente importante. B\u00e1sicamente, la NSA incita a los desarrolladores de software a cambiar a lenguajes de programaci\u00f3n cuya arquitectura implique mayor seguridad al momento de trabajar con la memoria; y dejar de usar C y C++. De no hacerlo, se recomienda implementar un conjunto de medidas para probar el software para buscar de vulnerabilidades y evitar su explotaci\u00f3n.<\/p>\n

Esto es algo bastante obvio para los programadores, por lo que la llamada de la NSA no va enfocada a ellos de forma directa, sino a la gerencia o representantes comerciales. La redacci\u00f3n, en realidad, est\u00e1 claramente centrada en las empresas. Ahora intentaremos analizar los argumentos presentados sin ser demasiado t\u00e9cnicos.<\/p>\n

La seguridad de la memoria<\/h2>\n

Abramos nuestro \u00faltimo Informe<\/a> sobre la evoluci\u00f3n de las amenazas en el tercer trimestre de 2022 y veamos las vulnerabilidades m\u00e1s usadas durante los ciberataques. En primer lugar, sigue estando la vulnerabilidad CVE-2018-0802<\/a> en el componente Editor de ecuaciones<\/em> del paquete Microsoft Office, descubierta en el 2018. Un procesamiento de datos incorrecto en la RAM, culmina en la apertura de un documento malicioso de Microsoft Word que podr\u00eda llevar al lanzamiento de c\u00f3digo arbitrario. Otra vulnerabilidad popular entre los delincuentes es la CVE-2022-2294<\/a> en el componente WebRTC del navegador Google Chrome que lleva a la ejecuci\u00f3n de c\u00f3digo arbitrario como resultado de un error de desbordamiento de b\u00fafer<\/a>. Otra vulnerabilidad, la CVE-2022-2624<\/a>, encontrada en la herramienta de visualizaci\u00f3n de PDF de Chrome, puede provocar tambi\u00e9n un desbordamiento de b\u00fafer.<\/p>\n

Claro que no todas las vulnerabilidades de software se producen debido una gesti\u00f3n insegura de la RAM, pero muchas de ellas s\u00ed. El informe de la NSA cita las estad\u00edsticas<\/a> de Microsoft de que el 70 % de las vulnerabilidades descubiertas son causadas por los errores en la gesti\u00f3n de la memoria.<\/p>\n

\"\"

De acuerdo con las estad\u00edsticas de Microsoft, dos tercios de las vulnerabilidades ocurren debido a errores en la memoria. Fuente <\/a>.<\/p><\/div>\n

\u00bfPor qu\u00e9 pasa esto? Si el problema de las filtraciones de memoria es tan grave, \u00bfpor qu\u00e9 no podemos unirnos de alguna manera para ya no escribir c\u00f3digo vulnerable? La ra\u00edz del problema es el uso de los lenguajes de programaci\u00f3n C y C++. Su arquitectura brinda a los desarrolladores mucha libertad para trabajar con la RAM. Pero la responsabilidad viene junto con la libertad. Los programadores de C\/C++ tienen que implementar mecanismos para escribir y leer datos de forma segura. A su vez, los lenguajes de programaci\u00f3n de alto nivel como C#, Rust, Go y otros se encargan de eso. El tema es que al compilar el c\u00f3digo fuente del programa, los medios de gesti\u00f3n segura de la memoria se introducen de forma autom\u00e1tica, y los desarrolladores no necesitan dedicar su tiempo a eso. Rust utiliza todav\u00eda m\u00e1s medios para mejorar la seguridad, hasta restringir la compilaci\u00f3n de c\u00f3digo potencialmente peligroso al tiempo que muestra al programador el error.<\/p>\n

Claro que dejar de usar C\/C++ no es factible mientras estos lenguajes sigan siendo indispensables para algunas tareas, como cuando se necesita c\u00f3digo para el MCU u otros dispositivos con serias limitaciones en el poder de c\u00f3mputo y el tama\u00f1o de la memoria. En condiciones equilibradas, los lenguajes de programaci\u00f3n de alto nivel pueden conducir a la creaci\u00f3n de programas que requieren m\u00e1s recursos. Pero las estad\u00edsticas de amenazas comunes nos muestran que los ataques se dirigen m\u00e1s frecuentemente al software de usuarios dom\u00e9sticos (como navegadores y editores de texto), que se ejecutan en computadoras muy potentes (en comparaci\u00f3n con los MCU, por supuesto).<\/p>\n

No se puede solo cambiar el lenguaje de programaci\u00f3n<\/h2>\n

Y la NSA lo sabe. No puede trasladarse una gran base de datos de software escrita en lenguajes de programaci\u00f3n \u201cinseguros\u201d a otro de la noche a la ma\u00f1ana. Aunque hablemos de escribir un producto de software desde cero, puede haber un equipo establecido, una infraestructura y m\u00e9todos de desarrollo en torno a un lenguaje de programaci\u00f3n en particular.<\/p>\n

Por ejemplo, imagina que te piden que te mudes de tu casa solo porque la construyeron hace mucho tiempo. Sabes que la estructura est\u00e1 perfectamente y que solo se derrumbar\u00eda si hay un gran terremoto y, adem\u00e1s, ya est\u00e1s acostumbrado a vivir all\u00ed. El equipo de desarrolladores de Google Chrome tiene una publicaci\u00f3n en la que establece expl\u00edcitamente que en este momento no pueden cambiar a otro lenguaje de programaci\u00f3n (en este caso, Rust) en el que la seguridad est\u00e9 integrada en la arquitectura. Quiz\u00e1 sea posible en un futuro, pero ahora mismo necesitan otras soluciones.<\/p>\n

Esta misma publicaci\u00f3n de los desarrolladores de Google Chrome tambi\u00e9n explica por qu\u00e9 no se puede cambiar la seguridad del c\u00f3digo C\/C++ de manera fundamental. Estos lenguajes de programaci\u00f3n simplemente no fueron dise\u00f1ados para resolver de tajo todos los problemas de compilaci\u00f3n. Por esto, el informe de la NSA menciona dos conjuntos de medidas alternativas:<\/p>\n

    \n
  • La prueba de c\u00f3digo para vulnerabilidades potenciales con t\u00e9cnicas de an\u00e1lisis din\u00e1mico y est\u00e1tico.<\/li>\n
  • Usar caracter\u00edsticas que eviten la explotaci\u00f3n de un error de c\u00f3digo, aunque ya exista.<\/li>\n<\/ul>\n

    Los desaf\u00edos del cambio<\/h2>\n

    En general, los expertos comparten la opini\u00f3n de la NSA, pero pueden tener diferentes puntos sobre c\u00f3mo cambiar a lenguajes de programaci\u00f3n de alto nivel en los casos en que la necesidad surja, entre otras cosas, de los requisitos de seguridad. Primero, es importante entender que, si llega a pasar tal movimiento, tardar\u00e1 muchos a\u00f1os. Segundo, una evoluci\u00f3n como esta tiene un precio que no todas las empresas est\u00e1n dispuestas a pagar. El problema de la gesti\u00f3n insegura de la memoria en los lenguajes de programaci\u00f3n con un bajo nivel de abstracci\u00f3n es un problema sist\u00e9mico. Es necesaria una soluci\u00f3n radical, pero no esperes que ma\u00f1ana mismo todos comiencen a desarrollar en C#, Go, Java, Ruby, Rust o Swift. Esta situaci\u00f3n presenta las mismas complicaciones que si se intentara obligar a toda una ciudad o pa\u00eds a volverse vegetarianos o cualquier otro cambio extremo de un d\u00eda para otro.<\/p>\n

    Por \u00faltimo, el problema de la gesti\u00f3n insegura de la memoria puede ser muy importante, pero est\u00e1 lejos de ser el \u00fanico problema relacionado con la seguridad del software. En las varias d\u00e9cadas de existencia de la industria TI, no ha sido posible crear un sistema universal y totalmente seguro para todas las tareas (exceptuando soluciones muy especializadas). Desde un punto de vista empresarial, tiene sentido tanto invertir en nuevas tecnolog\u00edas (desarrollando las habilidades correspondientes y contratando especialistas con experiencia) como en la m\u00e1xima protecci\u00f3n de las tecnolog\u00edas existentes. Para el desarrollo de software, podemos hablar de nuevos lenguajes de programaci\u00f3n y tecnolog\u00edas para probar el c\u00f3digo que ya existe. Para cualquier otro negocio, puede ser invertir en nuevas tecnolog\u00edas para protegerse ante ciberataques, as\u00ed como probar la solidez de la infraestructura existente de manera constante. En otras palabras, una estrategia integral de la seguridad es lo \u00f3ptimo y lo ser\u00e1 por mucho tiempo.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Investigamos la conexi\u00f3n entre la seguridad del software y las filtraciones al momento de gestionar la RAM.<\/p>\n","protected":false},"author":665,"featured_media":25610,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2795,3539,3540],"tags":[5841,647],"class_list":{"0":"post-25609","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ram","11":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/the-long-road-to-memory-safety\/25609\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/the-long-road-to-memory-safety\/24957\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/the-long-road-to-memory-safety\/20453\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/the-long-road-to-memory-safety\/27517\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/the-long-road-to-memory-safety\/25287\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/the-long-road-to-memory-safety\/28167\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/the-long-road-to-memory-safety\/34357\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/the-long-road-to-memory-safety\/46511\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/the-long-road-to-memory-safety\/19876\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/the-long-road-to-memory-safety\/20461\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/the-long-road-to-memory-safety\/29583\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/the-long-road-to-memory-safety\/25649\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/the-long-road-to-memory-safety\/31334\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/the-long-road-to-memory-safety\/31043\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/latam.kaspersky.com\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25609","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=25609"}],"version-history":[{"count":1,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25609\/revisions"}],"predecessor-version":[{"id":25612,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25609\/revisions\/25612"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/25610"}],"wp:attachment":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=25609"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=25609"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=25609"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}