¿C es ya una buena opción para el software relacionado con la seguridad? [cerrado]

La razón principal y casi única por la cual la mayoría del software en el ecosistema de Linux está escrito en C es Tradición . Los desarrolladores ven software escrito en C, bibliotecas con una API basada en C, y por lo tanto usan C, porque eso es conveniente. Los compiladores ya están allí y funcionan bien porque todo el sistema operativo está escrito en C.

Nada de esto dice que C es bueno para desarrollar software robusto. De hecho, C es bastante terrible en eso. Con C, el desarrollador debe tener cuidado con muchas cosas en todo momento. C tiene muchas trampas listas para ser lanzadas en los errores más pequeños, incluyendo:

• Acceso a matrices no seleccionados, lo que permite desbordamientos.
• Administración de memoria manual, lo que lleva a errores de uso después de doble liberación o sin uso, y pérdidas de memoria.
• El temido "comportamiento indefinido" que hace que las expresiones aparentemente razonables se vuelvan locas (en particular, las operaciones firmadas que exceden el rango representable).
• Problemas de portabilidad al ir a arquitecturas con diferentes longitudes para tipos enteros y punteros.

En qué C es realmente bueno es lo siguiente:

• Interactuando con un conjunto existente de bibliotecas que ofrecen una API de C. C es la lingua franca que permite la interoperabilidad entre los componentes de software en muchas plataformas.

Lo que C es pasable es:

• Escribir código de muy bajo nivel (por ejemplo, código criptográfico resistente a ataques de tiempo a través de patrones de acceso a memoria fijos) al intentar mantener cierto nivel de portabilidad.

Mi conclusión es que C no es una buena idea para escribir software relacionado con la seguridad en general , y no lo ha sido desde hace bastante tiempo (al menos una década). C todavía está justificado en algunos contextos específicos, en particular si se dirige a plataformas integradas (no incrustadas como en "teléfono inteligente", sino incrustadas como en "tarjeta inteligente"). En lugar de buscar razones para alejarse de C, sería más justificado buscar razones específicas para seguir usando C.

Usted puede escribir código seguro en C. Es solo que el idioma es inseguro por defecto . La seguridad debe incluirse manualmente con un código adicional (que, por supuesto, puede contener errores).

Por esa razón, C nunca fue nunca realmente la mejor opción para el software crítico para la seguridad. Se usó de todos modos en FOSS porque los compiladores gratuitos para él han estado históricamente disponibles en casi todas las plataformas (por definición, para cada plataforma compatible con gcc).

El consejo general para el software crítico para la seguridad, si no está atado a un idioma específico (como C) es usar Ada. Ese lenguaje se encuentra en un nivel de abstracción similar al de C o C ++, pero los valores predeterminados son de seguridad (por ejemplo: verificación automática de límites para todas las matrices) con la capacidad de agregar código para desactivar las comprobaciones , en lugar de las otras reves.

En particular, hay un subconjunto de Ada llamado SPARK que está diseñado específicamente para la seguridad y crítico software. También se puede usar para la verificación formal del software, si te gusta ese tipo de cosas.

En primer lugar, para cosas como el cifrado el rendimiento importa .

Es la diferencia entre poder atender a cientos de usuarios o solo 10 a la vez. Y esto tiene cierta relevancia de seguridad: si sus servidores tienen problemas, entonces son fáciles de eliminar con un ataque de DOS.

Si alguna vez comparaste el código puro de Python con el código nativo, te sorprenderás de cuán grandes son las diferencias.

En segundo lugar, no hay Python / Java sin C . Cualquiera que sea el lenguaje "moderno" que mire, utiliza una cantidad sustancial de bibliotecas debajo. Y adivina qué, la mayoría de estas son bibliotecas de C

