Hacker News Reader

An interesting problem is that even if you sandbox everything perfectly, you still need to get accurate information out of the sandbox. If a sandboxed parser was compromised, you still can't trust that it reported true information to you.

Sandbox prevents malicious code from escaping, but not from lying to you.

Agreed - it just limits the damage.

>Writing, maintaining, and updating their own code to process all types of media, and keep up-to-date with all changes to all those types of the media, seems impossible and certainly uneconomical. What could they do?

There is a middle ground of "force update software on the device more than once a decade." Yes, FFmpeg will always have vulnerabilities, and recreating their work would cost an enormous amount and be less secure. Properly distributing security patches is an affordable alternative.

There is no abstract security benefit from updating some software, updates just changes things. Software security is like a bubbly shell with holes and no thickness, patching a random hole means nothing.

It changes whether I could exploit the device. I have realistically no way of developing a new hole in their software, but I'm capable of becoming a script kiddie if I wanted to.

The "patch" is to not use the physical extraction thingy on iPhones anymore: https://www.google.com/amp/s/9to5mac.com/2021/04/27/cellebri...

Wow, that seems really obfuscatory. It's implausible that they only have a vulnerability to iPhone devices, but I guess that's the line of argumentation they'd use to limit the fallout. Sucks to be cellebrite.

I think it's related to the stolen Apple DLLs in their product. Any competent legal department would tell them to remove those immediately, because you don't want to get in a lawsuit with Apple over such a clear case.

It does seem very clearly a permissible use. Corellium beat Apple's copyright claims and they did far more than just embed a DLL.

That is incorrect, Corellium does not ship Apple code.

My understanding was that the copyright portion of the suit was over them doing exactly that? Maybe running it in the cloud vs shipping it, but e.g. https://techcrunch.com/2020/12/29/apples-lawsuit-against-cor... mentions iOS IPSW files.

Edit: it seems like they downloaded the file from Apple's site. The order says using the IPSW file was fair use, and that doesn't appear to depend on them downloading it vs shipping it. I don't think that makes a different. The cellebrite usage is also fair use for the same reasons (doesn't compete with Apple, transformative usage, etc)

> they'd need a lot of horsepower in their device.

Googling "cellebrite forensic extraction device" shows a rugged laptop-like device in a case the size of a desktop PC. I'm not sure if that's the real thing or not, but in any case it doesn't look like space is a concern. There's plenty of room in that suitcase for a modern CPU, lots and lots RAM, and as much battery power as you need.

The « rugged » part usually translates to thermal and reliability concerns, which are traded for raw performances.

The friggin device probably costs over $100,000 and comes with a full-time support contract. They could add an extra $500 worth of CPU and RAM to the device, assuming they can find a competent evil kernel dev to do the work

The parent comment means that hardware that runs in a rugged container thingy is typically limited by thermal constraints. It's not the $ 500 that's the problem, but a faster CPU could overheat with that packaging.

It costs around $10k.

You'll find that dollars don't actually override physics. If you can't cool your extra fasty CPU, it's not going to be vey fasty.

For reference look at panasonic's "fully rugged" toughbooks. A baseline 31 will cost you $3700 for a 7300U, 16GB RAM, a 256GB SSD, and a 13.1 1024x768 display. On base spec it'd be a $800 laptop if you could find one with a screen that bad, and that outdated a CPU.

Except you can drop the 31 from 6ft, you can literally hose it down, you can rub it in a dirt pit, you can drive on it with a truck, and it's expected to survive and work fine. It also has a baseline 20h battery. That resistance, that ruggedness, comes with limitations. And it's not very useful to have an indestructible laptop if a gentle shake kills the electronics either.

Hence "thermal and reliability concerns". You look for parts you can cool with a relatively low thermal budget — which limits your performances — and you look for parts which have been designed and manufactured for industrial resistances, which also limits your performances. No matter how you slice it, a GTK Boxer won't outrace a Bugatti Chiron.

And because Marlinspike specifically mentioned FFMPEG by name, I think vulnerability was not in there.

At least that's what I would do.

He said it was an FFMPEG snapshot from 2012, which has had dozens of vulnerabilities since.

He even said that the vulnerability was not in there.

But since he advertised that one, anyone wanting to compromise Cellebrite has an easy target. So Cellebrite has to fix it.

Sandboxed code is not slower than unsandboxed code

Really? It seems like there should be some overhead ex. to verify whether each operation is allowed. Or does it not work like that?

The modern Linux kernel allows you to sandbox applications natively. There are tools that make this easy to set up, for instance [1].

[0]: https://blog.cloudflare.com/sandboxing-in-linux-with-zero-li...

[1]: https://firejail.wordpress.com/

Those sandboxes are certainly not free to set up (internal kernel locking) fwiw.

I use firejail and have the standard redirects in /usr/local/bin for most firejail supported applications, but the performance hit is definitely noticeable. I'm on an i7-8650U on my laptop with 16G ram.

Sandboxing _can_ be without overhead, but in the case of firejail it's definitely not the case.

> performance hit is definitely noticeable

Could you please name which application, and how do you notice it?

I notice it by how long it takes to start applications when I run them through firejail vs. when I run them directly.

I don't know if it also makes a difference during execution.

EDIT: it's kinda amusing to get downvoted on this.

a) There's no performance issue. Just use linux sandboxes

b) There are these possible performance hits

c) I use those sandboxes and I have observe X performance issues.

a) Your performance issues are not valid performance issues, because I say so.

Ok, gotcha

That's really a caching issue. Normally dynamically linked bins share a lot of code pages (many are already loaded) due to SOs. In jailed apps these are duplicated and have to be loaded again for each app.

It’s a caching issue that manifests itself as a performance difference, which is all GP claimed.

I'm using a low-spec laptop, so I usually notice these things before others. With Firejail I don't notice any performance hit at all on any of the apps I've used: Telegram, various windows games under Wine, Chromium.

To expand on vngzs's post, many key Linux syscalls (such as opening a socket/file descriptor) always check if a bit is set in a capabilities bitfield, so the only extra overhead is the one-time syscall to drop some set of capabilities.

Now, there is some overhead in forking a child process to have different capabilities than the parent, and some overhead in using a pipe/shared memory to communicate between the sandboxed child and the parent, but that overhead should be tiny compared to the work of decoding compressed video, etc.

there is some overhead depending of how you define isolation.

seccomp has very little impact but it's not 0:

https://wiki.tizen.org/Security:Seccomp#Performance_Analysis

firejail or systemd isolation techniques (using a variety of methods such as mounting a private version of directories or initiating ACL's at application start) are extremely lightweight but not 0. Most processes (regardless of desktop or server) usually live long enough (more than a few seconds anyway) to justify any theoretic impact. Even firejail on an ancient desktop system will not change things so that it's noticeable by a user imo.

Speaking theoretically: If you want to isolate an application, it seems you need extra resources to run the isolation functions, to handle any trade-offs they introduce (it's hard to believe it's zero), and to reproduce needed functionality and services that are outside the isolated space.

Essentially, I'm imagining a bunch of isolated VMs. How is that wrong in practice?

On Linux, namespaces and seccomp have minimal overhead. seccomp can filter syscalls directly, so if you just need to convert formats, you could load the library in a helper process and drop privileges. Sure the helper process would require more resources, but it shouldn't take much. For more sophisticated isolation, Linux namespaces can be used.

Out of boredom, I started 400 containers with podman running only bash in Ubuntu. It used less than 1 GB of RAM in total. podman is likely overkill if you just want sandboxing, however.

I'm sure there are still tradeoffs to containerization but at least the overhead is minimal.

There's a bunch of isolation that you're already paying the price of.

Your OS already has a layer that checks, when a process tries to open a file or access a bit of hardware, whether you have permission to access it. Your CPU has a layer that checks, when you try to read or write a given memory address, whether you have the right permissions. And so on.

A lot of sandboxing amounts to making those existing checks more restrictive - telling the OS "If this program running as John Doe asks to open a file, instead of treating it like John Doe treat it like someone with no files at all" - which is no slower than what the OS was doing anyway.

The sandboxing that comes with performance penalties is generally doing more than just sandboxing - for example, Ubuntu's 'snaps' have sandboxing, but they also duplicate a bunch of libraries for compatibility reasons.