Opened 2 years ago

Closed 11 months ago

#20844 closed defect (wontfix)

Inform me about sandbox violations

Reported by: arma Owned by: yawning
Priority: Medium Milestone:
Component: Archived/Tor Browser Sandbox Version:
Severity: Normal Keywords: sandbox-security
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

The bubblewrap seccomp sandbox prevents my sandboxed tor browser from doing certain system calls. That's great! But, what do I see when it attempts a forbidden system call?

Yawning tells me the answer right now is that it silently doesn't do the forbidden action. That's not terrible, but if I want to debug our sandbox rules, or learn whether I'm being attacked by the website payload, it's not ideal.

Apparently another option is that the kernel could send the process a SIGSYS signal. So in that case my browser would die with a sigsys signal, and I could conclude that apparently a sandbox violation occurred.

But Yawning says that the sandbox rules aren't perfect, and in particular there are some edge cases involving "weird issues with x86 32 bit systems forgetting whitelisted syscalls". So killing by default will end up with some sad users.

Apparently a third option would be to teach Firefox to hook the sigsys signal, and then it could log something about what it was doing at the time it got the signal. That involves some programming -- and I wonder if the timing is fine-grained enough that Firefox at the time of the sigsys signal can identify exactly which syscall it is doing?

Child Tickets

Change History (8)

comment:1 Changed 2 years ago by yawning

Apparently a third option would be to teach Firefox to hook the sigsys signal, and then it could log something about what it was doing at the time it got the signal. That involves some programming -- and I wonder if the timing is fine-grained enough that Firefox at the time of the sigsys signal can identify exactly which syscall it is doing?

This is fine. The siginfo_t that the signal handler will get contains all the relevant information.

comment:2 Changed 2 years ago by arma

Description: modified (diff)

comment:3 Changed 2 years ago by cypherpunks

Apparently another option is that the kernel could send the process a SIGSYS signal. So in that case my browser would die with a sigsys signal, and I could conclude that apparently a sandbox violation occurred.

If it's allowed to catch the signal, what's to stop a hijacked Firefox from ignoring it? The only signals which cannot be caught are SIGKILL and SIGSTOP. Others can be trapped or maliciously ignored.

"weird issues with x86 32 bit systems forgetting whitelisted syscalls"

Why is it permitting x86_x32 syscalls? They have questionable benefits and a history of vulnerabilities. Firefox does not make use of the x32 ABI anyway.

comment:4 in reply to:  3 ; Changed 2 years ago by yawning

Replying to cypherpunks:

If it's allowed to catch the signal, what's to stop a hijacked Firefox from ignoring it? The only signals which cannot be caught are SIGKILL and SIGSTOP. Others can be trapped or maliciously ignored.

I mean, right now, proscribed calls return ENOSYS. I was going to change it to trapping, and returning ENOSYS from the handler, which, firefox is free to ignore as it sees fit.

"weird issues with x86 32 bit systems forgetting whitelisted syscalls"

Why is it permitting x86_x32 syscalls? They have questionable benefits and a history of vulnerabilities. Firefox does not make use of the x32 ABI anyway.

As in, 32 bit intel, on 32 bit systems, not X32.

Version 0, edited 2 years ago by yawning (next)

comment:5 in reply to:  4 Changed 2 years ago by cypherpunks

Replying to yawning:

Edit: I went and added a rule to SIGKILL on unexpected architecture (I think it would have ENOSYSed), for the sake of my peace of mind.

I think libseccomp is supposed to automatically throw an error during the initiation phase if they're running on the improper architecture. See seccomp_arch_exist(3).

In general, unless you're directly writing in raw BPF bytecode or writing for multiple architectures at once, in the same seccomp running seccomp filter, you don't have to worry about architecture issues.

comment:6 Changed 2 years ago by yawning

I think firefox's sandboxing code uses the trap action and a SIGSYS handler to handle filesystem access brokering, so things will probably break horribly. Before I can take further action on this, i really need to see what ESR52 will look like (So basically #20794, and I really need to talk to Mozilla and figure out what they have planned).

comment:7 Changed 2 years ago by yawning

Keywords: sandbox-security added

comment:8 Changed 11 months ago by yawning

Resolution: wontfix
Status: newclosed

This project is deprecated, and none of these will ever be fixed.

Note: See TracTickets for help on using tickets.