Ahora, si escribe una biblioteca "crítica para la seguridad" en un lenguaje de este tipo, debe preocuparse por 1. problemas en su propio código 2. problemas en el código Java / Python que usa 3. problemas en el código C subyacente son actualizaciones de seguridad frecuentes para Java!) y 4. problemas en las bibliotecas de C debajo que pueden cambiar sin que usted lo sepa (por ejemplo, actualizaciones del sistema operativo). Si desea un código de seguridad relevante, minimice las dependencias.

La cantidad de C debajo está aumentando, no disminuyendo . Esto puede parecer no obvio. Pero numpy, tensorflow, JavaFX, ... todos usan mucho código C debajo, debido al rendimiento .

Se podrían evitar muchos problemas con una ingeniería cuidadosa y la programación verbose . Por ejemplo, el error "goto fail" de OSX se debió a que los programadores no se adhirieron a la mejor práctica de usar siempre corchetes ...

if (a)
  goto fail;
  goto fail;
somethingelse

es un error fácil de pasar por alto en la mayoría de los idiomas (excepto en Python, donde necesitaría dos espacios menos para el mismo problema) que se pueden evitar simplemente con verbosidad:

if (a) {
  goto fail;
  goto fail;
}
somethingelse

No es como si Python fuera muy útil para evitar tales problemas (de hecho, los compiladores de Java le advierten sobre el código inalcanzable). Python no lo hace, y los compiladores de C pueden hacerlo si el usuario los habilita) ... Al final, la disciplina del desarrollador sigue siendo un factor clave.

El código C usualmente requiere mucho más cuidado para escribir; lo que no es malo para la calidad. El principal inconveniente es que su desarrollo es más lento.

C ha sido usado por millones de personas por más de 20 años. Sus fallas de seguridad, como la de scanf () , son bien conocidas y están documentadas, y existen soluciones provisionales probadas y altamente probadas.

Un lenguaje más nuevo, digamos que perl 6 o python 3 solo ha estado en uso por poco tiempo, poca gente es experta en ellos, pueden existir fallas de seguridad que aún no se han encontrado, y la revisión crítica y la documentación son escasas. / p>

Ambos de estos lenguajes más nuevos son mucho más 'grandes' que C con muchas más habilidades, y pueden pasar muchos más de 20 años antes de que se hayan usado todas las construcciones de programación posibles, y podemos confiar en su seguridad.

Es de bajo nivel y totalmente inseguro por defecto. Por supuesto, es posible escribir software seguro, pero hay que ser bueno en eso. OTOH: C es de bajo nivel y no es necesario que incluyas bibliotecas que puedan tener sus propios problemas de seguridad, esto podría ser bueno. Además, no se debe olvidar que un lenguaje "seguro" significa que hay programas involucrados que, de nuevo, son un posible problema de seguridad.

Personalmente I probablemente recomendaría usar Rust, ya que puede ser de un nivel suficientemente bajo y también está enfocado en la seguridad.

no usaría cualquier Código no nativo (es decir, no Java, C #, etc.) excepto si usted entrega su propio Runtime. Lo mismo se aplica a todas las bibliotecas a las que se vincula, pero esto puede evitarse en contraste con el código no nativo.

En general, deberías centrarte en el menor código posible, es decir. Hazlo tan simple como puedas y no confíes en otro código. Sin embargo, si puede evitarlo, en cambio, no confíe en usted mismo al escribir código de seguridad, por lo general no es bueno.

El motivo de la persistencia de C es no una tradición, sino una portabilidad y una API + lib muy permisiva. Sí, no piensa que a usted le gusta algo de basura de alto nivel, el lenguaje se creó con la firme convicción de que es solo una herramienta para implementar su idea. Si la idea en sí está mal diseñada / con fallas, no solo fallas de seguridad, ningún lenguaje la salvará por completo. Sí, algunos nuevos "productos" basados en programadores tontos intentarán hacer lo mejor posible para evitar el problema, pero no tendrán éxito, no con todos los problemas. Usa cerebro, estándar, depurador y valgrind - y amarás C por lo que es.