I understand that the safest way to use torbrowser is to disable javascipt completely, but there are a lot of websites that can’t be used without javascript and I turn it on every time.
I don’t understand how dangerous it is to enable javascript, so I don’t know what I’m doing is right.
Could you tell me the dangers of javascipt?
When do you enable javascript?
Pretty dangerous. Since it is turing complete it enables an attacker to run arbitrary code on your machine if there is a security hole in the interpreter (which is a common occurrence).
On a Linux machine, the browser is the biggest gaping security hole you can have.
2 Likes
I’m getting scared of using javascript. The security level of Torbrowser should always be set to Highest and javascript should never be used.
Thank you for telling me.
1 Like
It depends on your threat model.
JavaScript de-anonymization exploits are rare (and can’t even be done on Whonix) and historically, have only ever been known to be used on pedophiles.
“a security hole” does not mean “giant gaping hole resulting in sandbox bypass and RCE”.
1 Like
Much more common than when it is not involved. While it would work on a vulnerable Tor Browser in Whonix, a further total compromise would need exploit chaining to break out of the hypervisor.
Exploits are used with a variety of intentions and to target people sometimes indiscriminately. So assuming one is not doing XYZ and therefore safe is a false sense of security.
Who knows what other hardware level bugs are out there? JS exploits are definitely a bridgehead on people’s machines that open the door to more powerful attacks.
2 Likes
People won’t waste highly valuable exploits on some random person. The likelihood of the FBI or something using thousand dollar exploits on you for no reason is extremely low.
I’m not denying that JS can be dangerous but calling RCE exploits common is untrue.
1 Like
iphone exploits are the most highly valued in the industry carrying a price tag of millions. However recently discovered mass attacks by China disprove the commonly held idea that such attacks are rare because of the reasoning you mention.
https://www.schneier.com/blog/archives/2019/09/massive_iphone_.html
In the case of freedom hosting, the Feds were slinging exploits at everybody even those who unwittingly used services that had nothing to do with the illegal ones.
There are plenty of plates on the FF bug buffet other than RCEs.
Blocking JS handles most if history is an indicator.
1 Like
Apple disputed that and claimed it was actually “narrow focused”.
First, the sophisticated attack was narrowly focused, not a broad-based exploit of iPhones “en masse” as described. The attack affected fewer than a dozen websites that focus on content related to the Uighur community. Regardless of the scale of the attack, we take the safety and security of all users extremely seriously.
A message about iOS security - Apple
Because they can’t tell the difference between innocents and pedophiles by just seeing them connect to the website. If they could, that’d probably be even more concerning.
Also, people who were affected by that attack were using outdated versions of TBB. The vulnerability was patched a month before it was exploited.
So stay updated. Mozilla will likely fix these pretty quickly once they are found.
There is also a major difference between a vulnerability being found and it being actively exploited.
1 Like
For javascript it is most prudent (in my informed opinion) to leave it disabled as much as you can. If you can leave it disabled all the time even better.
As far as exploits there are probably some that exist right now that we are not aware of yet.
Can we trust Mozilla or Tor to disclose security issues to the public right away and not alert various governement entities first? To answer that I would need to see where all their funding comes from. It would be shortsighted to take them on their word–not because they are necessarily hiding something, but because it is always better to be over-cautious instead of too lax.
Apart from that, I try to err on the side of caution. Keep js disabled and use common sense while using the internet. Have a secure system, update it and be proactive. Thats the best we can do. Joining the mailing list can help to keep informed too
2 Likes
I think what you say makes sense.
I also disabled javascipt as much as possible and turned it on only when necessary.
By the way, before I allowed javascript, I first checked the website with libreJS. If the website would work with libreJS, I would be relieved. If not, I would have enabled javascript at risk.
Is it a bad idea to use libreJS to check the safety of javascript?
2 Likes
JS assisted deanonimization or at least efficient fingerprinting can occur even without any RCE exploits / zero days, within a fully patched and updated system, even in Whonix, through correlation attacks.
Example: a 3rd party JS script by google or facebook (very very common) running in different tabs of a JS enabled Torbrowser, or even at different times (fingerprinting still good) or in different VMs, or in a VM and on the host (clearnet) in parallel, or in a VM and on any other device, clearnet, using the same access point in parallel (at least the latter would be, I believe, very hard to completely eliminate).
Yes the above paragraph did not make a distinction between “mere” fingerprinting and full IP discovery. One can lead to another so the line isn’t very clear to draw.
I’d say block JS by default.
When it’s absolutely neccessary for the site to function, enable only required scripts and continue blocking 3rd party scripts.
If the 3rd party scripts are also neccessary, be aware of the increased risk you’re taking.
2 Likes
I agree. I always leave javascript disabled. I just don’t think disabling it is necessary for most threat models. If javascript is part of your threat model then go ahead and disable it.
The javascript being proprietary or not isn’t a good indicator of whether it’s malicious or not.
Most people don’t have those advanced de-anonymization attacks or fingerprinting as part of their threat models. That’s the point I’m trying to make. Not that javascript is all fine and dandy.
TBB mitigates most fingerprinting attempts anyway.
Also, disabling javascript isn’t a simple catch all solution to avoiding fingerprinting. Fingerprinting can even be done with just CSS.
2 Likes
this. literally every user of “tormail” at the time with a vulnerable tor browser with javascript enabled was compromised. at the time, as i recall, updating the tor browser was not as straight forward as it is now.
the trade offs between enabling and disabling javascript, or selectively enabling it, have been described and debated multiple times. if a potential loss of greater anonymity per session is not a concern to you, disabling javascript by default and enabling it temporarily for the sites you need per session will potentially protect you better from driveby malware that relies on a javascript browser exploit. however, it will potentially give you a unique fingerprint per session.
4 Likes
The license of the code/JS scripts != safe not malicious, just that you can inspect, copy and modify it.
3 Likes
I didn’t refer to most people’s threat model but to those with higher needs. Those who appreciate concepts such as stream isolation and other goodies. I thought that’s kind of obvious when correlation attacks are mentioned. The question is “How dangerous is javascript” and my answer gives some examples. Further, the notion one’s assumption regarding their actual threat model is indeed correct sounds to me like baseless wishful thinking more than anything else. I’d bet most people are too careless than too paranoid.
“dangerous” is indeed a wide term though. Better discuss issues of “security”, “anonymity” and “privacy” more specifically.
That is indeed very true and receives less attention than it deserves.
1 Like
the correct answer is simply this. proper risk management involves preparing for the worst case scenario, regardless of how unlikely it is. think about your risk exposure, and play it from there. if you need to be hyper paranoid, whonix alone won’t help you anyways. you’ll need to find physical isolation means that create a true dead end if you are exploitable. for example, an entry point that you’ve used once, is not attached to you, and is nowhere predictable to your home. is that a pain? yes. is it needed for most? no. but, a number of quite skilled people have been ensnared by someone because they ignored or forgot this.
1 Like
Maybe worth mentioning, to mitigate the fingerprinting problem somewhat you can also use different VMs, or different TB instances on the same machine, at different security levels simultaneously. The latter is not recommended by the Tor developers, but I’ve never been able to figure out why exactly.
What tempest was taking about was the per site whitelisting feature of NoScript not the security slider levels.
TPO decided its safest to hide the NoScript icon altogether in the latest releases.
Yeah, I meant using separate VMs or instances for per-site js blocking instead of using NoScript’s per-site features. That way you get similar per-site control, but without making you more fingerprintable. If you have the resources, probably the best thing to do is open a new instance/VM for every site* and set the security slider to the level you feel comfortable with for that site. It also limits your trackability across different sites or identities, as TB doesn’t attempt to isolate activities within the same instance until you restart it. I normally have 2-4 instances open at any given time, sometimes more.
*Not necessarily for every single domain, but for each group of related tabs, or logical compartment if you will.