'exploit basato su rsync -K'

Question

'exploit basato su rsync -K'

#1 da (4 voti)
#2 da (4 voti)

6

Nella descrizione del flag -K ( --keep-dirlinks ), la pagina man di rsync fornisce questo avviso (il mio accento):

One note of caution: if you use --keep-dirlinks, you must trust all the symlinks in the copy! If it is possible for an untrusted user to create their own symlink to any directory, the user could then (on a subsequent copy) replace the symlink with a real directory and affect the content of whatever directory the symlink references. For backup copies, you are better off using something like a bind mount instead of a symlink to modify your receiving hierarchy.

Ho letto la frase evidenziata più volte e non riesco ancora a visualizzare l'exploit a cui si riferisce.

Qualcuno potrebbe dare un esempio dettagliato dell'exploit? (Si prega di includere una spiegazione di come un "bind mount" evita il problema.)

FWIW, questa è la mia comprensione di cosa fa l'opzione -K .

Ad esempio, se lo stato iniziale è questo:

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

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

Quindi, dopo rsync sender:/path/to/sourcedir/ receiver:/path/to/targetdir , il destinatario sarà simile a questo:

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

(nota che foo non è più un link simbolico.)

Dopo rsync -K sender:/path/to/sourcedir/ receiver:/path/to/targetdir , d'altra parte, assomiglierà a questo:

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

linux unix file-system

posta kjo 15.03.2017 - 00:23

fonte

2 risposte

Leggi altre domande sui tag linux unix file-system

Ho bisogno di un nuovo CSR per un rinnovo del certificato? È sicuro memorizzare un seed di autenticazione a due fattori in un gestore di password?

score 4 · Answer 1

Sei corretto sull'uso dell'opzione -K . Ma l'exploit riguarda il fatto che utenti diversi eseguono la creazione di link e corrono rsync . Vediamo prima alcuni rsync -K in azione. Crea alcune istruzioni di test:

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

Ed esegui il semplice 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

Puliamo c prima di un nuovo test:

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

Ora, immagina che io dia ad alcuni altri utenti i diritti di scrivere in c/to e b/from . Per semplificare le cose, diciamo che il seguente chgrp consentirà a un gruppo di persone di scrivere lì:

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

E uno studente intelligente esegue questo:

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

Il mattino dopo eseguo rsync e:

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

Ahi! Il mio file all'interno di a che non ho mai dato il permesso a chiunque di modificare è cambiato:

[me] $ cat a/bar
1337

E, dato che rsync è comunemente usato per attività ripetitive come i lavori di cron, ci sono buone probabilità che ciò non accada nemmeno inosservato.

In parole semplici si può affermare che l'exploit è che: un utente che ha accesso ai lati mittente (da) e destinatario (a) di un lavoro rsync ricorrente acquisisce i privilegi dell'utente che esegue il lavoro rsync.

Non eseguire rsync -K come root!

score 4 · Answer 2

Ecco un possibile attacco. Inizia con questo sul mittente:

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

Esegui rsync una volta e ottieni questo:

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

Adesso cambia il mittente per avere questo:

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

Ora quando rsync viene eseguito di nuovo, / etc / passwd verrà sovrascritto sul ricevitore.

Bind mounts previene questo attacco perché rsync scriverà sempre attraverso di loro ma non li creerà mai.