Servidor de socket personalizado en Internet ejecutándose como root

Que el código "se ejecuta como root" es en su mayoría irrelevante. Raíz o no raíz es una distinción que tiene sentido solo localmente para una máquina, y solo si desea contener algún código potencialmente hostil (por ejemplo, un código de servidor pirateado) sin desactivar toda la máquina. Este es el modelo de mainframe de hace unas décadas. En ese momento, se creía que usted podría tener un sistema Unix (o similar a Unix) de tal manera que el proceso no root pudiera mantenerse separado el uno del otro, sin ninguna posibilidad de evadir esa contención y alcance. otro proceso en la misma máquina.

Esta creencia casi no se sostiene hoy en día. Las escaladas de privilegios locales son abundantes; es muy difícil conectarlos todos a la vez que se mantiene un entorno completamente funcional. En general, es más seguro asumir que cualquier código hostil que se ejecute en la máquina, bajo cualquier usuario, podrá tomar el control de todo el sistema, a menos que se apliquen medidas de contención más fuertes, como (en niveles crecientes de complejidad y contención). ) chroot , jail , máquinas virtuales . En cualquier caso, un proceso que llame a mmap () en /dev/mem puede obtener el control total en la máquina local (posiblemente la máquina virtual si va por el camino de la máquina virtual).

La conclusión de todo esto es que si tu máquina es pirateada, y hacer que esté orientada a Internet aumenta esa probabilidad, entonces deberías preguntarte qué podría suceder si los forasteros hostiles la subvierten. Cambiar el código para no ejecutarse como root y no para mmap /dev/mem no cambia sustancialmente las cosas aquí. Lo que importa es si el código ha sido bien diseñado, revisado, probado, documentado y mantenido.

Debo decir que un mmap() directo en /dev/mem envía una fuerte señal de que "a estos tipos no se les debe permitir acercarse a un teclado". No sé por qué lo haces en tu servidor (*) pero parece realmente extraño. La asignación de RAM física en su espacio de direcciones no es un problema de seguridad , a menos que se aferre al modelo de mainframe obsoleto; sin embargo, hacer cosas muy extrañas es un problema de seguridad porque hace que el diseño, la revisión, las pruebas, la documentación y el mantenimiento sean mucho más difíciles.

^{(*) Mi mejor conjetura es que su servidor interactúa con una pieza de hardware personalizada que carece de un controlador de kernel específico, y hace E / S al mapear sus circuitos en el espacio de direcciones físicas, como, por ejemplo, un tarjeta grafica. Sería más limpio, y por lo tanto más seguro, escribir un controlador de kernel apropiado.}

Francamente, las palabras relevantes son "código personalizado que se ejecuta como root y está expuesto al público".

Para justificar el esfuerzo de codificación y los retrasos, tendrá que hacer algunos cálculos rápidos sobre el impacto del código que se está explotando y un actor malintencionado que obtiene acceso de raíz al servidor en el que se está ejecutando. Si el costo de una infracción es mayor que el costo del esfuerzo de codificación y la demora en la programación, entonces usted tiene una métrica clara que debe presentar ante la empresa, y pueden hacer la llamada sobre los riesgos que están dispuestos a asumir.

Un factor importante a considerar es la probabilidad de que un actor malintencionado obtenga acceso a la raíz directamente desde su código personalizado, en lugar de obtener acceso al usuario no root al que podría ejecutarse el código. También debe tener en cuenta la probabilidad de escalar a la raíz desde el usuario no root. Si obtener acceso al usuario no root tiene el mismo impacto que obtener acceso root, o si escalar al usuario root no es trivial, entonces no hay diferencia entre los 2 usuarios.

Hablarle a la empresa puede ser muy difícil porque su perspectiva es muy diferente de la técnica, y tienen que equilibrar más problemas que solo la tecnología. Encontrar un lenguaje común, como el dinero, tiende a ayudar a proporcionar un terreno común.

