Il 2015-09-11 12:52 Igor Falcomata' ha scritto:
> On Fri, Sep 11, 2015 at 09:57:51AM +0200, Robert Newmark wrote:
>
>> e non vale lo stesso per quella password? nel senso, se hai avuto
>> codice
>> arbitrario, magari non ti intercetto la password, ma ti intercetto
>> tutto
>> quel che fai con quella password.
>
> Si' ovvio, ma *non* accedi[1] in ssh, ai miei sistemi e non hai le
> password di luks o le password di gpg/vpn/ballevarie importanti.
>
tutto dipende dal threat model che si prova a risolvere, di questi molti
sono mitigati, altri meno..
per esempio, se hai una macchina compromessa, non hai un grosso
vantaggio nello scrivere le pwd in terminale anziche' in X (perche'
anche le pwd ssh/gpg/vpn dopo averle usate restano nella mem della
shell, puoi confermarlo se provi a dumpare la mem di bash e greppare la
tua pwd in chiaro...), stessa cosa vale per luks, non hai la pwd in
memoria, ma la key gia' stretchata (che brutto termine). anche se luks
usa AF-split, con un plugin di volatility la riesci a tirare fuori.
molto carino e' il nuovo gpg-agent, che puoi usare anche con ssh, ma
anche qui hai problemi similari :)
> Che poi tu veda che sto guardando youporn, editando riservatissimo.odt
> o
> sia in ssh su una shell di antani o addirittura tu possa iniettare un
> comando arbitrario, e' una possibilita', ma nel mio contesto questo
> rischio e' accettabile (in confronto alla scomodita' di non usare X, e
> sempre calcolando che di base, se stai eseguendo codice abitrario sulla
> mia macchina, e' gia molto male e sono gia' molto nella merda).
>
> Btw, tutta la roba anche vagamente pericolosa gira in una VM, senza
> supporto per lo scambio di clipboard, per cui devi prima fare VM->host
> o
> almeno VM->Xorg, e sono un dei pochi idioti che usa grsecurity anche
> sul
> desktop, oltre ad altro hardening vario (tra cui non usare consolekit e
> dbus da root e tutte le altre balle che permettono escalation a root
> che
> non sia via su/sudo).
>
non per essere catastrofico, ma anche le VM possono dare false speranze.
basta guardare alle ultime vuln su qemu/vmware che permettono di fare vm
evasion.
altra cosa da tener conto e' che qubes OS funziona in modo completamente
differente, per esempio, dall'usare il browser nella vm, soprattutto se
il proprio hw ha anche il supporto a vt-d..
per quanto riguarda le clipboard c'e' questo
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt
anche se e' un attacco molto teorico, ma per ora c'e'..
penso che una soluzione decente sia whoonix(con grsec) + qubes
ma il problema resta: se la macchina e' compromessa, attualmente, c'e'
poco da fare, se non rendere la vita dell'attacker molto complicata :)
windows 10 ha introdotto una cosa che sembra essere molto interessante,
https://adsecurity.org/?p=1535 , una sorta di lsass che gira dentro
hyperv.. Ma, forse, bisogna attendere il supporto di intel con SGX (
https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2015/january/intel-software-guard-extensions-sgx-a-researchers-primer/
) per avere tutta sta roba implementata col supporto hw (poi bisogna
sempre fidarsi dell'hw.. :)
ciao
