Shared memory

[bananagold00]

Regarding the isolation based on threads one obvious question would be how you addressed the risk of shared memory with the other threads of the process. Since all thread have access to the same shared memory, a compromised sandboxed thread could manipulate the memory and thereby escape the restrictions through another less sandboxed thread. Previous sandbox technologies were process based for this exact reason, because processes are isolated from each other while threads are not, so how is this risk mitigated in threadbox?

[null9900]

Hello @bananagold00

I discuss the design of Threadbox and address this question in this paper: https://arxiv.org/pdf/2506.23683

Threadbox is designed to limit what threads can do without imposing any limitations on the shared memory between threads. For instance, a socket can be shared between two threads as a global variable, but one of the threads can have access to sockets system calls, while the other can't.

Threadbox doesn't promise full security, but it provides a layer of security that can mitigate vulnerabilities. This repo contains examples of real-world vulnerabilities mitigated by Threadbox: https://github.com/null9900/threadbox-evaluation

I honestly think that the shared memory issue is not the biggest limitation of threadbox, but rather its portability across different Linux systems. You can check the paper for more details.

[bananagold00]

I did read your entire dissertation actually, that's why I'm asking about the details of thread isolation.
It was an interesting topic, so thanks for publishing it :)

You mentioned in the paper as well that threadbox does not address the issue of thread isolation but I am wondering just how big the realistic obstacle for sandbox escape is. While different threads can't directly manipulate each others stacks, heap manipulation is what most real world exploits use to get arbitrary code execution.

From my perspective threadbox may require additional steps from an attacker but wont get on the same level as browser sandbox isolation. Maybe that's not actually the objective though as you focused on usability

[null9900]

@bananagold00 Sorry for the late response.

I honestly thought that no one is ever going to read it :D
So happy to hear that you found it interesting.

It is great that you brought the topic of browser sandbox isolation. Let's see what Chrome uses for sandboxing. Type this in Chrome browser chrome://sandbox/, you will see that it is using different components to create the sandbox, but mainly using Seccomp, Namespaces, and Ptrace.

Each one of these components can --under some conditions-- be escaped, and they don't promise FULL security or isolation. Seccomp can disable an application to use the open and write system calls, but technically, the attacker can still use already opened fds and write to them using mmap. Does that make Seccomp useless? No.

Same goes for namespaces, containers like Docker and LXC use namespaces to create isolation, but they also do so many things alongside that to prevent escapes, like mounting some proc files as read-only, etc etc .. and still after that, sometimes they get escaped ..

They provide a layer of security.

The reasoning behind Threadbox:

• It is simple
• Can be applied to small subsets
• It does provide security and prevents vulnerabilities using kernel-level enforcement. If you have a global variable that contains a password that is shared between threads, then Threadbox will not do anything about it, because global variables are SUPPOSED to be shared. If it is a local variable to the thread that needs it, then it won't be shared with other threads, so my reasoning is that this is not a problem with Threadbox, but rather with thread-unsafe code.

Here is a scenario: You are writing a Python script to automate something, you realize you need to install a package from PIP. The package Github page doesn't seem to be very active. You get worried that this package could contain malicious code and you don't want to run it on your machine without confinement.. You wrap the function that uses that package with Threadbox and only enable rpath. I would argue in this case, Threadbox provides a layer of security while being simple to use.

TLDR: Sandboxing is hard :D

PS: sorry for typos

[bananagold00]

The usability aspects are certainly valuable and I can see how much easier it is to apply based on functions compared to process based isolation. But the security aspects are much more relevant for the end results. Unfortunately I have not yet found any recent paper that actually measures the effective security of these different sandbox mechanisms.

Each one of these components can --under some conditions-- be escaped

And each of these components can in theory be applied without the possibly to escape them. But thread based isolation can not.
I have yet to try this in practice so I cant really say how easy it is, but since threads share their memory with each other, a sandboxed thread would be able to manipulate the memory of another, less or unrestricted thread and escape the entire confinement that way.

With a well build broker sandbox implementing seccomp, the only path to escape would be to find a vulnerability in the remaining IPC API between broker and confined client. This provides an entirely different picture and depends on the security of the broker API and not seccomp.

When any established security mechanism is applied, there is usually no way to circumvent it. Sure there are ways to circumvent even DAC when it is applied wrong, but that's not a problem of the DAC implementation or theoretical mechanism itself.
Yet one could argue that thread isolation has a known escape path that cannot be isolated to begin with, so the entire category of thread based isolation could be labeled as security by obscurity. And while obscurity can still be argued to provide security, its not usually what is intended