Puede intentar demostrar los problemas del servidor que ocurrieron en servidores bien probados y hacer la reclamación "Si después de todas las pruebas y el examen fueron inseguros, ¿cómo podemos esperar que sea mejor?"

El primer ejemplo que aparece en mi cabeza es el error de Shellshock . Cuando combinado con CGI del servidor web Apache, permitió la ejecución remota. Esto no se debió a un error en Apache, pero aun así Apache se volvió vulnerable. Si siguió las mejores prácticas y ejecutó a Apache como un usuario sin privilegios, esto solo fue una mala vulnerabilidad. Si ejecutó Apache como root, fue una vulnerabilidad fatal que puso en grave peligro la seguridad de su servidor y todo lo que estaba conectado a él.

PD: Estoy de acuerdo en que decir "esto es una locura". debería ser más que suficiente :)

Es realmente importante que proporcione soluciones alternativas viables y no solo Confíe en argumentos que es una mala solución técnica. Por ejemplo, podría usar una VPN La instalación puede ser una mejor opción en lugar de volver a desarrollar el código para usar un no privilegiado ¿usuario? ¿Se puede generalizar la solución? Por ejemplo, una solución VPN proporcionaría Funcionalidad mayor y más segura en otras áreas también. No solo discutas eso es una mala idea, defiende una mejor idea que les dé la solución que desean. A Para ello, tendrá que entender qué es lo que realmente quieren, no lo que Han pedido, pero cuál es el controlador subyacente. A menudo encontrarás que lo que ellos Lo que piden es lo incorrecto, pero la funcionalidad que quieren es necesario. Comprender esto le permitirá identificar una mejor solución que será feliz con.

La otra cosa que debe hacer es priorizar los costos / riesgos del negocio sobre los técnicos unos También puede incluir los riesgos / costos de base técnica, pero no se enfoca en ellos. Tan pronto como empiece a hablar de escalada de privilegios, CVE, cifrado de datos, firewalls, puertos, etc., perderá el interés de los gerentes de negocios. En lugar, hablar sobre cosas como pérdida de ventas / productividad, daños a la reputación, robo de comercio secretos o información de propiedad, menor confianza del cliente, gobierno y otros Cumplimiento, etc. Esencialmente, ponga su caso en términos que la administración pueda entender: términos de negocios.

Si todo lo demás falla, considere argumentar para una prueba de penetración o auditoría externa. los La desafortunada realidad es que, con demasiada frecuencia, la gerencia no escucha la información interna. recomendaciones técnicas, pero se sentará y tomará nota tan pronto como una reputación La empresa externa o consultor señala los riesgos. Esto se debe a veces a la Empresa externa / consultor que tiene mejores habilidades para presentar argumentos en los negocios. términos y, a veces es porque están más dispuestos a presentar los hechos en una forma directa y clara que el personal interno puede ser reacio a hacer porque podría ser Se interpretan incorrectamente o se reflejan mal en ellos. A menudo este proceso es extremadamente frustrante ya que la compañía / consultor externo dirá exactamente lo mismo que usted he estado diciendo No se preocupe por eso, concéntrese en el objetivo final, que es conseguir un Mejor solución que puede administrar y no lo mantiene despierto por la noche preocuparse por cuando las cosas marrones golpearán al fan.

Al final del día, todo lo que puede hacer es identificar e informar los riesgos y garantizar Se comunican lo más claramente posible a quienes hacen la final. decisiones Se les está pagando grandes sumas de dinero para asumir la responsabilidad de esas decisiones y en realidad es bastante legítimo que ellos decidan aceptar el Riesgos y seguir adelante de todos modos. Todavía puedes pensar que es una mala idea, pero eso es en gran medida irrelevante. Por lo que sabes, puede haber otras estrategias o razones. que cambian la ecuación de riesgo y toman la decisión de continuar con lo que sienten que es una mala solución una opción viable después de todo. Siempre que haya hecho lo que pudo para Comunica los riesgos y proporciona alternativas viables, has hecho lo que se requiere. y ahora necesita implementar la decisión final de la mejor manera que pueda con el recursos proporcionados.