🚀 go-pugleaf

Hola, Alex:

Alex Estevez escribi� en es.comp.os.linux.programacion:

>>>  #chmod 6755 myscript.sh
>> scripts.  En definitiva, contra lo que pone el libro, un script no se
>> ejecuta en modo SUID.
>> * El m�todo desacoplado: hacer lo que te dije en mi primer mensaje. 
>> Puede Si se trata �nicamente de esta cosa puntual mi consejo es que lo
>> m�s seguro es seguir la tercera opci�n.
> 
> Bien. ahora veamos porque planteandomelo me encuentro con que el
> problema de seguridad sigue ahi.
> 
> Supongamos lo siguiente: un formulario pide un nombre de usuario y
> password en php.
> 
> El proceso es meter eso en un archivo. luego un programa lanzado por
> cron lo leera.
> 
> Supongamos que el php mira que no se hallan puesto barbaridades. Genero
> el archivo. y el programa de cron lee el archivo y crea el usuario.
> 
> No veo la diferencia de peligro.
> 

Redundancia.  Por supuesto, puedes hacerlo mal en un sitio, en dos o en diez
mil.  Sin embargo, con dos sitios te tiene que coincidir "la llave" (llamo
as� a los sistemas en cascada porque les ocurre lo mismo que a una llave
Yale: para que se abra la puerta, la muesca del diente tiene que coincidir
con la salida del pist�n.  Esto se revienta con toda facilidad; sin
embargo, una llave Yale tiene un mont�n de dientes y la �nica manera de
abrir la cerradura es que coincidan *todos* en su posici�n correcta, lo que
no s�lo es t�cnicamente m�s dif�cil, sino que aumenta la seguridad te�rica
del sistema, dado el dise�o).

En tu programa, ciertamente se puede tratar de forzar alg�n car�cter
escapado en la parte web, y t� tratar�s de evitarlo, tratando toda la
variable pasada.  Para ello deber�as limitar el tama�o m�ximo de variable
pasado y sanear los caracteres admitidos.  Estas variables saneadas se
pasar�n, una por l�nea a un fichero temporal.  No hay variables que se
pasen tal cual y aun en caso de problemas, el usuario afecto ser� aquel con
el que corra apache (en tu caso nobody) en lugar de root.  Adem�s, ten en
cuenta que esta parte ni siquiera tendr� llamadas al sistema (no hace falta
una llamada a 'system' o similar puesto que no ejecutas nada: simplemente
abres un descriptor de fichero y escribes en �l).

Posteriormente, el script de tratamiento ya no trabajar� con toda la
entrada, sino s�lo con aquello que es esperable: si son dos variables, ni
siquiera intentar� leer la tercera l�nea que pudiera haber (hay que
programar con esto en la cabeza: no se abre un descriptor de fichero y se
recorre con un bucle while, sino con un bucle for -s�lo las l�neas uno y
dos-); en cada l�nea no tratar� de filtrar lo que de malo pueda haber, sino
que s�lo aceptar� el primer segmento de caracteres v�lidos de la l�nea,
car�cter por caracter, hasta el m�ximo adecuado.  Aqu� tienes "la llave":
dos estrategias distintas, en dos pasos distintos, ejecutados por dos
usuarios distintos.  NO supone los mismos riesgos (aunque en teor�a y a
primera vista parezca que s�) que hacerlo todo en un golpe.

> Ejemplicemos :) imaginemos que se burla el "comprobador de usuario"
> 
> Proceso inseguro:
> 
> usuario: pepe ; rm -rf * >/dev/null;
> password: adios
> 
> php lee los parametros y hace
> 
> <?
>   system ("programilla $_POST['usr'] $_POST['pwd']");
> ?>
> 
> me petaron el sistema.
> 

...como nobody, que es quien est� ejecutando el servidor web, lo que ya no
es lo mismo que este "pete" afectando a root.

> en cambio si hago en el php
> 
> <?
> # se supone que escribiria el archivo correctamente:
> # hago un system echo para ir rapido.
> 
>   system ("echo \" $_POST['usr']:$_POST['pwd']\" >> archivo");
> ?>
> 

�Y qui�n te dice que hagas una llamada a system?  Precisamente de lo que se
trata es de evitarla.  Tratas en la medida de lo posible de sanear la
entrada, abres un descriptor de fichero y escribes en �l.
> 
> y luego desde cron un script comprueba el archivo y lanza
>   #programilla $campouserdelarchivo $campopwddelarchivo
> 
> 
> No pasaria exactamente lo mismo?
> 

Si en tu script utilizases la misma estrategia de saneamiento, s�; al no
utilizarla, es m�s dif�cil (exponencialmente m�s dif�cil) cometer el error. 
De hecho, si se tratase de algo realmente cr�tico, la p�gina PHP y el
script cron deber�an escribirlos diferentes desarrolladores, por supuesto,
sin tener ning�n prejuicio sobre lo que el otro a hecho o ha podido hacer
para sanear los datos: a todos los efectos, se puede esperar en la entrada
de datos cualquier enga�o del maligno.

> Ademas necesitaria que se ejecutara como cada minuto y ... lo encuentro
> poco elegante.
> 

Si es tan poco elegante �por qu� permite cron ejecutar tareas cada minuto? 
(Adem�s �tantos usuarios vas a crear que no se puede esperar diez minutos,
incluso una hora para obtener el resultado?).
-- 
SALUD,
Jes�s
***
jesus_navarro@undominio.net
***