Hay muchos m�s ejemplos de lo que mencionas, y no s�lo con system(). En
Perl (y yo s�lo puedo hablar de Perl, pues es el �nico lenguaje con el que
estoy a gusto), si usas el modo 'Tainted', entre otras muchas
restricciones te impide usar cualquier valor adquirido de afuera y, por
tanto, potencialmente da�ino en cualquier interacci�n con el sistema,
antes de que le des una buena "cepillada". Claro est�, cualquier llamada
al sistema est� dentro de lo restringido.
En el caso espec�fico de system... �Qu� pasa si corres un comando sin
especificar el path completo? La variable PATH de tu ambiente peude tener
alg�n directorio indeseado. �Y qu� pasa si redefines el IFS para que tome
a alguna otra cosa en vez del espacio como separador? O... Bueno, �para
qu� seguir enumerando?
Esto lleva a una discusi�n parecida a strcat vs. strncat y similares -
Cito un poquito del manual:
char *strcat(char *dest, const char *src);
char *strncat(char *dest, const char *src, size_t n);
DESCRIPTION
The strcat() function appends the src string to the dest
string overwriting the `\0' character at the end of dest,
and then adds a terminating `\0' character. The strings
may not overlap, and the dest string must have enough
space for the result.
The strncat() function is similar, except that only the
first n characters of src are appended to dest.
strcat puede ser m�s corta al escribir, e inclusive al ser una funci�n m�s
simple, ser un poco m�s r�pida de ejecutar. Sin embargo, strcat se presta
muy feo a los buffer overflows, en tanto que strncat te permite evitarlos.
Va lo mismo para las variables de entorno - Puede no ser da�ino que uses
system() sin ajustar el entorno... Pero mejor camina por el lado tranquilo
y no te arriesgues.
Saludos,
> > > par de errores gordos de concepto en cuanto a seguridad ( el usar
> > > system() sin ajustar el entorno, por ejemplo ), pero por lo menos hace
> >
> > Eso no lo entiendo. A que te refieres con ajustar el entorno ?
> > En el man de system() lo �nico que veo sobre esto es:
> >
> > No llame a system() desde un programa con privilegios suid o sgid,
> > porque pudiera ser que se emplearan valores extra�os para
> > algunas variables de entorno para comprometer la integridad del
> > sistema.
> > Yo creo que cuando system llama a un programa normal sin privilegios
> > no deber�a haber problemas a no ser que exista la posibilidad de salir
> > a la shell como es el caso de un mont�n de comandos de tipo interactivo.
>
> En los tiempos de maricasta�a hab�a un bug famoso del telnetd que hac�a
> que se invocase a una shell desde �ste. Daba la casualidad de que
> telnetd corre como setuid root.... El truco consist�a en aprovechar que
> se utilizaba una llamada a un programa que tomaba como par�metros
> valores de las variables de entorno... algo as� "ARGS=hola;/bin/bash"
>
> El telnetd, obediente, llamaba a su programita...( totalmente seguro y a
> prueba de hackers)... y acto seguido lanzaba una shell :)
>
> Normalmente, en lugar de system(), en entornos seguros se utilizan las
> funciones execvp() y familia, donde le puedes pasar como par�metro un
> puntero a la lista de variables de entorno, que TU has previamente
> definido. La verdad es que nadie deber�a utilizar system() en entornos
> "criticos"
>
> No hace falta que el programa al que llamas sea "seguro". El problema
> reside en meter en la l�nea de comandos datos de las variables de
> entorno que puedan haber sido editados por alguien ajeno a t�. El
> ejemplo del telnetd deber�a ser suficientemente elocuente
>
>
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-1118
