1

I could not understand why this pull request was merged:

https://github.com/bitcoin/bitcoin/pull/20487

According to PR:

Enable filtering of system calls using seccomp-bpf: allow only explicitly allowlisted (expected) syscalls to be called.

The syscall sandboxing implemented in this PR is an experimental feature currently available only under Linux x86-64.

Can someone help me understand how does this help as as a user with examples?

Improve this question

1 Answer 1

Reset to default
2

In general, in order for a thread to interact with any resource external to itself (such as disk I/O, other processes, other threads, etc.), it does so through the use of system calls. There are many system calls, many which could be dangerous in the right context, and many which a thread is not going to use. Syscall sandboxing thus restricts the system calls that a thread is allowed to use. Attempting to use any syscalls outside of the allowlist will result in the OS terminating the process rather than allowing execution to continue.

For Bitcoin Core, this is not going to do much during normal operation. However it can help mitigate the effects of unknown vulnerabilities. For example, suppose there were a buffer overrun vulnerability which allows an attacker to execute arbitrary shellcode. Such shellcode could contain an execve syscall which spawns a ssh daemon allowing the attacker remote access into the machine. If seccomp-bpf is enabled, and the thread where this attack would occur does not allow the execve syscall, then an attack of this sort would fail because the process would be terminated as soon as execve were attempted. This can make it harder for the vulnerability to be exploited as a RCE and limit what an attacker can do.

Improve this answer
4
  • How would this work for Win or Mac?
    – user103136
    Jan 2 at 3:40
  • This doesn't turn the vulnerability from a RCE to just a crash. If any thread of the program is compromised, it can easily force other threads to do whatever it wants (by overwriting their stack, for example). While no thread has access to execve, many of them have access to the network and the filesystem, which is sufficient. So this only affects vulnerabilities where the amount of executable code is very limited and can't be increased with a multiple-stage exploit. I think the intersection of this set with the set of vulnerabilities that make arbitrary execve possible is not very large.
    – the default.
    Jan 2 at 9:54
  • @Prayank AFAIK, neither Windows nor Mac have this this feature.
    – Andrew Chow ♦
    Jan 2 at 18:52
  • @thedefault. Indeed, there are many other tricks an attacker could do to execute arbitrary code that do not require syscalls, but they are more limited in what they can do. I've edited the answer to reflect that.
    – Andrew Chow ♦
    Jan 2 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy