Question about Whonix / Tor Browser / exploits

74 views
Skip to first unread message

neilh...@gmail.com

unread,
Aug 2, 2016, 6:30:36 PM8/2/16
to qubes-users
I have a question about Whonix/Tor Browser exploits.

I have played around a bit with Metasploit to see how browser exploits work.

They basically rig a web page with exploits, and then it does what's known as "arbitrary code execution", to open up a "remote shell".

As far as I can tell.. the remote shell is running in the browser's RAM. They are essentially hi-jacking the browser's RAM, and using it to run their own remote shell.

The hacker then usually loads a file from the remote shell, onto the computer's hard drive, in order to obtain persistence... As soon as the browser tab closes, the remote shell is gone, hence why they need persistence.

So my question is about persistence.

Is it possible to simply remove the hard drive altogether from Whonix, to prevent them achieving persistence...?

I know that TAILS simply doesn't have a hard drive at all.

Would this be useful to have in Whonix..? To remove the hard drive altogether, perhaps in VM Settings in QUBES...?

Or is it possible to run a Xen exploit purely in the browser's RAM anyway...? Thus, they don't even need a hard drive because they can just run the exploit in RAM anyway...?

So the main question is really whether they can run the Xen exploit in RAM anyway.... or not.... If not, then surely removing the hard drive itself would be useful...?

Hopefully you understand my question.

Jeremy Rand

unread,
Aug 2, 2016, 11:16:40 PM8/2/16
to qubes...@googlegroups.com
neilh...@gmail.com:
It's possible to use Whonix as a DisposableVM (although it's not the
default configuration of a fresh Qubes installation), so in theory any
exploit placed in the VM will disappear when the VM is closed. This
would, presumably, mitigate persistent malware placed via Firefox
exploits, but won't help against malware that combines a Firefox exploit
with a Xen exploit. It still seems like an improvement against the
default configuration.

Cheers,
-Jeremy Rand

signature.asc

neilh...@gmail.com

unread,
Aug 3, 2016, 6:19:01 AM8/3/16
to qubes-users, jer...@veclabs.net, jerem...@airmail.cc
So you're saying that you can run an entire Xen exploit without installing anything to the hard drive at all... Just purely run it in the RAM itself.

Wow.

And what do you think about Selfrando..?

Is this going to fix browser exploits once and for all, or will it just fall to hackers..?

https://blog.torproject.org/blog/selfrando-q-and-georg-koppen

"Selfrando randomizes Tor browser code to ensure that an attacker doesn't know where the code is on your computer. This makes it much harder for someone to construct a reliable attack--and harder for them to use a flaw in your Tor Browser to de-anonymize you."

http://news.softpedia.com/news/tor-browser-integrates-tool-to-fend-off-deanonymization-exploits-505418.shtml

"While ASLR takes code and shifts the memory location in which it runs, Selfrando works by taking each code function separately and randomizing the memory address at which it runs.

If the attacker cannot predict the memory position at which pieces of code execute, then they cannot trigger memory corruption bugs that usually allow them to run rogue code inside the Tor Browser"

Jeremy Rand

unread,
Aug 3, 2016, 6:39:26 AM8/3/16
to qubes...@googlegroups.com
neilh...@gmail.com:
> So you're saying that you can run an entire Xen exploit without installing anything to the hard drive at all... Just purely run it in the RAM itself.

Well, most GNU/Linux systems have a /tmp/ partition, which acts like a
hard drive but is backed by RAM. So even if you removed the emulated
hard drive from a Xen VM, I assume the /tmp/ partition could still be
used by a hypothetical Firefox exploit much the same way that the hard
drive could.

I suppose removing the emulated hard drive might reduce the attack
surface a bit, for the specific case of vulnerabilities in Xen's hard
drive emulation code.

I'm not a Xen expert by any means. Marek or one of the other Qubes devs
would presumably be able to give a better answer than I can.

> And what do you think about Selfrando..?
>
> Is this going to fix browser exploits once and for all, or will it just fall to hackers..?

Quoting the blogpost that you quoted:

"This makes it much harder for someone to construct a reliable attack"

AFAICT No one is claiming that Selfrando will "fix browser exploits once
and for all", but they are claiming that, if it works as intended, it
should increase the cost of attacks significantly.

Defense in depth is a useful approach. Hence why it might make sense to
use Xen, AppArmor, and Selfrando together, so that if a subset of them
fail, you may still survive.

Cheers,
-Jeremy

signature.asc
Reply all
Reply to author
Forward
0 new messages