On Mon, 23 Dec 2013, boyska wrote:
> On 23/12/2013 09:54, mrmacete wrote:
> > On 12/23/2013 02:35 AM, gin(e) wrote:
> >> http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/
> >
> >> sudo cryptsetup luksDump /dev/sticazzi |grep '^Cipher mode:'
> >
> >
> > ah! e tomb?
>
> tomb usa cbc, infatti. :S
> lo facevamo per retrocompatibilita' con kernel non nuovissimi; direi
> che e' ora di switchare a xts
si era una cosa da fare gia' da un po' il cambio di quel default.
l'attacco mi pare riesca a fare una sorta di "code injection":
" ... this does allow injecting more or less arbitrary shellcode to an
executable file by dividing the shellcode to small chunks and adding JMP
instructions to jump over the garbage blocks. "
Per manipolare il volume crittografato, dopo la sua manomissione il
proprietario delle chiavi dovrebbe aprire la tomba e provocare
l'esecuzione di almeno un eseguibile. nel caso di Tomb non so se
potrebbe venire aggiunto shellcode allo script di post-hook o serve un
ELF (qualcuno riesce a capirlo dal paper?)
ad ogni modo questo attacco non rende vulnerabili le tombe su harddisk
sequestrati o rubati ammenocche' il proprietario non venga portato ad
aprirle di nuovo dopo averle manomesse. e' un attacco utile su computer
lasciati in mano solo temporaneamente agli attaccanti e con accesso
root. Ma in tal caso l'attaccante troverebbe molto piu' semplice
rootkittare l'interprete zsh che usare questo attacco...
Comunque ok, prepariamoci a fare una nuova release di tomb.
nel frattempo e' possibile creare nuove tombe aggiungendo un'opzione al
lock che le rendera XTS:
tomb lock -o aes-xts-plain64:sha256 ...
funziona gia' con l'ultima versione
ciao
p.s. quanto vorrei fosse tanto eccitante quanto l'attacco recentemente
pubblicato contro gpg, ma non lo e'. cmq grazie della segnalazione
