NO
Deberíamos tener mejores políticas y procedimientos de verificación de errores de software, y sobre todo pruebas de control de calidad que prueben “lo inesperado”.
Si eres diligente y solo aceptas lo que crees que deberías recibir, se pueden evitar casi todos los exploits. Esto implica examinar a mano lo que parece un volumen de código increíblemente grande, desde el código integrado en los dispositivos de interfaz a través de la pila de protocolos y el núcleo hasta la aplicación, pero se puede hacer. Se ha hecho.
Es doloroso hacerlo repetidamente.
El proyecto OpenBSD hizo grandes avances en los aspectos de “plataforma” de eso, las personalidades de algunos involucrados lo convierten en una elección impopular. Aún así, es una mejora gigante sobre cualquier otra cosa en este momento.
La clave en seguridad es minimizar el área de superficie de ataque. No ejecute código que no necesita ejecutar. No ejecute código que tenga características que no necesita absolutamente. No confíes en nada que nunca haya sido examinado por completo. Resista el impulso de agregar “una cosa más”.
C es el lenguaje de facto del núcleo de “Internet” por una muy buena razón: nada funciona mejor. Está tan cerca de escribir en metal desnudo como puede obtener y aún así mantener una capa de abstracción razonable. Personalmente prefiero estar un poco más cerca del metal desnudo (BCPL, que lamentablemente está casi extinto), pero todavía he escrito literalmente cientos de miles de líneas de C, casi todas en modo kernel o en metal sin procesar como sistemas integrados.
También he escrito grandes volúmenes de código en docenas de lenguajes de alto nivel: Smalltalk, Lisp, ADA, PL / I, COBOL, casi cualquier cosa que pueda nombrar. Puedo imaginar formas en que podría ser posible escribir sistemas de control en tiempo real en algunos de ellos, pero que no se ejecuten en los niveles de rendimiento requeridos.
C simplemente gana WINS para este tipo de cosas. Si el rendimiento es tu juego, es la única opción lógica.
Dicho esto, necesitamos herramientas mucho mejores para que sea posible asegurarnos de que el código está haciendo lo que está destinado a hacer, no hace cosas que no están destinadas y rechaza cualquier entrada inesperada. Pero por muy valioso que sea, no hay un mercado comercial para eso, por lo que no sucede.
Y debido a que un QA realmente bueno cuesta dinero y toma casi tanto tiempo como escribir el código en primer lugar, eso también se acorta.
Así que tenemos un código malo ejecutando aplicaciones críticas.
Eso no es culpa de C, es culpa del modelo económico. Y cambiar a cualquier lenguaje de programación que tengas en mente NO va a cambiar eso.
