CWE-78

El producto construye la totalidad o parte de un comando del sistema operativo utilizando entradas influenciadas externamente provenientes de un componente ascendente, pero no neutraliza o neutraliza incorrectamente elementos especiales que podrían modificar el comando del sistema operativo previsto cuando se envía a un componente descendente.

Esta debilidad puede conducir a una vulnerabilidad en entornos en los que el atacante no tiene acceso directo al sistema operativo, como en las aplicaciones web. Alternativamente, si la debilidad ocurre en un programa privilegiado, podría permitir al atacante especificar comandos que normalmente no serían accesibles, o invocar comandos alternativos con privilegios que el atacante no tiene. El problema se agrava si el proceso comprometido no sigue el principio de mínimo privilegio, porque los comandos controlados por el atacante pueden ejecutarse con privilegios especiales del sistema que aumentan la magnitud del daño. Existen al menos dos subtipos de inyección de comandos del sistema operativo: - La aplicación pretende ejecutar un único programa fijo que está bajo su propio control. Pretende usar entradas suministradas externamente como argumentos para ese programa. Por ejemplo, el programa podría usar system("nslookup [HOSTNAME]") para ejecutar nslookup y permitir que el usuario proporcione un HOSTNAME, que se usa como argumento. Los atacantes no pueden impedir que nslookup se ejecute. Sin embargo, si el programa no elimina los separadores de comandos del argumento HOSTNAME, los atacantes podrían colocar los separadores dentro de los argumentos, lo que les permite ejecutar su propio programa una vez que nslookup ha terminado de ejecutarse. - La aplicación acepta una entrada que utiliza para seleccionar por completo qué programa ejecutar, así como qué comandos usar. La aplicación simplemente redirige todo este comando al sistema operativo. Por ejemplo, el programa podría usar "exec([COMMAND])" para ejecutar el [COMMAND] suministrado por el usuario. Si el COMMAND está bajo el control del atacante, entonces el atacante puede ejecutar comandos o programas arbitrarios. Si el comando se ejecuta mediante funciones como exec() y CreateProcess(), es posible que el atacante no pueda combinar varios comandos en la misma línea. Desde el punto de vista de la debilidad, estas variantes representan errores distintos del programador. En la primera variante, el programador pretende claramente que la entrada de partes no confiables forme parte de los argumentos del comando que se ejecutará. En la segunda variante, el programador no pretende que el comando sea accesible para ninguna parte no confiable, pero probablemente no ha considerado formas alternativas en las que atacantes maliciosos pueden proporcionar entradas.

Consecuencias comunes

• Confidencialidad, Integridad, Disponibilidad, No repudio → Ejecución de código o comandos no autorizados, DoS: bloqueo, salida o reinicio, Lectura de archivos o directorios, Modificación de archivos o directorios, Lectura de datos de la aplicación, Modificación de datos de la aplicación, Ocultamiento de actividades

Mitigaciones

• Arquitectura y diseño: Si es posible, utilice llamadas a bibliotecas en lugar de procesos externos para recrear la funcionalidad deseada.
• Arquitectura y diseño, Operación: Ejecute el código en una "jaula" o entorno de espacio aislado (sandbox) similar que imponga límites estrictos entre el proceso y el sistema operativo. Esto puede restringir eficazmente a qué archivos se puede acceder en un directorio determinado o qué comandos puede ejecutar el software. Los ejemplos a nivel de sistema operativo incluyen la jaula chroot de Unix, A
• Arquitectura y diseño: Para cualquier dato que se utilice para generar un comando que se ejecutará, mantenga la mayor parte posible de esos datos fuera del control externo. Por ejemplo, en las aplicaciones web, esto puede requerir almacenar los datos localmente en el estado de la sesión en lugar de enviarlos al cliente en un campo de formulario oculto.
• Arquitectura y diseño: Para cualquier verificación de seguridad que se realice en el lado del cliente, asegúrese de que estas verificaciones se dupliquen en el lado del servidor, a fin de evitar CWE-602. Los atacantes pueden eludir las verificaciones del lado del cliente modificando los valores después de que se hayan realizado las verificaciones, o cambiando el cliente para eliminar por completo
• Arquitectura y diseño: Utilice una biblioteca o marco de trabajo verificado que no permita que esta debilidad ocurra o que proporcione construcciones que faciliten evitarla. Por ejemplo, considere usar el control de codificación de ESAPI [REF-45] o una herramienta, biblioteca o marco similar. Estos ayudarán al programador a codificar las salidas de una manera menos propensa a errores.
• Implementación: Si bien es arriesgado usar cadenas de consulta, código o comandos generados dinámicamente que mezclan control y datos, a veces puede ser inevitable. Entrecomille adecuadamente los argumentos y escape cualquier carácter especial dentro de esos argumentos. El enfoque más conservador es escapar o filtrar todos los caracteres que no pasen una lista de permitidos extremadamente estricta