[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gets() en Lenguaje C.




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: carles.pina@salleURL.edu / is08139@salleURL.edu / cpina@cat-linux.com
http://www.salleURL.edu/~is08139/

   Compra el nuevo Windows para Desastre en Grupo.



Reply to: