1606592 - Use RLBox to sandbox Prio

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, task)

Description

[Deian Stefan]

Attachment: Patch to PrioEncoder (using NOP-sandbox)

I briefly talked to Henry about sandboxing Prio in Firefox. This would reduce the attack surface due to bugs in both Prio and msgpack. With RLBox+Wasm we can ensure that memory safety bugs in libprio can't be exploited to compromise parts of Firefox.

Since this would amount to doing crypto in Wasm (unless we can expose NSS to the Wasm sandbox), I was a bit concerned about timing channels. But it seems like timing channels are already out of scope for the Prio browser use case. And reasonably so: a co-located
attacker can learn which sites you visited through all kinds of other higher-bandwidth side channels (e.g., :visited links). This leaves a server-only attacker timing your computation---and this seems both unrealistic and easy to address.

Comment 1

[Deian Stefan]

@Robert: hi! Sorry for not CCing you on the original email exchange with Henry. Since you're the owner of this code, it would obviously only make sense to do this if this sounds useful to you. We don't have to make any decisions anytime soon; I want to make sure the other Mozilla folks we've been collaborating with on RLBox are on board with this too, I just wanted to create the bug while I had the patch laying around and thought you should be CC'd.

Comment 2

[Bobby Holley (:bholley)]

Rob mentioned that libprio depends on NSS - how does this patch work if the sandboxed libprio needs to call out into NSS?

Comment 3

[Deian Stefan]

This patch is for the NOP sandbox. We need another patch to enable the Wasm sandbox.

The simplest way to do this is to create a .so that has libprio with msgpack and NSS.

• Con: since NSS is in the tree, we'd be essentially pulling in a second copy of it (though maybe only bits of it). We definitely don't want to do this long term.
• Pro: we don't have to worry about a compromised libprio to not exploit the NSS interface.

Alternatively: we can expose the relevant functions as host functions to the Wasm sandbox. Ideally we would expose wrapped versions that copy and validate arguments before calling the actual NSS functions. We probably need some build system magic here though.

Comment 4

[Shravan Narayan]

@deian - yup, that sounds right to me. Did you want me to look into the patch to enable the wasm sandbox for prio as well?

Comment 5

[Robert Helmer [:rhelmer]]

(In reply to Deian Stefan from comment #3)

This patch is for the NOP sandbox. We need another patch to enable the Wasm sandbox.

The simplest way to do this is to create a .so that has libprio with msgpack and NSS.

• Con: since NSS is in the tree, we'd be essentially pulling in a second copy of it (though maybe only bits of it). We definitely don't want to do this long term.

I think this is the right way to go too. Prio doesn't use very much of NSS, it'll be interesting to see how large the result is.

• Pro: we don't have to worry about a compromised libprio to not exploit the NSS interface.

Alternatively: we can expose the relevant functions as host functions to the Wasm sandbox. Ideally we would expose wrapped versions that copy and validate arguments before calling the actual NSS functions. We probably need some build system magic here though.

NSS itself (and its API) are fairly complex, I think exposing WebCrypto-style APIs (or maybe even something simpler like libsodium crypto_box) would be time better spent vs. wrapping individual NSS functions and exposing those directly to the sandbox.

Comment 6

[Nathan Froyd [:froydnj]]

Note that doing a libprio + msgpack + NSS super-library also involves pulling in NSPR (I think), which means (I think) informing NSPR about a wasm32-wasi target. Which is probably sufficiently different from targets that NSPR supports (e.g. no threads) that there are probably some interesting things that need to be handled. Or maybe NSPR already/still supports such targets?

Comment 7

[Deian Stefan]

Shravan had a simpler alternative to the super-library: we can modify Prio to take the handful of NSS functions and turn them into callbacks. We can probably do this by just modifying Prio_init to take these function pointers. This might side-step the NSPR issues, I think?

NSS itself (and its API) are fairly complex, I think exposing WebCrypto-style APIs (or maybe even something simpler like libsodium crypto_box) would be time better spent vs. wrapping individual NSS functions and exposing those directly to the sandbox.

If we're going to do crypto in Wasm I would be a fan of using something like libsodium's secretbox since we can also more easily ensure that the code is constant time.

@Shravan: > Did you want me to look into the patch to enable the wasm sandbox for prio as well?

No need (yet), thanks for the offer though!

Comment 8

[Deian Stefan]

Abandoning this because of the Rust rewrite.