¿Deben los programas verificar los enlaces simbólicos antes de crear archivos?

Question

¿Deben los programas verificar los enlaces simbólicos antes de crear archivos?

#1 de 40F4 (1 votos)
#2 de Serge Ballesta (1 votos)

2

Recibimos un informe de error (expresado como un problema de seguridad) para un programa, que establecía que cuando el programa crea archivos en el disco, no verifica primero si existe un enlace simbólico en la ruta del archivo que se creará. Debido a eso, un atacante puede crear un enlace simbólico, que el programa (cuando lo ejecuta otro usuario) puede intentar sobrescribir, sobrescribiendo así un archivo al que el atacante no podría tener acceso de escritura.

Para ilustrar, aquí hay un ejemplo con gcc, que también es "vulnerable" a este problema:

Eve envía a Alice un archivo .tar.gz que contiene un programa en C. Dentro del archivo está evil.c , y a.out , que es un enlace simbólico a /home/alice/.xinitrc .
Bajo algún pretexto, Eve le pide a Alice que compile el programa (y no haga nada más).
Eve ejecuta gcc evil.c , que por sí solo debería ser seguro (salvo el desbordamiento del búfer, etc. en el compilador).
gcc (técnicamente el enlazador) intentará escribir el binario resultante en a.out , por lo que se sobrescribirá el .xinitrc de Alice.
La próxima vez que Alice inicie su servidor X, se ejecutará el código de Eve.

En nuestro caso, la situación es muy parecida a gcc: el programa crea archivos solo en el directorio actual (a menos que se indique lo contrario), con nombres predecibles, y no ejecuta ningún código desde su entrada.

¿Es esto algo por lo que los programas como los compiladores deben preocuparse?

compiler symlink

pregunta Vladimir Panteleev 08.07.2017 - 00:26

fuente

2 respuestas

Lea otras preguntas en las etiquetas compiler symlink

¿Cómo puedo hacer un seguimiento de si un pdf se abrió o no? Cómo auditar un sistema de correo electrónico

score 1 · Answer 1

Sí, los programas deben prestar atención a los enlaces simbólicos si los programas leen o escriben archivos desde / a directorios donde los usuarios con privilegios más bajos pueden crear enlaces simbólicos. De lo contrario, es posible que un usuario pueda leer o escribir en archivos que deberían estar protegidos.

Pero debes evitar un cheque como if(!issymlink(path)) { writeto(path) } porque eso sería propenso a una condición de carrera. En lugar de Linux, por ejemplo, puede usar el indicador O_NOFOLLOW para open para que falle con un error si la ruta apunta a un enlace simbólico.

score 1 · Answer 2

Eso es un problema de programación general. De hecho, debería preguntarse si desea anular todos los enlaces al archivo cuando está vinculado de forma múltiple. El informe de errores solo hace referencia a enlaces simbólicos, pero podría existir un problema equivalente con enlaces duros:

el usuario A usa el programa para generar (y sobrescribir si existe) un archivo en la carpeta F (por ejemplo, /F/app_file )
el usuario A tiene acceso de escritura a la carpeta G
el usuario B tiene acceso de escritura a la carpeta F pero no a la carpeta G
el usuario B vincula un archivo de la carpeta G a la carpeta F ( ln /G/file /F/app_file )
el usuario A ejecuta el programa y sobrescribe el archivo en la carpeta G

Ni siquiera está estrictamente relacionado con Unix, ya que Windows también admite enlaces y uniones (como dijiste en el comentario).

La forma común de evitar ese problema es tratar de desvincular el archivo antes de escribirlo (asumiendo el lenguaje C):

remove(filepath);                  // unlink the file if it was previously multiply linked
FILE *fd = fopen(filepath, "w");   // will not overwrite any file other than filepath