Tema 15
En esta unidad se estudia cómo el sistema operativo protege la ejecución de procesos, aísla espacios de memoria y controla el acceso a privilegios sensibles. Gran parte de los ataques exitosos intentan justamente romper esas barreras para obtener ejecución indebida, persistencia o control administrativo sobre el host.
El sistema operativo no solo administra tareas; también impone límites entre ellas. Cada proceso debería ejecutar su trabajo dentro de un espacio controlado, con acceso restringido a memoria, archivos, dispositivos y funciones privilegiadas. Esa separación es una defensa fundamental.
Cuando un atacante logra romperla, el impacto puede ser enorme. Puede leer memoria ajena, inyectar código, secuestrar ejecución, robar secretos, modificar procesos confiables o escalar privilegios. Por eso la seguridad de procesos y memoria no es un detalle interno del sistema, sino una pieza central de la defensa del host.
Un proceso es una instancia en ejecución con contexto propio: código, memoria, identificador, privilegios, handles, archivos abiertos, sockets y recursos asociados. Desde la seguridad, esto implica que cada proceso tiene una identidad operativa y un conjunto de permisos que deben estar claramente delimitados.
La defensa no se limita a impedir que procesos extraños se ejecuten. También importa controlar qué procesos legítimos pueden hacer, cómo interactúan entre sí, qué usuarios los lanzan y con qué derechos corren.
Uno de los principios más importantes es el aislamiento. En un sistema sano, un proceso no debería poder leer o modificar arbitrariamente la memoria de otro proceso, ni interferir con su ejecución sin autorización explícita y controlada.
Este aislamiento reduce el impacto de fallas locales. Si una aplicación tiene una vulnerabilidad, el ideal es que el daño quede contenido dentro de su propio contexto. Cuando el aislamiento es débil o puede ser burlado, un compromiso pequeño puede escalar rápidamente hacia control más amplio del sistema.
Cada proceso opera dentro de un espacio de memoria propio gestionado por el sistema operativo. Esto permite que los datos, instrucciones y estados de ejecución queden separados de los de otros procesos. La memoria virtual, las tablas de páginas y otras estructuras del sistema hacen posible este modelo.
Desde la seguridad, la separación de contexto significa que una falla en un programa no debería convertirse automáticamente en visibilidad o control sobre la memoria de otro. Mantener esta frontera es esencial para proteger secretos, sesiones, credenciales temporales y estado interno de aplicaciones.
Muchas vulnerabilidades históricas del software han surgido de errores en el manejo de memoria: desbordamientos de buffer, uso después de liberar memoria, doble liberación, punteros inválidos o accesos fuera de límites. Estas fallas no son solo problemas de programación; son problemas de seguridad porque pueden alterar el flujo de ejecución.
Cuando un atacante explota una vulnerabilidad de este tipo, puede lograr corrupción de memoria, fuga de información o ejecución arbitraria de código. Por eso el sistema operativo incorpora mitigaciones destinadas a dificultar o contener estas técnicas.
Un objetivo clásico del atacante es lograr que el sistema ejecute instrucciones elegidas por él o que desvíe el flujo normal hacia rutas controladas. Esto puede ocurrir mediante binarios maliciosos, scripts, carga de bibliotecas, explotación de memoria o abuso de aplicaciones legítimas.
La seguridad de ejecución consiste en limitar qué código puede correr, desde dónde, con qué integridad y bajo qué condiciones. Cuanto más control tenga el sistema operativo sobre ese proceso, más difícil será para el atacante convertir una vulnerabilidad en control efectivo.
Los sistemas modernos incorporan diversas mitigaciones destinadas a complicar la explotación de memoria y el secuestro del flujo de ejecución. Entre ellas suelen aparecer:
Estas defensas no eliminan todas las vulnerabilidades, pero elevan el costo técnico del ataque y reducen la probabilidad de explotación confiable.
Escalar privilegios significa pasar de un contexto con permisos limitados a otro con permisos más altos. Esto puede ocurrir desde un usuario común hacia administrador, desde una aplicación restringida hacia control del sistema o desde modo usuario hacia kernel en los casos más graves.
Desde la perspectiva del atacante, el escalamiento es una fase decisiva. Permite ampliar acceso, desactivar defensas, instalar persistencia robusta, manipular evidencia y controlar más recursos del host. Por eso muchas cadenas de ataque combinan acceso inicial limitado con una segunda fase destinada a elevar privilegios.
No todo código que se ejecuta en un sistema tiene el mismo poder. Un proceso con permisos de usuario estándar no debería poder cambiar configuraciones críticas, instalar drivers, leer cualquier archivo o manipular servicios sensibles. Esa limitación es una barrera defensiva importante.
Cuando los privilegios son excesivos o mal asignados, el atacante no necesita escalar: ya recibe demasiado poder desde el inicio. Por eso el mínimo privilegio sigue siendo una defensa transversal en toda la seguridad de procesos y ejecución.
Un atacante no siempre necesita ejecutar un binario independiente. En muchos casos intenta inyectar código en un proceso legítimo, aprovechar bibliotecas compartidas, secuestrar DLL, modificar variables de entorno o utilizar intérpretes y herramientas ya presentes en el sistema.
Este tipo de técnicas complica la detección porque el proceso visible puede parecer normal. La amenaza no siempre está en el nombre del binario, sino en cómo se usa y qué comportamiento resulta de esa ejecución.
| Área | Riesgo principal | Impacto posible |
|---|---|---|
| Procesos | Ejecución indebida o manipulación | Persistencia, ocultamiento o abuso de confianza |
| Memoria | Corrupción o lectura no autorizada | Robo de secretos o secuestro de ejecución |
| Privilegios | Asignación excesiva o elevación indebida | Control ampliado del sistema |
| Kernel | Falla de aislamiento con modo usuario | Compromiso profundo del host |
| Carga de código | Ejecución de binarios o módulos no confiables | Persistencia, evasión o sabotaje |
Los sistemas operativos diferencian varios niveles de capacidad. Un usuario estándar opera con permisos acotados; un administrador puede modificar configuraciones críticas; el sistema o kernel tiene acceso aún más profundo a funciones esenciales. Entender esta jerarquía es clave para comprender el riesgo del escalamiento.
No todas las elevaciones tienen el mismo impacto. Pasar de usuario a administrador ya es grave; pasar de usuario o administrador a control del kernel afecta la base misma de confianza del host.
La separación entre modo usuario y modo kernel es una de las barreras más importantes del diseño del sistema operativo. El modo usuario restringe acceso directo a hardware y funciones críticas; el modo kernel concentra privilegios profundos y controla recursos centrales del sistema.
Cuando una vulnerabilidad permite cruzar esa frontera, el incidente adquiere una gravedad especial. El atacante puede manipular memoria, interceptar llamadas, ocultar actividad o alterar mecanismos defensivos con mucha más facilidad.
Las credenciales, tokens, claves temporales, sesiones y configuraciones críticas suelen pasar por memoria durante la ejecución normal del sistema. Esto significa que comprometer memoria no solo sirve para tomar control del proceso, sino también para capturar información sensible sin tocar archivos persistentes.
Por eso la protección de memoria tiene relevancia más allá de la estabilidad. También protege secretos efímeros que pueden ser suficientes para moverse lateralmente o mantener acceso.
Muchos procesos dependen de bibliotecas dinámicas o módulos cargados en tiempo de ejecución. El sistema operativo también puede cargar controladores o extensiones con privilegios elevados. Si el origen o la integridad de esos componentes no se controla bien, se abre una vía crítica de compromiso.
Esto explica por qué la firma, validación y restricción de módulos o drivers tiene tanta importancia. Un componente cargado en un contexto privilegiado puede darle al atacante un punto de apoyo extraordinariamente poderoso.
No todo escalamiento depende de una vulnerabilidad técnica compleja. Muchas veces surge de configuraciones débiles: servicios que corren con más privilegios de los necesarios, binarios con permisos inseguros, tareas programadas mal definidas, rutas de búsqueda manipulables o cuentas de servicio sobreprivilegiadas.
Esto refuerza una idea central del curso: la seguridad del sistema operativo depende tanto del diseño técnico como de la administración cotidiana. Una mala configuración puede ser tan peligrosa como una falla de software.
Controlar qué código puede ejecutarse reduce drásticamente la superficie disponible para ataques basados en binarios, scripts o herramientas no autorizadas. Las listas blancas, políticas de ejecución, restricciones por ruta o firma y controles sobre intérpretes limitan la libertad del atacante dentro del host.
Estas medidas no impiden todas las técnicas, pero sí obligan a usar caminos más complejos o más visibles. Son especialmente valiosas en estaciones de trabajo y entornos con software relativamente estable.
Defenderse del escalamiento requiere una combinación de medidas:
La clave es no tratar el escalamiento como un problema aislado. Suele depender de varias capas: configuración, software, monitoreo y control de ejecución.
El tema anterior mostró la importancia del monitoreo. En esta área, observar procesos nuevos, servicios modificados, uso anómalo de cuentas privilegiadas, inyección aparente, cambios de integridad o actividad de red inesperada puede revelar intentos de escalamiento o abuso de ejecución.
La protección técnica y la detección se complementan: una limita lo posible; la otra ayuda a descubrir cuando la limitación está siendo forzada o sorteada.
| Control | Qué protege | Cómo ayuda |
|---|---|---|
| Mínimo privilegio | Usuarios y procesos | Reduce impacto de ejecución inicial |
| Mitigaciones de memoria | Flujo de ejecución | Complica explotación confiable |
| Control de aplicaciones | Ejecución de código | Bloquea binarios no aprobados |
| Protección de integridad | Archivos y binarios críticos | Detecta cambios inesperados |
| Monitoreo de privilegios | Eventos de elevación | Ayuda a detectar abuso temprano |
Windows suele mostrar este problema a través de tokens, UAC, servicios, drivers, integridad de procesos, cargas de DLL y mecanismos de protección del kernel. Linux lo expresa mediante permisos, `sudo`, capacidades, servicios, espacios de nombres, bibliotecas compartidas, módulos del kernel y configuraciones del sistema.
Las herramientas concretas cambian, pero la lógica es la misma: separar contextos, limitar ejecución, controlar privilegios y hacer difícil que un proceso comprometido se convierta en control total del host.
En algunos casos, además del aislamiento clásico entre procesos, se aplican mecanismos extra de sandboxing o contención. Estos entornos restringidos limitan acceso a archivos, red, dispositivos o funciones del sistema aun cuando el proceso esté en ejecución normal.
La idea es que una aplicación expuesta o de mayor riesgo opere dentro de un contenedor defensivo que minimice daño en caso de compromiso. No elimina el riesgo, pero reduce lateralidad e impacto.
Estos errores suelen transformar una intrusión limitada en un compromiso sistémico con mucha mayor rapidez.
Imaginemos una estación de trabajo donde un usuario abre un archivo malicioso y se ejecuta un proceso con permisos estándar. Si el sistema está bien administrado, ese proceso debería enfrentar varias barreras: restricciones de ejecución, privilegios acotados, aislamiento, monitoreo y defensas de memoria.
Pero si además existen servicios mal configurados, binarios con permisos débiles y componentes sin parchear, el atacante puede usar esa primera ejecución limitada para escalar privilegios y ganar control administrativo. El caso muestra que el problema no es solo la ejecución inicial, sino la ausencia de barreras posteriores.
Estas preguntas ayudan a entender si el sistema está preparado para contener compromisos o si una falla puntual puede convertirse rápidamente en control amplio del host.
La seguridad en procesos, memoria, ejecución y privilegios protege la capacidad del sistema operativo para mantener separaciones confiables entre tareas, usuarios y niveles de acceso. Cuando esas barreras fallan, el atacante puede transformar una intrusión puntual en control profundo del host.
En el próximo tema se estudiarán la virtualización, los contenedores y el aislamiento de entornos, para analizar cómo el sistema operativo y la infraestructura separan cargas de trabajo y reducen impacto entre contextos distintos.