Temas para SecureCoding curso en C

Recomendaría consultar el contenido de " El arte de la evaluación de seguridad del software " aka TAOSSA . Tiene todo en su lugar, nada para reinventar.

También, veo que en tu lista falta una cosa importante: tratar con punteros. Supongo que para ese artículo debería haber un tema separado. Ese es un PITA real y se debe prestar atención a este problema desde el principio.

Luego, puede echar un vistazo aquí: enlace para mostrar "peores prácticas".

Finalmente, hoy es muy importante llamar la atención hacia el software x64. La buena lectura se puede encontrar aquí: enlace

Sé que esto está fuera de los detalles de C, pero creo que es apropiado para enseñar a cualquier desarrollador:

• Validación de entrada y codificación de salida

Haz que esa idea se hunda en ellos. Ya sea que termines o no haciendo algo con la inyección de SQL, ¡todavía vale la pena enseñar la mentalidad de "no confíes en nada fuera de tu control"!

Actualizar : tener una revisión rápida de la cordura al revisar mis notas de revisión de código también me da:

• Error al liberar recursos que conducen a DoS o estados de bloqueo

Sé que esta respuesta será impopular, pero le diría a la gente que deje de programar en C o en cualquier código no administrado. Las optimizaciones de JIT en marcos de código administrados se optimizan mejor (que es algo que no debería preocuparte en primer lugar como desarrollador) en 2011.

En el caso de Brownfield, las tiendas de artículos antiguos, deben utilizar un compilador diferente, como el de seguridad construido en un idioma vecino. Será más fácil hacer esto que escribir especificaciones formales en Z para traducirlas a Hoare Logics, aunque Klocwork Insight (como se explica en Hacking Exposed Linux, tercera edición) puede ayudar con este proyecto potencialmente de 70 años que acaba de crear usted mismo.

Sería bueno saber qué tipo de software es, y qué infraestructura y gestión de riesgos se aplica comúnmente a su alrededor. El proyecto SATE sería un buen lugar para darse cuenta de que las herramientas de análisis estático centradas en la seguridad y el fuzzing no serán útiles por sí solos. Si desea una garantía de software, debe cambiar el idioma o utilizar métodos formales. Esas son las opciones.

A riesgo de no responder la pregunta, sin duda quisiera señalarle los Principios del desarrollo seguro de David Rook (también conocido como @securityninja) en securityninja.co.uk .

Aunque no te ayudará con los detalles de un idioma en particular, personalmente encuentro su enfoque en el punto. Utiliza la analogía de aprender a conducir un automóvil. En lugar de enseñarle a la gente a chocar un auto de diferentes maneras (piense en las hazañas), les enseñamos cómo realizar maniobras básicas, etc. (piense en la codificación de entrada / salida como dijo @RoryAlsop), lo que debería significar que evitan las colisiones.

Como dije, no es exactamente una respuesta a tu pregunta específica, pero espero que sea un recurso valioso para ti y para aquellos en una posición similar.

Lo que mencionaste es ciertamente muy importante y debería estar cubierto.

Si estuviera enseñando en clase, primero presentaría a los estudiantes a Aplastando la pila por diversión y beneficio y cómo El desbordamiento de búfer basado en la pila se puede usar para corromper el marco de la pila para la función en la que se encuentra y controlar la dirección de retorno. Obtendría una vieja máquina XP SP1 y OllyDBG y pasaría el proceso de explotación para que la viera toda la clase. (O si usa un ejemplo de aleph, puede usar un moderno Linux disto con los sistemas de protección de memoria desactivados)

Entonces deberías cubrir sistemas defensivos modernos como: ASLR, Canaries y NX Zones. Si observa las vulnerabilidades modernas que pueden funcionar en este entorno, no verá desbordamientos de búfer basados en la pila. Verás punteros colgantes . Un gran ejemplo es el Pwn2Own para 2010 contra IE8 + Windows7 .

También creo que es necesario cubrir cómo estos problemas se encuentran en el mundo real. Como fuzzing frameworks como peach (¡Gran tarea asignada!). También cubre herramientas de análisis de código como RATS (código abierto) y Coverity ($$$). Valgrind también es interesante, especialmente si te gustan los punteros colgando.

También Blog de Metasploit es realmente bueno. Me gustan las publicaciones de análisis de exploits.

No mencionas buenos hábitos de programación en general. Diseñe por contrato, sea explícito acerca de la administración de la memoria de sus funciones, luche por interfaces limpias: la disciplina involucrada aquí puede ir más allá pero hace que sea mucho más fácil detectar problemas potenciales.     

En sistemas similares a UNIX, una desreferencia NULA se puede explotar en un contexto de núcleo, por lo que es bastante importante enfatizar la verificación religiosa de las funciones de asignación de memoria.

En la zona de usuario solo puede provocar bloqueos (a menos que alguien atrape SIGSEGV y el manejador de señales sea vulnerable, pero no estoy al tanto de ningún caso en el que interceptar SIGSEGV sea una tarea inteligente).     

El conocimiento de seguridad más útil no es específico del lenguaje o la plataforma, por lo que es mejor tratar de enseñar los principios generales de 'codificación segura' y mostrar ejemplos en 'C', en lugar de enseñar 'codificación segura en' C ' '.

Por ejemplo, entender el principio de 'negar por defecto' es una idea clave que funciona en una gran variedad de contextos, idiomas y plataformas, y cubre clases de vulnerabilidades completas. Denegar de forma predeterminada conduce a la validación de entrada, que a su vez es una defensa contra el desbordamiento del búfer, los ataques de cadenas de formato y muchos otros.