¿Qué daño puede causar un programa C/asm a Linux cuando lo ejecuta un usuario sin privilegios?

Question

He estado pensando en un escenario donde uno permite a los usuarios (puede ser cualquiera, posiblemente con malas intenciones) enviar código que se ejecuta en una PC Linux (llamémoslo nodo de referencia). El objetivo es crear un tipo de entorno de evaluación automática para rutinas de subproceso único. Digamos que un sitio web publica algún código en un proxy. Este proxy transfiere este código al nodo de referencia, y el nodo de referencia solo tiene una conexión de Ethernet con el proxy, no con Internet.

Si se permite que cualquier usuario publique código C/asm para ejecutarse en el nodo de referencia, ¿qué desafíos de seguridad enfrentará? Las siguientes suposiciones se hacen:

• El programa se ejecuta como un usuario sin privilegios
• El proxy tendrá la oportunidad de matar el proceso en el nodo de referencia (tomar el escenario de un bucle infinito por ejemplo)
• el proxy es capaz de reiniciar el nodo de referencia (si responde ...)

por lo tanto, es en la práctica es posible que este programa de espacio de usuario puede hacer que el desplome del sistema operativo, o hacer que la máquina no esté disponible para el proxy ? Con el ensamblaje, el programador puede hacer básicamente lo que quiera (por ejemplo, manipular el puntero de la pila), y me pregunto qué tan restrictivo/robusto es el Linux a este respecto. También sé sobre la posibilidad de que los procesos soliciten regiones de memoria compartida con otros procesos (shm), que también podrían desempeñar un papel aquí.

Cualquier literatura o artículos sobre este tema son bienvenidos.

Las soluciones de Sandbox también pueden ser interesantes, pero es importante que la CPU debe realizar el 100% de lo que es capaz durante el benchmark (al menos en el núcleo se ejecuta el benchmark).

Answer 1

Entonces, ¿es posible en la práctica que este programa de espacio del usuario pueda hacer que el sistema operativo falle o que la máquina no esté disponible para el proxy?

Sí, técnicas tales como el desove un número excesivo de procesos, la asignación de memoria excesiva (que causa el uso archivo de intercambio), o haciendo cola un montón de disco I/O hará que la máquina no responde para que su proceso de supervisor no lo hará ejecutar de manera oportuna.

Si su código de supervisor termina intercambiándose al disco, incluso si tiene alta prioridad, no se ejecutará hasta que el disco esté disponible, lo que puede ser un retraso muy largo debido a los tiempos de búsqueda.

Linux tiene ulimit que puede proteger contra algunos de estos, consulte Limit the memory and cpu available for a user in Linux Y la actividad de red maliciosa también se puede bloquear. También puede desactivar swap y chroot el programa en un montaje tmpfs. Pero algunas travesuras aún serán posibles.

Answer 2

Sólo una lista rápida de la parte superior de mi cabeza.En esencia, si usted no confía en los usuarios al menos un poco, estás en serios problemas:

• la manipulación del sistema de archivos: borrar o sobrescribir los archivos que pertenecen al usuario el proceso se ejecuta como
• Curioseando todo tipo de datos encontrado en el sistema (archivos, a veces el tráfico de red del mismo usuario)
• matar a otros procesos del usuario
• el consumo de memoria hasta OOM Killer empieza a matar procesos aleatorios o (si tiene habilitado intercambio) hasta que la máquina se ralentiza a paso de tortuga
• Generando lotes de E/S en slo w el sistema
• La ejecución de exploits a voluntad (que está cerca de seguro de tener alguna sin parchear privilegio vulnerabilidad de escalada en alguna parte)
• aprovecha vulnerabilidades en el software que el usuario es capaz de ejecutar
• Organizar una red DDoS o de pornografía infantil servidor de archivos en su máquina
• uso del dispositivo como un proxy para el inicio de los ataques contra servidores CIA y el FBI
• el cielo es el límite ...

no suena como un ir od idea.

Answer 3

Un grupo de programas puede ejercer presión en la memoria haciendo que la máquina deje de responder (especialmente cuando comienza a producirse un intercambio en el disco). Código de ejemplo: perl -e '$_.="x"x1000000 while fork'

Answer 4

Por lo tanto, es en la práctica es posible que este programa de espacio de usuario puede hacer que el desplome del sistema operativo, o hacer que la máquina no esté disponible para el proxy?

Bueno, en teoría, debería tener dificultades para bloquear el sistema operativo. Sin embargo, hay muchos informes de errores que dicen que es más posible en la práctica de lo que nos gustaría.

Sin precauciones especiales, por otro lado, será bastante fácil lograr la denegación de servicio. Imagine un programa de usuario que no hizo más que inundar el proxy con paquetes; eso solo podría, si no lograr la negación absoluta del servicio, entonces hacer que las cosas sean embarazosamente lentas.

Con el ensamblaje, el programador puede hacer básicamente lo que quiera (por ejemplo, manipule el puntero de la pila), y me pregunto qué tan restrictivo/robusto es el Linux al respecto.

Sin embargo, somos mucho mejores que eso. Si todo lo que necesita para la escalada de privilegios es "desordenar con el puntero de pila" la seguridad como un campo sería una broma total. El kernel es previsto que se escribirá para que ningún programa, sin importar qué, pueda causar la falla del kernel. Como se señaló, es imperfecto.

La moraleja de la historia es que realmente no desea ejecutar el código no confiable en una computadora que le importa. La respuesta estándar aquí sería una VM con punto de control: inicie una máquina virtual, ejecute el código que no es de confianza en la máquina virtual y luego, una vez que finalice o agote el tiempo de espera, apague la máquina virtual. De esa forma, el daño persistente es imposible. En cuanto a otros abusos, su proxy evitará que alojen servicios de Internet sórdidos, lo cual es bueno. Dependiendo de la situación de su máquina virtual, pueden existir buenas herramientas para limitar el consumo de CPU y el uso de la red, lo que ayudará a eliminar otras posibilidades de denegación de servicio.

Menciona que necesita que la CPU funcione a plena capacidad. La virtualización de hardware es bastante buena, y el rendimiento debería reflejar razonablemente lo que sería en un sistema real.

Nada de lo anterior es específico de Linux, por cierto; debería ser cierto para todos los sistemas operativos creíbles de propósito general.

edición: Si está realmente insistente en funcionamiento directamente en el hardware, entonces:

• arranque desde un dispositivo de sólo lectura (LiveCD o disco duro writeblocked)
• no tienen medios grabables en el sistema
• Agregue un servidor de apagado que puede restablecer forzosamente la máquina a petición del proxy, en caso de denegación de servicio; existen soluciones comerciales para este

Básicamente, le brinda las características de la solución de VM, pero en hardware.

Answer 5

Si el código se está ejecutando bajo una cuenta limitada en una máquina correctamente configurada, debe resistir muchos tipos básicos de ataques (ya sean accidentales o maliciosos).

El hecho de que el programador pueda usar el ensamblaje es irrelevante; los ataques se pueden codificar en muchos idiomas diferentes, compilados o no.

El problema principal son problemas de seguridad desconocidos o vulnerabilidades de 0 días. Permitir cualquier programa no autorizado para ejecutar es un riesgo y si alguien logra explotar un problema que permite la elevación de privilegios, está jodido.

Las cajas de arena generalmente se recomiendan porque restringen lo que la aplicación puede hacer y (si están diseñadas correctamente) minimizan el daño causado por el comportamiento deshonesto.