[null9900]

@bananagold00 How do you view Seccomp in this context? Seccomp is thread-based and doesn't address the shared heap. Yet it is used all over the place and considered to be a well-built security solution.

sandboxed thread would be able to manipulate the memory of another, less or unrestricted thread and escape the entire confinement that way.

Can a thread manipulate the heap of another thread? Theoretically, yes. But my understanding is that a pointer has to be explicitly shared with the other thread, otherwise you will have to scan the memory to find the heap of the other thread. ASLR and guarded pages makes it difficult to guess. In case of global variables, as I said, I don't view this as something to protect from, since they are meant to be global.

[bananagold00]

How do you view Seccomp in this context? Seccomp is thread-based and doesn't address the shared heap. Yet it is used all over the place and considered to be a well-built security solution.

Seccomp is by default applied to the entire process and while it can be applied on specific threads, I have yet to see this being used in practice. In other words the way it is actually applied in applications that use seccomp, there are no unrestricted threads to escape to.

Can a thread manipulate the heap of another thread? Theoretically, yes. But my understanding is that a pointer has to be explicitly shared with the other thread, otherwise you will have to scan the memory to find the heap of the other thread. ASLR and guarded pages makes it difficult to guess. In case of global variables, as I said, I don't view this as something to protect from, since they are meant to be global.

ASLR is a good example here, as it is commonly broken when enough information can be gathered. And information leakage is very common, so from my perspective ASLR and in extension threadbox are measures to annoy an attacker by making exploitation harder, but with a clear and known path to circumvent them in practice.

[null9900]

Seccomp is by default applied to the entire process and while it can be applied on specific threads, I have yet to see this being used in practice.

I disagree. Seccomp is thread-based. Not process-based. It will be applied to the entire process if you sandbox the main thread. AFAI, Chrome and Firefox apply different Seccomp filters to different threads in the browser.

ASLR is a good example here, as it is commonly broken when enough information can be gathered... so from my perspective ASLR and in extension threadbox are measures to annoy an attacker by making exploitation harder

I wouldn't say ASLR is a measure to annoy the attacker because it really does render many of exploitation paths obsolete. Sure, with enough information leakage, you could get around it, but in my view, the vulnerability becomes with the source of information leakage, not with ASLR.

[bananagold00]

Seccomp is by default applied to the entire process and while it can be applied on specific threads, I have yet to see this being used in practice.

I disagree. Seccomp is thread-based. Not process-based. It will be applied to the entire process if you sandbox the main thread. AFAI, Chrome and Firefox apply different Seccomp filters to different threads in the browser.

Chromium and Firefox do not address threads whatsoever. Their entire sandbox architecture resolves around processes

https://chromium.googlesource.com/chromium/src/+/0e94f26e8/docs/linux_sandboxing.md
https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md
https://firefox-source-docs.mozilla.org/dom/ipc/process_model.html
https://wiki.mozilla.org/Security/Sandbox/Architecture

[null9900]

Thanks for sharing, I will take a look. I would be truly surprised if Seccomp is not used in the context of sandboxing threads. I don't remember of the top of my head any clear examples where that is the case.

But regardless, if you consider this to be a big factor in the security of Seccomp vs Threadbox, a flag can be added to allow the Threadbox sandbox to extend to all other threads, that wouldn't be challenging to implement.

[bananagold00]

Extending the restrictions to child threads is not the issue, its the parent and siblings that can be exploited unless the same restrictions apply to them. The problem is that the escape path can only be addressed if all threads of the process are isolated but the advantage of threadbox lies in the simple application on single functions.

The very first thing I wondered after reading the first sentences about threadbox was how this would address the shared memory of threads. As a reviewer I would have asked to address this at the beginning of the paper, though I think it was mentoned somewhere in the middle. All other sandbox mechanism I am aware of aim to isolate the entire process because processes are intended to be isolated from each other while threads are explicitly not. From my perspective it therefore makes sense to apply sandbox mechanisms to processes, while concepts like threadbox would require extensive research into how threads can be isolated in the first place. At least I'm not aware of any other project attempting this.

[null9900]

Fair enough. Threadbox is after all a PoC to demonstrate the model of sandboxing functions. If I had to extend my research, I would probably look into ways to implement the function-level sandboxing on the interpreter level. Not sure if it is possible, but that would solve many of the problems in the current implementation of Threadbox. The history of the Java sandbox tells that this is not an easy thing to do :)

Let me know if you decided to explore this topic more. I would be interested to read any follow-up research.