>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
_______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
