Hola,
> > tambien era en el caso que el programa "nuestro" se ejecuto con setuid de
> > root
> >
> > Hay varios exploits que se aprovechan de eso, de no comprobar si el
> > fichero que el programa intenta abrir es un enlace simb�lico o no existe
> >
> > Imagina que nuestro programa se ejecuta como setuid de root y que un
> > usuario normal ha hecho un enlace de "prueba.txt" a /etc/passwd...
>
> Claro faltaba esa parte.
ahora ya est�...
> > Si lo digo es por algo }:-)
>
> Bueno un programa que vaya a funcionar con setuid es una cosa
> suficientemente seria como para atar absolutamente todos los
> cabos y no veo que fopen "a+" sea mucho m�s peligroso que
> fopen "w" por ejemplo. Si tienes privilegios de root incluso
yo tampoco, eso lo coment� Juan Antonio...
> un fopen "r" resulta peligroso. Bastar�a hacer un
> ln -s /etc/shadow .... para leer las claves y copiarlas a
> otro sitio para atacarlas o leer algunos logs sumamente interesantes.
correcto
> Lo mismo puede decirse de unlink, link, exec, y cualquier otra llamada
> al sistema que acepte un nombre de fichero.
s�p
> Si usas dentro de un programa setuid una llamada al sistema a la cual
> le pasas un nombre de fichero incontrolado que puede ser alterado por
> cualquiera lo tienes crud�simo y en mi opini�n ese es el verdadero fallo
> de caso que tu comentas por lo cual un fopen "a+" no a�ade gran cosa.
hay gente que intenta "adivinar" cual ser� el pr�ximo fichero temporal
para hacer el root exploit de turno
> Creo que dices las cosas a medias y tienes en mente algunas experiencias
no, si lo he dicho a medias ha sido sin querer y porqu� veniamos de otras
conversaciones y d� por supuesto algo...
Tanto el system("clear"); como el fopen(...) son peligrosos siempre y
cuando el fichero que ejecutemos est� con setuid de root (sin� es igual de
peligroso que un usuario y un compilador, para entendernos).
> que yo no puedo adivinar. La cuesti�n es que cuando se produce una cadena
> de errores que permiten un exploit suele ocurrir que nos fijamos en el
> �ltimo eslab�n de la cadena como el responsable de todo, pero creo que
> estar�s de acuerdo en que hay que retroceder en esa cadena de fallos todo
> lo que se pueda porque cada fallo abre varias puertas y arreglando el
> �ltimo no se hace gran cosa.
bueno, en el caso de un fopen el �ltimo eslav�n creo que es el �nico que
hay, un fopen sin comprobar antes que no exista el fichero (o si existe
que no sea un enlace simb�lico)
claro que cada caso es un mundo...
hay casos m�s rebuscados, s�, etc. etc.
Hasta pronto
----
Carles Pina i Estany | Nick: Pinux / Pine / Teufeus
E-Mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.salleURL.edu/~is08139/
Compra el nuevo Windows para Desastre en Grupo.
