Mike,
good idea to hide the target ...
> I've only used Tails a handful of times. I had my browser crash while
> researching a bit ago, and I'm assuming it was from an exploit. Firefox is
> full of holes,
If you boot tails from a cd and if you do not use persistence, an
exploit from a "bad" website can't never ever overlast a tails session
or a reboot, so the exploit must happen again and again with the first
visit of a "bad" site. Additonally the tor browser allows you to switch
off javascript completely for all sites which is the most safest (but
not most funny) sex on the internet.
If your browser still crashes while researching - probabely a good idea
to take a closer look on the hardware:
- does the cpu is overheating? If you run the tor browser, additionally
tor connections (onion circuits) are calculated, quite high cpu load
oberservable.
- check the ram load (system monitor)
- ...
>
> I just wanted to give a suggestion. It may be a good idea to use various
> versions of firefox binaries for different architectures. You could even
> manipulate the user agent, and javascript results for the current
> architecture, and OS. It would work fine choosing these at random with
> QEMU userland emulation engines.
Does it improve the browser or fix bugs/holes? If you fake the user
agent the behaviour of the site may be different, i.e. if you fake a
mozilla to appear as an IE some sites behave quite strange - as IE's
HTML 5 support is quite strange and the rendering is different from the
gecko engine. Additionally QEMU's arm emulation isn't yet really
threadsave see
http://wiki.qemu.org/Features/tcg-multithread.
As CubeOS does, it would be better to isolate buggy or weak
applications. Within Debian this could be done similar with LXC (or
docker) containers.
All in all - the more tools you use the more complex and vulnerable will
be your system.
> Pros:
> It would defeat all current exploits or at least require injecting all
> platforms which would allow heavy users, or automated systems to detect
> them easier. It may even be feasible to insert an opcode detection engine
> in QEMU directly that may detect x86 code on ARM, and vice-versa.
What means, first to enhance QEMU. In general (without ARM and QEMU)
this is - as far as I understood - the idea of the QubeOS.
>
> Cons:
> A bit slower, but we are already dealing with TOR traffic which may not
> even show a major difference while converting from one architecture to
> another
> size -- you would have to include various architecture binaries
My experiences are not a "bit" slower, rather "very" slower: If you
emulate ARM on a non-arm platform (i.e intel) there's no way of hardware
supported emulation, so QEMU (KVM) must soft emulate, which is very very
very slow. Other hypervisors like virtualbox or vmware or xen do not
emulate cross platforms, KVM (QEMU) is as far as I know the only one.
--
Best Regards!
n9iu7pk
PGP 0x4D12FFCB 7426 4598 B5AD 4D12 1699 C710 D602 E331 4D12 FFCB
