Opened 6 years ago

Last modified 3 years ago

#13873 new enhancement

hard lock tails/torbrowser

Reported by: ioerror Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: security, usability, fuzzing
Cc: gk, DqZYF Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


I was looking at some of the fantastic fuzzing research from lcamtuf and I made the mistake of looking at the autogenerated test cases:

It locked my machine (on Tails) because the browser began to consume every possible resource. I would consider this a Tails issue as the load was around ~20 after a minute or three but not Tails alone. On the one hand, I think Tails should probably compartmentalize the browser and set reasonable rlimits. On the other hand, why doesn't Tor Browser do that? The fact that the entire machine locked up is clearly a Tails-doesn't-confine-the-browser very-well. The fact that Tor Browser can do that is clearly a Tor Browser doesn't set limits issue. I don't think this is just a matter of "not sandboxing" but rather this is a matter of trying to use every bit of juice a machine has available.

How could we do this on a sane platform? In an ideal world, we can load any page and it should not lock the machine. In an ideal world, we could load any page and it shouldn't even lock the browser for other tabs. The latter is obviously something that comes with sandboxing but only if the whole machine isn't thrashing, right?

Anyway, we may also want to use lcamtuf's awesome fuzzing work to crash Tor Browser in interesting ways.

Child Tickets

Change History (5)

comment:1 Changed 6 years ago by ioerror

I found that the most minimal solution that didn't hang my box when loading that link was simply to run Tor Browser and then run cpulimit like so:

cpulimit -e firefox -l 70

It would also be nice to have a memory limit. Both of these would be reasonable sandbox like features, I suppose. If we already have them, I think they're not working for me. If we don't already have them, how might we get them? Is this a part of the overall sandboxing plan by Mozilla?

comment:2 Changed 6 years ago by gk

Cc: gk added

This might as well help us with lol.svg-style DOS-attacks.

comment:3 Changed 4 years ago by cypherpunks

Severity: Normal

It's not really up to the browser to set resource limits. My computer has 64 GiB of memory, and I often have a *lot* of tabs open. I also have a small laptop with 2 GiB of memory, and the browser easily crashes if I open a particularly large webpage that lists an index of enough thousand files. What would save my tiny laptop from an unfortunate crash would severely limit my high-end workstation and prevent me from using it to its full potential.

Setting resource limits is up to the operating system. If you want to set the limits, you set them before opening the browser. I agree, Tails should probably set rlimits, and I've been considering opening a bug report for them to do so for more than a year now for both the browser and other programs (but I've been lazy).

The only type of limits Firefox should set are stack limits, since that has a security benefit and there's a point when no matter how many tabs you open, you won't increase the size of the stack, and process limits, because Firefox won't just spawn infinite processes as you increase your number of tabs. But limiting the memory (address limits) is just asking for trouble.

comment:4 Changed 4 years ago by gk

Cc: DqZYF added

Resolved #21232 as duplicate.

comment:5 Changed 3 years ago by cypherpunks

There are a million and one ways to DoS a browser. Fixing them all is likely out of scope (and Mozilla hasn't even started considering it as a serious issue). Even excluding various types of "bombs" like SVG bombs or XML bombs, merely loading a huge page is sufficient to crash a browser. This is far beyond the abilities of Tor Project.

Note: See TracTickets for help on using tickets.