|
|
|
|
II: daemons running with priviliged uid's
race conditions
poor file protectons
implicit file protections
trust
authentication
III: Kernel problems
Kernel race conditions
device driver code
El siguiente metodo de 4 pasos fue creado por System Development
Corporation, que da un indice de 65% de éxito en las hipotesis generadas.
El hacer una busqueda detallada de imperfecciones en los sistemas operativos requiere
4 pasos:
Paso 1) Conocimiento de la estructura de control del sistema
==============================================================
Para encontrar agujeros de seguridad, e identificar debilidades de diseño es necesario
entender la estructura de control del sistema, y las capas.
Uno deberia ser capaz de listar:
A)objetos de seguridad: componentes que deben ser protegidos. Ej: un archivo de usuario
B)objetos de control: componentes que protegen objetos de seguridad. Ej: un i-node
C)objetos reciprocos: objetos de ambas clases. Ej: el archivo de password.
Con dicha lista, es posible el representar graficamente una jerarquia de control e
identificar puntos potenciales de ataque. Hacer diagramas de flujo para dar un
analisis visual de relaciones definitivamente ayuda. El leer los varios manuales
de usuario, operadores, y administradores proveera dicha informacion.
Paso 2) Generar un inventario de desperfectos sospechosos
===========================================================
En particular queremos:
Historia de codigo:
De que UNIX deriva un defecto en particular? Esto es importante para proximas
referencias (muy a menudo solo un vendedor parchea partes del codigo, que sera
usado por otros en su "reencarnacion" sin parchear.
Una referencia solida:
Quien chequea que bugs hay, en que sistema operativo y en que versiones, nos
previene de realizar una doble tarea.
Un buen comienzo seria el listar todos los binarios suid de las diferentes versiones
de los sistemas operativos. Despues intentar averiguar por que cada programa es suid
ej: rcp es suid root ya que debe usar un puerto privilegiado para autentificar nombres
de usuario.
A menudo, codigo que nunca fue diseñado para ser suid, se hace suid, para resolver
problemas de acceso a ficheros.
Necesitamos crear una base de datos que sea capaz de "mirar" a pares y trios de datos,
especificamente:nombre del programa, suid, sgid, objeto accedido (por que es suid/sgid),
version del sistema operativo.
Alguna sugerencia de como implementar dicha base de datos?
Paso 3) Confirmar hipotesis (testear y explotar los defectos)
===============================================================
Paso 4) Hacer generalizaciones de las debilidades del sistema, para
las que los defectos representan un ejemplo especifico
=====================================================================
Caja de herramientas
=====================
AGREP: Recomiendo a todo el mundo pillar e instalar agrep de:
ftp cs.arizona.edu /agrep/agrep.tar.Z
Agrep soporta "windowing" por lo que puede busacr rutinas, y subrutinas. Tambien
soporta operadores logicos y es de esta forma ideal para automatizar la busqueda de
muchos de estos defectos. Ej: <psudocode>
agrep WINDOW {suid() NOT taintperl()} /usr/local/*.pl
or agrep WINDOW {[suid() OR sgid()] AND [system() OR popen() OR execlp()
OR execvp()]} /usr/local/src/*.c
PROGRAMA DE PERMUTACION: Otra herramienta que merece producir es un programa que
genere todas las permutaciones posibles de los argumentos de la linea de comandos
para asi descubrir caracteristicas indocumentadas, y tratar de producir errores.
TCOV:
CRASH: Posteado a USENET (que archivo FTP?)(descripcion?)
TEXTOS: Hay varios textos que tratan metodos sobre como encontrar defectos, y
presentan series de tests
1) Un estudio empirico de la seguridad de las utilidades UNIX, por Barton P. Miller,
Lars Fredriksen, and Bryan So, Comm ACM, v33 n12, pp32-44,Diciembre 90. Describe
una serie de tests para testear cadenas aleatorias de entradas.
Los resultados indicaban que un 25% de los programas se colgaban, se venian abajo, o
no actuaban como debian. En un caso el sistema operativo se vino abajo.
El entendimiento de la composicion del buffer y el registro en el ambiente en
cuestion, y la entrada esperada se entiende que dara los resultados esperados.
2) El conjunto de herramientas Mothra, in Proceedings of the 22nd Hawaii International
|
|
|
|
|
