>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)
>- ...
If you have a single intrusion on tor you can almost expect anything
further that you experience on the TOR ring to be tainted, and
horrible to trust. This is why I worry about every single issue even
something that may not be persistent. I wasn't looking at porn,
lol... funny enough I wouldn't care to TOR that since I am not in an
Arab state...
I was creating an anonymous e-mail address, and just using tor-browser
for queries such as: dark web search engine. I had 4 tabs open that I
had opened during my last session. I wasn't browsing any ridiculously
'shady' sites. I am assuming this was happening due to an exit node.
I understand the risks, and mathematical probabilities of the
circuits.. This is much more alarming to me than what you
considered... I hope you feel the same..
It wasn't anything regarding CPU. It was definitely a bug, or
accident that triggered it. More than likely a bug... I don't really
know since I wasn't instrumenting the entire system.. Its still very
important IMO to mitigate every attack, or at least ensure it cannot
cause harm beyond a crash. I wouldve considered TOR secure until this
breach happened so randomly whenever I had not been using it for
long.. (15 minutes)
I am just doing some dark net research. I can't imagine having these
issues if I were someone who really depended on the anonymous nature
expected. I am just creating a thread hoping to help someone who may
be in that position where their livelihood may depend on it.
>>* 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.
If you fake the VERSION of the browser itself is sometimes enough to
mitigate exploits from even being pushed to the user by their
attacker. Every exploit it that I have come across has used
javascript, or user agents to designate which exploit+payload to
deliver. I didn't mean going as far as breaking it from having
compliance with HTML/JS. I just meant claiming a different
architecture on a browser that is usually compiled for both. It
should in theory hold all of the same results visually to the end
user.
.
I didn't recognize about ARM being threadsafe.. -- I'll perform some
testing. I'm getting a Vagrant session up for building Tails so that
I can test a few things that may help overall in the long run. It is
an example, and I recognize the effort the CPU requires for
translation. I just firmly believe that if this happened to me so
suddenly on my second day and 15 minutes into a SIMPLE session
(repeating a lot of the first session) then I believe it could be a
major problem for others that do not understand the results of the
attacks..
>>* 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.
The QEMU method of checking for an alternative architectures opcodes
is just a simple way to determine if someone, or something has taken
control of the execution flow.. or loaded a plugin that was compiled
for the wrong architecture. It would definitely not be the priority
of my suggestion..
QubeOS creates various separate hypervisors.. I'm talking about doing
some simple 'truth table,' or opcode verification checks during
execution to determine if there are opcodes from another architecture
being fed into the CPUs execution stack... Lets forget this for now...
Its more important to mitigate the results of an attack than to
'detect for sure' it happening..
>>* 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.
You may be correct. I will perform some tests using various setups
and determine if it works decently on my machine. I thought QEMU
might be a decent option due to its block execution, and caching. I
could be confusing it with another emulation engine from a prior
project. I hope to give some more information in the near future. My
Vagrant/test bed is almost ready to try some things out... I consider
TOR in general to be pretty slow so I wouldn't personally mind the
browsing being a little slower. It may also be possible to use QEMU
to execute portions of firefox in one process which is ARM that may
handle some execution without a full 'QubeOS' and 'proxy' to another
process for the architecture to handle the graphics parts such as X11.
This solution would only require some GOT redirecting, and LD
library injection via PATH. I know it may seem unstable now but its
practically how chrome has been executing for years.. It could be
handled in an automated way requiring no modification to firefox
binaries ahead of time.
I will definitely need to research it a bit further. I try to
approach exploits to mitigate the entire class.. I've never considered
tor until that crash. It is something I installed solely to reach
Dark Net sites. I'd have more than likely never spoke about Tails
until this had happened...
I have another suggestion regarding Tor in general which I hope to
present after I determine if this solution, or something similar is
plausible for the browser bugs. It could help prevent a lot of
traffic analysis that I assume has taken place by the University (from
a prior news article)..
Thanks for the response! I'll see how the test go, and I'll also
verify on some slower machines since I am on a MBP. I am not sure of
the usual statistics of computers that Tails is being executed on
worldwide... The speed may be a factor...
- Mike
