Microsoft planea Rust como una alternativa segura a C y C

Desde 2004, el Centro de Respuesta de Seguridad de Microsoft (MSRC) ha clasificado todas las vulnerabilidades de seguridad de Microsoft reportadas. Según los datos proporcionados por ellos, de todos los parches lanzados por Microsoft cada año, alrededor de 70 son correcciones para vulnerabilidades de seguridad de la memoria.

La proporción es tan alta porque Windows y la mayoría de los demás productos de Microsoft están escritos principalmente en C y C, dos lenguajes de programación "inseguros para la memoria" que permiten a los desarrolladores tener un control preciso sobre las direcciones de memoria y ejecutar el código. Las vulnerabilidades en el código del desarrollador que administra la ejecución de la memoria pueden generar una variedad de errores que no son seguros para la memoria y que los atacantes pueden explotar con consecuencias peligrosamente intrusivas, como la ejecución remota de código o vulnerabilidades de escalada de privilegios.

Por lo tanto, está en la agenda explorar el uso de lenguajes seguros para la memoria como Rust como método alternativo para crear aplicaciones de Microsoft más seguras.

Rust comenzó como un proyecto de investigación en Mozilla para reescribir el navegador Firefox y hacerlo más seguro y rápido. El navegador Brave también reemplazó recientemente su componente de bloqueo de anuncios, escrito originalmente en C, con una versión en Rust, que fue nombrado el "lenguaje de programación favorito de los desarrolladores" por cuarto año consecutivo en la Encuesta de desarrolladores StackOverflow de 2019. A los desarrolladores les encanta Rust porque su sintaxis es más simple y las aplicaciones escritas en Rust tienen menos errores, por lo que los desarrolladores pueden concentrarse en escalar la aplicación en lugar del mantenimiento continuo.

Gavin Thomas, director principal de ingeniería de seguridad de MSRC, sugirió que los desarrolladores externos también deberían buscar lenguajes seguros para la memoria, citando razones que incluyen que los desarrolladores necesitan dedicar tiempo y esfuerzo a aprender a depurar aplicaciones C. Vulnerabilidades de seguridad relacionadas con la memoria en programas. Pero esto es obviamente inapropiado. "El trabajo principal de un desarrollador no es preocuparse por los problemas de seguridad, sino desarrollar funciones". Thomas preguntó: "¿Por qué no introducir la seguridad de la memoria en el lenguaje de desarrollo desde el principio?"

Con este fin, instó: "Si la industria realmente se preocupa por la seguridad, debería centrarse en las herramientas de desarrollo en lugar de confundirse con todos los equipos de seguridad y métodos obsoletos. Debemos trabajar para evitar que los desarrolladores caigan en vulnerabilidades en las primeras lugar, en lugar de proporcionar orientación y herramientas para resolver vulnerabilidades

Publicación original del blog de MSRC: /2019/07/16/a-proactive-approach-to-more-secure-code/