{"id":28167,"date":"2022-12-11T13:55:12","date_gmt":"2022-12-11T11:55:12","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=28167"},"modified":"2022-12-11T13:55:12","modified_gmt":"2022-12-11T11:55:12","slug":"the-long-road-to-memory-safety","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/the-long-road-to-memory-safety\/28167\/","title":{"rendered":"El largo camino hacia la gesti\u00f3n segura de la RAM"},"content":{"rendered":"

En noviembre del 2022, la Agencia de Seguridad Nacional de EE. UU. emiti\u00f3 un informe<\/a> sobre la seguridad en la gesti\u00f3n de la memoria RAM. Si te fijas en 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 otros problemas organizativos, por lo que dirigirse directamente a los desarrolladores de software es un movimiento bastante inusual para la agencia. Esto podr\u00eda dar a pensar que se trata de algo particularmente importante. B\u00e1sicamente, la NSA est\u00e1 instando a los desarrolladores de software a cambiar a lenguajes de programaci\u00f3n cuya arquitectura implique una mayor seguridad a la hora de trabajar con la memoria; y dejar de usar C y C++. De lo contrario, se recomienda implementar un conjunto de medidas para probar el software en busca de vulnerabilidades y evitar su explotaci\u00f3n.<\/p>\n

Para los programadores, esto es algo bastante obvio, por lo que la llamada de la NSA no est\u00e1 dirigida directamente a ellos, sino a la gerencia o representantes comerciales. De hecho, la redacci\u00f3n est\u00e1 claramente centrada en las empresas. A continuaci\u00f3n, trataremos de 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 del 2022 y echemos un vistazo a las vulnerabilidades m\u00e1s utilizadas en los ciberataques.<\/p>\n

En primera l\u00ednea, 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, da como resultado la apertura de un documento malicioso de Microsoft Word que podr\u00eda llevar al lanzamiento de c\u00f3digo arbitrario.<\/p>\n

Otra vulnerabilidad popular entre los delincuentes es la CVE-2022-2294<\/a> en el componente WebRTC del navegador Google Chrome que conduce a la ejecuci\u00f3n de c\u00f3digo arbitrario como resultado de un error de desbordamiento de b\u00fafer<\/a>.<\/p>\n

Otra vulnerabilidad, la CVE-2022-2624<\/a>, ubicada en la herramienta de visualizaci\u00f3n de PDF de Chrome, tambi\u00e9n puede provocar un desbordamiento de b\u00fafer.<\/p>\n

Por supuesto, no todas las vulnerabilidades de software se producen por causa de 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 los errores en la gesti\u00f3n de la memoria causan el 70 % de las vulnerabilidades descubiertas.<\/p>\n

\"Seg\u00fan

Seg\u00fan 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 forma y dejar de escribir c\u00f3digo vulnerable?<\/p>\n

La ra\u00edz del problema es el uso de los lenguajes de programaci\u00f3n C y C++.<\/strong> Su arquitectura brinda a los desarrolladores mucha libertad para trabajar con la RAM. Pero junto con la libertad viene la responsabilidad.<\/p>\n

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. La cuesti\u00f3n es que al compilar el c\u00f3digo fuente del programa, los medios de gesti\u00f3n segura de la memoria se introducen autom\u00e1ticamente, y los desarrolladores no necesitan dedicar su tiempo a eso. Rust utiliza a\u00fan m\u00e1s medios para mejorar la seguridad, hasta restringir la compilaci\u00f3n de c\u00f3digo potencialmente peligroso mientras muestra el error al programador.<\/p>\n

Por supuesto, dejar de usar C\/C++ no es factible mientras estos lenguajes sigan siendo indispensables para ciertas 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.<\/p>\n

En igualdad de condiciones, 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 con mayor frecuencia al software de usuarios dom\u00e9sticos (como navegadores y editores de texto), que se ejecutan en ordenadores muy potentes (en comparaci\u00f3n con los MCU, por supuesto).<\/p>\n

No se puede cambiar el lenguaje de programaci\u00f3n sin m\u00e1s<\/h2>\n

Y la NSA lo sabe. Una enorme base de datos de software escrita en lenguajes de programaci\u00f3n \u201cinseguros\u201d no se puede trasladar a otro lenguaje 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

Como ejemplo, imag\u00ednate que te piden que te mudes de tu casa solo porque fue construida hace mucho tiempo. Sabes que la estructura est\u00e1 perfectamente y que solo se derrumbar\u00eda a causa de un gran terremoto y, adem\u00e1s, 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. Podr\u00eda ser posible en el 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 fundamentalmente la seguridad del c\u00f3digo C\/C++. Estos lenguajes de programaci\u00f3n simplemente no fueron dise\u00f1ados para resolver todos los problemas de compilaci\u00f3n de golpe. Por ello, el informe de la NSA menciona dos conjuntos de medidas como alternativa:<\/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 est\u00e9 all\u00ed.<\/li>\n<\/ul>\n

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

    Los expertos coinciden en general con la opini\u00f3n de la NSA, pero pueden tener diferentes opiniones sobre c\u00f3mo podemos cambiar exactamente a lenguajes de programaci\u00f3n de alto nivel en los casos en que la necesidad surja, entre otras cosas, de los requisitos de seguridad.<\/p>\n

    En primer lugar, es importante comprender que, si se produce tal movimiento, llevar\u00e1 muchos a\u00f1os. En segundo lugar, una evoluci\u00f3n como esta tiene un precio, uno 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. Se necesita una soluci\u00f3n radical, pero no esperes que todos comiencen ma\u00f1ana mismo 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 pasarse al vegetarianismo o cualquier otro cambio extremo de la noche a la ma\u00f1ana.<\/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.<\/p>\n

    En las varias d\u00e9cadas de existencia de la industria TI, nunca ha sido posible crear un sistema universal y completamente seguro para todas las tareas (excepto soluciones altamente 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 existente. Para cualquier otro negocio, puede ser invertir en nuevas tecnolog\u00edas para protegerse contra los ciberataques, as\u00ed como probar constantemente la solidez de la infraestructura existente. En otras palabras, una estrategia integral de la seguridad es lo m\u00e1s \u00f3ptimo y seguir\u00e1 si\u00e9ndolo durante mucho tiempo.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

    Investigamos la conexi\u00f3n entre la seguridad del software y las filtraciones a la hora de gestionar la RAM.<\/p>\n","protected":false},"author":665,"featured_media":28169,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754],"tags":[3510,784],"class_list":{"0":"post-28167","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-ram","10":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/the-long-road-to-memory-safety\/28167\/"},{"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-mx","url":"https:\/\/latam.kaspersky.com\/blog\/the-long-road-to-memory-safety\/25609\/"},{"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:\/\/www.kaspersky.es\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28167","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=28167"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28167\/revisions"}],"predecessor-version":[{"id":28171,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/28167\/revisions\/28171"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/28169"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=28167"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=28167"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=28167"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}