Re: system() y variables de entorno

[Gunnar Wolf <gwolf@campus.iztacala.unam.mx>]

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 - gwolf@campus.iztacala.unam.mx - (+52-55)5623-1118