• Presentation
• Register
• Program
• Organizing Comittee
• Listing of registered people
• Translators team

felix	|Ramon|
krocz	---------------- ATENTION ---------- comenzamos
felix	!jaime startlog
krocz	Bueno un gusto tenerlos por aqui nuevamente
krocz	para nosotros es muy satisfactorio hacer este tipo de charla
krocz	para ello en esta ocacion presentaremos a Andres L. Sclippa
krocz	colaborador Argentino, de la Universidad Tecnolsgica Nacional Facultad Regional Resistencia
krocz	el es analista de seguridad y pertenece a www.LinuxDevelopment.com.ar
krocz	el hace poco nos presento una conferencia sobre "WBEM en Linux" y para
krocz	esta ocacion ha preparado una charla relacionada con
krocz	"Unix Application Security Framework"
krocz	Tenemos la traduccion al ingles en el canal #redes y las preguntas y comentarios en el canal #qc
krocz	a si que le damos la bienvenida a Andres
krocz	adelante Andres
krocz	el canal es tuyo :)
feistel	ok gracias a todos por estar hoy aqui, y estoy muy a gusto colaborando con este noble proyecto
feistel	por favor conectensen a http://170.210.180.9/umeet
feistel	ahi encontraran
feistel	mirrors para las presentaciones
feistel	y un log para los que llegan tarde :)
feistel	las preguntas pueden hacer en #qc
feistel	yo las contesto aca
feistel	ok empecemos
feistel	de todos los ataques a los sistemas UNIX
feistel	a me olvidaba
feistel	voy a ir avisando cuando deben ir cambiando de filmina, ok
feistel	los del tipo DoS y buffer overflow son los mas populares y peligrosos
feistel	(diapositiva 2)
feistel	en esta charla me ocupare de como eliminar o mitigar el segundo tipo de ataque
feistel	en UNIX todo proceso corre con un identificador de usuario y de grupo (UID/GID)
feistel	esto limita el acceso de tal proceso a los recursos del SO
feistel	lamentablemente muchas aplicaciones requieren de privilegios root
feistel	en *NIX u otros privilegios
feistel	para funcionar correctamente (por ejemplo: cambiar la password, necesitan acceder a dispositivos
feistel	<krocz> feistel, te basaras en un SO en especial o es general?
feistel	en general
feistel	en bruto, a determinadas syscalls privilegiadas o a sistemas de archivos
feistel	como /etc)
feistel	entonces encontraremos que muchos procesos corren con privilegios de root
feistel	mientras estos procesos se comporten como fueron diseñados, ningun problema
feistel	me ocupare en general de UNIX :)
feistel	me piden que vaya mas lento por la traduccion
feistel	el problema aparece cuando un atacante logra controlar la ejecucion de tal
feistel	proceso y ejecutar codigo arbitrario con los privilegios del proceso
feistel	para limitar esto, las aplicaciones *NIX han utilizado por años
feistel	dos metodos, el SUID/SGID y el chroot jailing
feistel	la idea del primero es la siguiente
feistel	los procesos corren normalmente con un usuario no privilegiado pero
feistel	cuando requieren acceso privilegiado (como root por ej.)
feistel	ejecutan una syscall que cambia temporalmente el usuario del proceso
feistel	para ello el binario debe tener el bit S activado
feistel	<trulux> feistel, cuando dices en general chroot jailing deberías mencionar otro tipo de jaulas como las de freebsd, y no hablar de jaulas chroot en general en todos los Unices
feistel	si trulux tiene razon
feistel	en este caso me refieron al chroot jailing basico disponible en cualquier UNIX
feistel	para el caso de FreeBSD este es mucho mas funcional :-)
feistel	------------------------
feistel	# ls -aLF /usr/bin/passwd
feistel	-rwsr-xr-x   1 root     root        44705 Jul  1 00:49 /usr/bin/passwd
feistel	^
feistel	------------------------
feistel	ahi ven un binario con el bit activado
feistel	finalizada la ejecucion privilegiada el proceso vuelve a correr con
feistel	los privilegios limitados del usuario original
feistel	el chroot jailing lo que hace es confinar al proceso en
feistel	un filesystem con lo cual si el proceso es hackeado, el atacante
feistel	no tiene acceso al resto de los filesystems
feistel	estas tecnicas ofrecen una seguridad muy limitada
feistel	el SUID/SGID y el chroot pueden cambiarse facilmente una vez que el
feistel	proceso ha sido comprometido
feistel	el stack-smashing attack o buffer overflow attack aparece cuando un
feistel	proceso
feistel	requiere que datos externos sean colocados en un bufer
feistel	(en realidad el buffer overflow es un tipo especial de stack-smashing, pero lo tomaremos
feistel	como sinonimos aqui para facilitar)
feistel	<trulux> feistel, el chroot puede comprometerse en tiempo de ejecución con varios tipos de "trucos", desde hacer un doble chroot hasta intentar matar procesos fuera de el
feistel	como dice trulux chroot es muy vulnerable
feistel	o variables
feistel	y la aplicacion vulnerable no controla correctamente
feistel	el tamaño de tales datos externos
feistel	esto hace que si tal dato tiene un tamaño mayor al del bufer que lo
feistel	almacenara, al momento de almacenarlo, partes contiguas de la memoria
feistel	al bufer son sobreescritas con el contenido sobrante de tal dato
feistel	el problema viene en la estructura que utiliza *NIX en la memoria de
feistel	cada proceso, entonces el area de memoria contigua a los bufers contiene
feistel	datos criticos del proceso que controlan el flujo de ejecucion del mismo
feistel	esto permite que atacantes puedan insertar codigo de maquina (shell codes)
feistel	en aplicaciones vulnerables al buffer overflow y realizar asi
feistel	operaciones no contempladas, con los mismos privilegios del proceso
feistel	(diapo 4)
feistel	en la figura superior vemos la estructura del area de memoria de todo
feistel	proceso
feistel	esta es la estructura tipica de la stack (area de la memoria del proceso
feistel	donde se almacena datos temporales)
feistel	todo funcion C usa la stack desde el stack pointer hacia arriba en la
feistel	figura (el stack pointer apunta al tope de la stack)
feistel	en el siguiente orden: bufers, variables locales, puntero al frame anterior
feistel	, la direccion de retorno (desde donde se llamo a esta funcion) y
feistel	finalmente los argumentos de la funcion
feistel	con lo cual si el codigo no controla el tamaño de los datos a escribir
feistel	en los buffers las areas siguientes de memoria (para arriba en la fig.)
feistel	pueden ser sobreescritas
feistel	la figura inferior muestra una tipica funcion C vulnerable a este ataque
feistel	la funcion strcpy() copia el contenido de la variable de entorno $HOME al
feistel	buffer de 128 bytes
feistel	como no hay control del tamaño de la variable $HOME
feistel	si esta posee mas de 128 bytes el resto del string sobreescribira las
feistel	areas contiguas de memoria
feistel	entonces un atacante en este caso podra introducir shell code en la
feistel	variable $HOME a partir del byte 129, y este shell code se ejecutara con los
feistel	privilegios del proceso
feistel	<krocz> una forma de evitar la ejecucion es dejando el stack, en estado "no execute"
feistel	si eso se conoce como W^X y lo veremos mas adelante
feistel	para eso el shell code sobreescribira la "return address" hacia el area
feistel	de memoria donde esta el codigo arbitrario inyectado,
feistel	y este sera ejecutado cuando la funcion vulnerable finalice y la ejecucion del proceso deba retornar al punto
feistel	desde donde fue llamada la funcion
feistel	segun que area del stack el atacante sobreescriba el stack-smashing puede
feistel	<trulux> feistel, no, W^X es de OpenBSD, hay más implementaciones: Stack Guard de Immunity, ExecShield y PaX por ejemplo
feistel	W^X es un concepto
feistel	no una implementacion
feistel	es una tecnica
feistel	clasificarse en:
feistel	* return address: se modifica la direccion de retorno
feistel	* variables locales o argumentos: se modifican tales variables
feistel	* previous frame pointer: se modifica el puntero al frame anterior
feistel	ahora bien
feistel	una solucion es auditar el codigo fuente de la aplicaciones
feistel	para detectar codigo vulnerable, es decir codigo que no controle el
feistel	tamaño de los strings
feistel	la serie de tecnicas y mecanismos presentados aqui formaran un framework
feistel	donde puedan correr sus aplicaciones *NIX con una seguridad proactiva
feistel	es decir, en caso de que ocurra un buffer overflow por una vulnerabilidad
feistel	no detectada
feistel	este ataque sera eliminado, confinado o a lo sumo limitado.
feistel	(diapo 6)
feistel	ok, la primera tecnica que conforma nuestro framework es una cuestion de diseño
feistel	es la tecnica de separacion de privilegios
feistel	la idea es separar el codigo del proceso en dos partes:
feistel	1 - el proceso privilegiado: usara las syscall que requieran permisos privilegiados
feistel	2 - el proceso no-privilegiado: accedera al resto de todas las syscall, las cuales no requieran de una cuenta
feistel	privilegiada
feistel	entonces cuando el proceso PRIVILEGIADO si inicia hace un fork de si
feistel	mismo
feistel	y su hijo pasa a ser el proceso NOPRIVILEGIADO
feistel	la idea es que la interaccion con el usuario o con procesos locales o remotos
feistel	lo haga el proceso hijo NOPRIVILEGIADO
feistel	con lo cual si este es comprometido
feistel	el atacante tendra limitado su accionar
feistel	para entender mejor la tecnica
feistel	a la derecha ven la arquitectura de una aplicacion famosa el OpenNTP
feistel	que utiliza esta tecnica
feistel	el proceso ntp engine es el proceso no privilegiado (que corre como _ntp)
feistel	el cual se comunica a traves de un socket UNIX-domain (no accesible
feistel	por TCP/IP) con su proceso padre el ntpd master (que corre como root)
feistel	el ntpd master solo usa dos syscall privilegiadas: IMSG_ADJTIME
feistel	y IMSG_HOST_DNS (setear la hora y llamar al resolver library)
feistel	ahora si un atacante inyecta por el UDP 123 shell code solo el proceso
feistel	ntp engine sera comprometido
feistel	ademas en este caso el proceso ntp engine corre en chroot en /var/empty
feistel	con lo cual el mismo queda confinado a ese directorio
feistel	(diaspo 7)
feistel	hasta ahora entonces nuestra aplicacion contiene:
feistel	* SUID/GUID bits
feistel	* chroot jailing
feistel	* privilege separation
feistel	veremos ahora un mecanismo para proteger la memoria
feistel	que algunos OS la implementan, de alguna forma u otra
feistel	el mecanismo W^X (lease W xor X)
feistel	la idea es que areas de memoria tenga un control de acceso
feistel	similar a los bits RWX del UNIX filesystem
feistel	entonces con W^X el OS define una politica por defecto en determinadas
feistel	areas de la memoria
feistel	de manera tal que tales areas sean de acceso de escritura o de ejecucion
feistel	pero nunca ambas
feistel	salvo que la aplicacion lo requiera explicitamente
feistel	el problema de implementar esto esta relacionado con la MMU de la
feistel	arquitectura subyacente
feistel	sparc, sparc64, alpha, amd64, ia64 y hppa tiene todas
feistel	MMU=memory management unit
feistel	un bit X en cada pagina de memoria
feistel	el OS solo debe activar o desactivar este bit y listo ya esta
feistel	pero i386 no tiene este bit
feistel	W^X puede emularse en esta arquitectura gracias al soporte
feistel	de memoria segmentada
feistel	la idea es que los procesos tengan dos segmentos un CODE (area baja)
feistel	y un DATA (area alta de la memoria)
feistel	al iniciar el proceso (todo el code esta en DATA)
feistel	el code es pasado al area baja CODE
feistel	mientras que los datos son pasados al area alta DATA
feistel	el OS entonces mantiene una politica W en DATA y X en CODE
feistel	es decir en i386 el W^X se emula por software
feistel	las tecnicas vistas hasta ahora no generan un overhead ni requieren tocar
feistel	el code
feistel	las dos siguientes generan overhead y una de ellas modifica el code
feistel	(diapositiva 8)
feistel	nuestra aplicacion ahora ya se ve mas segura:
feistel	* SUID/GUID bits
feistel	* chroot jailing
feistel	* privilege separation
feistel	* W^X (o algo parecido)
feistel	el problema en el ultimo caso  es que dependemos exclusivamente del OS y de la
feistel	arquitectura subyacente
feistel	si bien la ejecucion de codigo esta limitada, la stack todavia puede ser alterado
feistel	el ProPolice o Stack Smashing Protector (SSP) es un desarrollo
feistel	de la division de investigacion en Tokio de IBM
feistel	este trabaja con gcc para transformar una
feistel	funcion C vulnerable en una funcion C no vulnerable
feistel	se obtiene un codigo cuyas funciones estan protegidas contra
feistel	corrupcion de la stack
feistel	para esto ProPolice realiza dos cosas
feistel	<trulux> feistel, hay varias implementaciones de SSP: http://wiki.debian-hardened.org/SSP/ProPolice_Implementations
feistel	la idea de la charla es trabajar con tecnologias independientes del OS
feistel	para varios flavors de Unix
feistel	<trulux> feistel, en realidad no se obtiene ningún codigo protegido, sigue sinedo vulenrable pero se llama a la función guard de SSP antes de ejecutar ningún tipo de operación extraña, en el inicio de la ejecución
feistel	SSP tambien ordena la memoria de la funcion, ademas del guard
feistel	el hecho de no puedas hacer un overflow lo hace invulnerable
feistel	1. Reordena la stack
feistel	arriba ven la stack clasica
feistel	abajo la stack ordenada y modificada por ProPolice
feistel	las variables y los arreglos estan en orden opuesto
feistel	en la nueva disposicion de memoria
feistel	(A) no contiene arreglos ni variables punteros
feistel	(B) contiene arreglos y estructuras
feistel	(C) no contiene arreglos
feistel	en el unico lugar donde una destruccion de la stack puede comenzar es en (B)
feistel	lo anterior es la clave de ProPolice
feistel	2. Y agrega codigo en el prologo y en el epilogo de la funcion
feistel	veamos como funciona esto
feistel	en el prologo de la funcion
feistel	(codigo que se ejecuta ni bien la funcion es llamada)
feistel	ProPolice genera un valor aleatorio, el "guard"
feistel	como veran el "guard" es lo primero que aparece en la stack
feistel	(recuerden que la stack crece para abajo)
feistel	es por eso que se lo genera en el prologo
feistel	una copia del "guard" es mantenida en un area protegida fuera del alcance de un overflow
feistel	ni bien la funcion finaliza, antes de retornar a la funcion que la llamo
feistel	se ejecuta el epilogo
feistel	el cual compara el "guard" original con el del stack
feistel	si estos son diferentes la ejecucion del proceso finaliza y se genera un log, asi todo shellcode inyectado no es ejecutado
feistel	por la ubicacion del return address
feistel	la unica forma de modificarlo es a traves de un overflow en los buffers
feistel	(B)
feistel	por la ubicaciones de las variables locales en (C)
feistel	estas estan protegidas por modificacion ya que la destruccion comienza en (B)
feistel	los argumentos (A) por otro lado estan protegidos por el "guard"
feistel	ProPolice tiene algunas excepciones que se deben tener en cuenta
feistel	que estan listadas en el sitio de ProPolice y es de
feistel	interes para programadores en C en UNIX que desean protegerse con ProPolice
feistel	(diapos 9)
feistel	<trulux> quizás quedaría más claro si cuentas algo sobre tipos de "canarios"
feistel	la conferencia abarca muchos temas y la idea es dar un puntapie para una investigacion mas profunda por
feistel	los interesados
feistel	no quieron entrar en la calificaciones de los canarios (otro nombre para el guard)
feistel	trulux, quiere colaborar con un ejemplo real
feistel	dice que tiene todo preparado, lo haremos al final de la charla
feistel	ademas de ProPolice existen otras implementaciones similares
feistel	pero todas ellas tienen limitaciones y debilidades
feistel	en la figura pueden ver una comparacion
feistel	-- aquellos interesados en el tema, pueden quedarse despues ;-) ---
feistel	un resumen de las alternativas
feistel	* libsafe: es una libreria que agrega un control sobre algunas
feistel	funciones de strings populares como strcpy() y gets()
feistel	funciona como un middleware que intercepta las llamadas a estas funciones
feistel	y realiza el control necesario
feistel	* StackGuard: utiliza el mismo concepto del "guard" que lo llama "canario"
feistel	genera un random y hace un XOR con el return address y eso es el "canario"
feistel	* StackShield: utiliza un metodo alternativo, mantiene una copia del return
feistel	address (durante el prologo, despues de los buffers)
feistel	el cual es verificada en el epilogo, no usa "guard" o "canarios"
feistel	tanto StackGuard y StackShield tiene famosas vulnerabilidades y ademas
feistel	generan mayor overhead que ProPolice
feistel	"Phrack Magazine - Volume 0xa Issue 0x38"
feistel	si bien ProPolice es bastante seguro y robusto
feistel	genera un overhead que hay que considerar a la hora
feistel	de decidir si proteger o no nuestro codigo con SSP
feistel	en las diapos 10 y 11 pueden ver algunos benchmark del equipo de desarrollo de ProPolice
feistel	(diapositiva 12)
feistel	nuestra aplicacion ahora ya se encuentra en un framework bastante confiable:
feistel	* SUID/GUID bits
feistel	* chroot jailing
feistel	* privilege separation
feistel	* W^X
feistel	* ProPolice
feistel	sin embargo...
feistel	supongamos que se detecta una vulnerabilidad en algunos de los
feistel	sistemas anteriores, por ejemplo en ProPolice
feistel	(como fue detectado antes en StackGuard y StackShield)
feistel	necesitamos de algo que incluso en esas circunstancias
feistel	nuestras aplicaciones UNIX no comprometan la seguridad del sistema
feistel	entero
feistel	el ultimo componente de nuestro framework es entonces: Systrace
feistel	Systrace es un mecanismo que corre en parte en userland y en
feistel	parte en el kernel
feistel	este mecanismo atrapa todas las syscalls que un proceso utiliza
feistel	y realiza un control de acceso con ellas como si de un firewall se tratase
feistel	es decir definimos politicas de control de acceso Systrace a
feistel	nivel de syscalls
feistel	por ejemplo, podemos limitar que un proceso se enlace (bind()) a determinados
feistel	puertos TCP y se deniegue el resto
feistel	o por ejemplo, impedir la escritura, limitando el uso de write()
feistel	o limitar el write() a especificados archivos o filesystems
feistel	imaginen ahora que un proceso es comprometido y un atacante escala
feistel	privilegios con el
feistel	como nosotros hemos limitado las syscalls que puede usar el proceso o en
feistel	el modo en que las usa, el ataque es confinada o limitado a lo que
feistel	la aplicacion fue desarrollada para hacer
feistel	como se ven en la figura las aplicaciones con Systrace corren en un
feistel	sandbox controlado, donde ellas solo pueden hacer lo que nosotros
feistel	les dejamos hacer
feistel	en el kernel el "System Call Gateway" captura todas las llamadas
feistel	a syscalls de la aplicacion sandboxeada, como si fuese un Proxy
feistel	esta se encarga de ejecutar las verdaderas syscalls y de devolver el
feistel	resultado a la aplicaciones
feistel	como esto es transparante, la aplicacion no se entera de la presencia
feistel	del syscall gateway
feistel	pero antes el syscall gateway debe determinar si las politicas permiten
feistel	la ejecucion de tal syscall
feistel	para eso el modulo de Systrace en el kernel se encarga de comunicarse
feistel	con el modulo del userland, el cual revisando las politicas determina
feistel	si la syscall debe permitirse o negarse
feistel	si la politica decia "permitir" entonces la syscall se ejecuta normalmente
feistel	de lo contrario, no, y la aplicacion recibe un codigo de error (<0)
feistel	Systrace tambien funciona como un IDS (Intrusion Detection System)
feistel	ya puede generar alarmas o notificaciones para el caso en las que syscall
feistel	se denieguen
feistel	por ejemplo una entrada en syslog ser veria algo asi:
feistel	------------------------------------
feistel	Dec  2 01:31:11 openbsdtest systrace: deny user: _identd, \
feistel	prog: /usr/libexec/identd, pid: 27046(1)[12989], \
feistel	policy: /usr/libexec/identd, filters: 24, syscall: native-fsread(5), \
feistel	filename: /etc/spwd.db
feistel	Dec  2 01:31:11 openbsdtest identd[27046]: /etc/pwd.db: Operation not permitted
feistel	Dec  2 01:31:11 openbsdtest identd[27046]: \
feistel	getpwuid() could not map uid (25) to name
feistel	--------------------------------------
feistel	es importante recalcar que Systrace funciona si en el kernel hay soporte
feistel	para el trace de las aplicaciones, es decir poder seguir el rastro
feistel	de las syscalls que un proceso utiliza
feistel	<krocz> feistel, systrace en que status esta en linux??
feistel	esta terminado el patch
feistel	<krocz> feistel eso de ACL a las syscall viene implementado en el parche de grsec
feistel	<trulux> krocz, en la mayoría de sistemas MAC suele venir, RBAC, RSBAC, SELinux, etc
feistel	si es correcto
feistel	pero mi idea es presentar un framework para UNIX,
feistel	ademas a mi me gusta mas Systrace :-)
feistel	despues cada uno elige como armar su framework ;-)
feistel	(diapos 13)
feistel	como se ve una politica Systrace?
feistel	------------------------------
feistel	Policy: /bin/ls, Emulation: native
feistel	native-munmap: permit
feistel	[...]
feistel	native-stat: permit
feistel	native-fsread: filename match "/usr/*" then permit
feistel	native-fsread: filename eq "/tmp" then permit
feistel	native-fsread: filename eq "/etc" then deny[enotdir]
feistel	native-fchdir: permit
feistel	native-fstat: permit
feistel	native-fcntl: permit
feistel	[...]
feistel	native-close: permit
feistel	native-write: permit
feistel	native-exit: permit
feistel	----------------------------------
feistel	luego como en toda ACL, hay una expresion a evaluar y una accion a tomar
feistel	en este caso permit o deny
feistel	vean que este caso /bin/ls solo tiene acceso de lectura al filesystem
feistel	(fsread) /usr/ y al directorio /tmp
feistel	Systrace trae algunas herramientas utiles
feistel	primero un generador de politicas
feistel	que monitorea la aplicaciones a sandboxear y genera una politica
feistel	con todas las syscalls que usan, con accion permit
feistel	durante el monitoreo
feistel	usas la aplicaciones como en la produccion
feistel	todas las syscall llamadas son registradas
feistel	y asi se genera las politicas
feistel	con todas "permit" en tu home
feistel	una vez que tienes la politica la aplicas con algo como
feistel	# systrace -a /usr/sbin/inetd
feistel	y listo! /usr/sbin/inetd ya esta en su sandbox!!
feistel	una herramienta grafica (ver la figura)
feistel	te puede asistir en la confeccion de las politicas tambien
feistel	otra caracteristica que me gusta de Systrace es el soporte
feistel	para escalada de privilegios, lo cual elimina la necesidad de usar
feistel	los peligrosos SUID/GUID
feistel	estas politicas se ven algo asi:
feistel	-------------------------------------------
feistel	native-socket: sockdom eq "AF_INET" and socktype eq "SOCK_RAW" then permit as root
feistel	native-bind: sockaddr eq "inet-[0.0.0.0]:22" then permit as root
feistel	native-fsread: filename eq "/dev/kmem" then permit as :kmem
feistel	-------------------------------------------
Session Time: Thu Dec 16 00:00:00 2004
feistel	(diapos 15)
feistel	finalmente que hay del costo de overhead de Systrace
feistel	pues depende de la aplicacion, ahi pueden ver algunos benchmarks
feistel	ahora si tenemos un buen framework!
feistel	* (sacamos los peligrosos SUID/GUID gracias a Systrace)
feistel	* chroot jailing: confinamos la aplicacion a un filesystem
feistel	* privilege separation: ocultamos el modulo con acceso privilegiado de los clientes
feistel	* W^X: establecemos politicas a las areas de memoria vulnerables
feistel	* ProPolice: protegemos nuestra aplicacion contra un stack-smashing attack
feistel	* Systrace: confinamos a la aplicacion en un sandbox controlado
feistel	--fin---
feistel	bueno este es mi framework, espero que les guste y que lo prueben...
krocz	CLAP CLAP CLAP
krocz	CLAP CLAP CLAP
krocz	CLAP CLAP CLAP
krocz	CLAP CLAP CLAP
krocz	CLAP CLAP CLAP
techi	clap clap clap clap clapclap clap clap clap clap
krocz	feistel increible
JulHer	plas plas plas plas
JulHer	plas plas plas plas
overflow_	Clap
JulHer	plas plas plas plas
overflow_	Clap
overflow_	Clap
JulHer	plas plas plas plas
overflow_	Clap
funky	clap clap clap clap clap clap
PedroJ	clap,clap,clap,clap,clap
funky	clap clap clap clap clap clap
overflow_	FELICITACIONES!
krocz	CLAP CLAP CLAP CLAP CLAP CLAP
krocz	CLAP CLAP CLAP CLAP CLAP CLAP
krocz	CLAP CLAP CLAP CLAP CLAP CLAP
krocz	CLAP CLAP CLAP CLAP CLAP CLAP
felix	bravo!
feistel	bueno gracias, es un gusto colaborar con estos proyectos
PedroJ	clap,clap,clap,clap,clap,clap
trulux	;D
felix	!unlog
krocz	feistel conferencia muy buena, de alta calidad :)
trulux	bueno, pues voy a intentar enseñar más o menos el concepto de seguridad proactiva
felix	!date
jaime	felix: Wed Dec 15 22:55:39 2004
felix	!startlog
jaime	felix: Estoy logueando el canal #linux  en [http://felix.zapto.org/jaime/linux.html]
felix	fucking jaime! :(
feistel	krocz: gracias, lo menos que podia hacer para la UMEET
trulux	y demostrando como funciona ProPolice , en la práctica real
trulux	krocz, ahi va
trulux	bien, tenemos una aplicación que gestiona los datos de una empresa, en concreto la base de datos de empleados
trulux	es simple, usa una base de datos en plano, y añade salarios, edades, nombres y apellidos y notas
trulux	tiene autenticación
trulux	para asegurar que nadie puede modificar los datos
trulux	y el bit setuid para poder leer y escribir la .employee2.dbs
trulux	veamos como funciona:
trulux	lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./employee2
trulux	- No password provided for authentication.
trulux	nos pide contraseña, bien
trulux	si fuesemos el "jefe", simplemente haríamos lo siguiente:
trulux	lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./employee2 l33t_b0ss
trulux	(!) Logged in.
trulux	===========ACME Inc. Employees=============
trulux	A: Add an employee to the database
trulux	D: Display employee information
trulux	L: List employees
trulux	M: Load Database
trulux	R: Raise the salary of an employee
trulux	S: Save Database
trulux	X: Exit
trulux	Your choice:
trulux	bien, es simple
trulux	uno de los empleados está enfadado, y mucho
trulux	es el típico pisateclas que anda de un lado para otro solucionando problemas al resto de personal
trulux	alguien le ha filtrado que el programa tiene un fallo
trulux	sabe que es un desbordamiento de buffer, no comoce los detalles pero lo único que puede afectar al programa es el argumento que se pasa como contraseña
trulux	este buen hombre empieza a investigar:
trulux	haciendo un strings ve que hay un hash extraño: 6a3649f2caa1602c52252f336c43a6cc , parece md5, y lo es
trulux	le da igual, no busca eso
trulux	se da cuenta de que tiene el bit setuid:
trulux	-rwsr-sr-x  1 root root 24515 2004-12-14 22:53 employee2
trulux	y sabiendo que el problema reside en el control de la longitud y copiado en memoria de los parámetros dados por el usuario...
trulux	se pone a investigar y se da cuenta de que el buffer está limitado a 512 bytes
trulux	sin mayores dificultades, busca una forma fácil de explotar ese fallo
trulux	después de una ardua lectura del art?iulo de Aleph1, Smashing the stack for fun and profit, descubre una forma sencilla:
trulux	un programa al que le da como parámetros el tamaño del buffer a desbordar y el offset/dirección dónde preparar los datos a ejecutar
trulux	en este caso un "shell code"
trulux	que arrancará una shell pseudo-interactiva con privilegios de root
trulux	arranca una sesión de depuración
trulux	gdb employee2
trulux	disassemble main
trulux	...
trulux	revisa el código y encuentra el punto donde se llama a strcpy
trulux	que copia argven el buffer vulnerable
trulux	(...)
trulux	0x00000a99 <main+21>:   and    $0xfffffff0,%esp
trulux	(...)
trulux	0x00000aa3 <main+31>:   lea    0xfffff3b8(%ebx),%eax
trulux	0x00000aa9 <main+37>:   mov    %eax,0xfffffd50(%ebp)
trulux	0x00000aaf <main+43>:   cmpl   $0x1,0x8(%ebp)
trulux	0x00000ab3 <main+47>:   jle    0xbc1 <main+317>
trulux	ahi lo tenemos, 317
trulux	previamente ha habilitado el correspondiente espacio de memoria
trulux	y ahi copia nuestro registro
trulux	el chico ya sabe lo que debe hacer:
trulux	:~/project1/$ ./breakfast 612 317
trulux	+ Using address: 0xbffff09b
trulux	+ Entering a subshell...
trulux	deadbeef@acme:~/project1/$ employee2 $EGG
trulux	- Wrong password!
trulux	sh-2.05b# id && whoami
trulux	uid=1000(deadbeef) gid=1000(deadbeef) euid=0(root) groups=1000(deadbeef)
trulux	root
trulux	como veis, ha obtenido privilegios de root, asunto concluido, sin necesidad de excesivos conocimientos consigue poner en serio compromiso datos relevantes de su empresa
trulux	y ahora veamos que ocurre si employee2 fue compilado con un gcc usando la extensión SSP/ProPolice
trulux	repite basicamente el mismo proceso
trulux	pero el encargado de administrar y desarrollar employee2 ha hecho lo siguiente:
trulux	pr@acme:~/em/$ gcc employee2.c -fPIE -fstack-protector -lssp -o employee2 -lm md5.c
trulux	pr@acme:~/em/$ sudo mv employee2 /usr/bin/ && sudo chown root.root /usr/bin/empl*
trulux	pr@acme:~/em/$ sudo chmod u+s+x+r-w /usr/bin/employee2
trulux	ha usado una biblioteca, la libssp (implementación de SSP como biblioteca independiente de la Glibc o la libgcc)
trulux	que contiene las rutinas de protección del SSP
trulux	y los demás pasos son idénticos a los que realizó cuando no usó el SSP
trulux	deadbeef (nuestro empleado "cabreado") lo reintenta y...
trulux	deadbeef@acme:~$ ./employee2 $EGG
trulux	- Wrong password!
trulux	employee2: stack smashing attack in function main()
trulux	----
trulux	main=0x80002828 __guard_setup=0x4001daf0 __guard=0x5fcc95a9
trulux	ppid=15801 pid=15819 uid=1000 euid=1000 gid=1000 egid=1000
trulux	----
trulux	Aborted
trulux	el programa lanza un SIGABRT y finaliza sin compromiso alguno
trulux	por supuesto el evento ha sido registrado
trulux	y deadbeef no tendrá que enfadarse nunca más con su empresa porque no volverá a trabajr con ellos
trulux	se acabó
overflow_	CLAP CLAP CLAP CLAP
overflow_	CLAP CLAP CLAP CLAP
krocz	CLAP CLAP CLAP CLAP
krocz	CLAP CLAP CLAP CLAP
krocz	CLAP CLAP CLAP CLAP
p4ch0	CLAP CLAP CLAP CLAP
p4ch0	CLAP CLAP CLAP CLAP
trulux	ahora veamos que diferencias hay en el employee2 y las comentaremos entre todos para ver como trabaja de verdad el SSP
trulux	;D
xtinAWAY	CLAP CLAP CLAP CLAP
xtinAWAY	CLAP CLAP CLAP CLAP
trulux	bueno, que quede claro que deadbeef es una persona fictia *srugh*
trulux	he colgado unas diapositivas aún no acabadas que podeís ver en http://www.debian-hardened.org/papers/hardened-debian-2005-en.pdf
trulux	la explicación es más larga y lamento no haber dado de sí mucho más pero aquí es tarde (24:24) y suelo madrugar ;P
krocz	bueno trulux ofrecera una charla el dia 19 de diciembre
krocz	a las 20 GMT
krocz	explicando en extenso :)
krocz	esto solo fue un avance
trulux	tengo preparadas un par de sorpresas, alguna que otra herramienta no publicada que será de interés
damage	:O!
krocz	bueno te esperamos el dia 19

Generated by irclog2html.pl by Jeff Waugh - find it at freshmeat.net!

The Organizing Comittee

More information

© 2004 - www.uninet.edu - Contact Organizing Comittee - Valid XHTML - Valid CSS - Based on a Design by Raul Pérez Justicia