Hardening the "file" utility for Debian [LWN.net]

Hardening the "file" utility for Debian

Posted Aug 14, 2019 19:23 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

The biggest problem here isn't the file utility, it's the expectation people have that they can LD_PRELOAD a random library that intercepts function calls and makes different syscalls while maintaining a security sandbox.

Hardening the "file" utility for Debian

Posted Aug 14, 2019 21:40 UTC (Wed) by clugstj (subscriber, #4020) [Link]

No, the problem is that one group of people want functionality (using LD_PRELOAD to do kewl things) and another group want to use "seccomp()" for security. These two "wants" don't play nice together.

Hardening the "file" utility for Debian

Posted Aug 15, 2019 11:31 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

But it seems to me that the same issues would happen with pledge and OpenBSD has fixed them. The article itself hints that you could even use seccomp v1 if the architecture of file is changed to split restricted code into a separate process.

Hardening the "file" utility for Debian

Posted Aug 14, 2019 19:30 UTC (Wed) by juliank (guest, #45896) [Link] (8 responses)

You can't rewrite file with security in mind w/o using seccomp. The point is that there is likely some bug somewhere in the parsing code that can be abused to execute programs or talk to network. seccomp is the only way to prevent that (well, you could switch network and mount namespaces into like empty namespaces, but um, sounds like similarly broken and more work, and not working as user depending on your distro).

Hardening the "file" utility for Debian

Posted Aug 14, 2019 19:53 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Well, choosing a language other than C is sure to help here. Assuming you have more advanced facilities like parser combinators or PEG grammars actually reading the untrusted code, the lack of open-coded fiddly bits (pointer increment, off-by-one loops, </<= mixups, etc.) is certainly a far better step in the right direction.

Hardening the "file" utility for Debian

Posted Aug 14, 2019 20:09 UTC (Wed) by epa (subscriber, #39769) [Link] (6 responses)

You could write the parsing code in a safe language. Then, if there isn't a call to exec() literally appearing in the source code, there's no way the code can be tricked into calling exec() by overwriting the stack due to a missing bounds check, integer overflow or whatever. There are safe dialects of C which are probably compatible enough for the parsing code to work.

Hardening the "file" utility for Debian

Posted Aug 14, 2019 20:26 UTC (Wed) by juliank (guest, #45896) [Link] (5 responses)

I don't think there are safe languages. Runtime bugs add a lot of unsafety; having another layer of protection is important.

Hardening the "file" utility for Debian

Posted Aug 14, 2019 23:14 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

In practice, if you write the parsing code in Rust or Go and avoid doing something exceptionally stupid like using Rust's "unsafe" keyword, your code will not be exploitable. For evidence, take a look at https://github.com/rust-fuzz/trophy-case and observe how few security bugs there are, and how they involved explicit use of "unsafe".

You can argue it still wouldn't be "safe" for some meaning of the word, but seccomp filters aren't "safe" in those terms either.

Having said that, extra layers of protection are still good and grappling with the issues in this post is still important. In particular, if `file` was written in Rust but users' systems inject C code into it via LD_PRELOAD, then savvy attackers would target that C code. Witness the security vulnerabilities introduced by AV filters over the years.

Hardening the "file" utility for Debian

Posted Aug 18, 2019 3:02 UTC (Sun) by k8to (guest, #15413) [Link] (1 responses)

Your code will not be exploitable by memory overruns, use after free, etc type problems. There are other potential attacks on software.

Hardening the "file" utility for Debian

Posted Aug 18, 2019 5:59 UTC (Sun) by dvdeug (guest, #10998) [Link]

Okay? You can give up on worrying about potential attacks on software, but it seems bizarre to worry about potential attacks on software and ignore the ability to ignore memory overruns, use after free, etc. type problems.

Hardening the "file" utility for Debian

Posted Aug 15, 2019 13:01 UTC (Thu) by epa (subscriber, #39769) [Link]

There may not be any safe languages but there are certainly dangerous ones.

While there are bugs in the Java or .NET runtimes, or other language runtimes, getting an exploit through one of those is usually much harder than the swarm of exploits a C program will contain unless written with exceptional discipline by a highly skilled programmer.

But actually I wasn't really suggesting one of these heavyweight managed languages that pulls along a runtime environment. Rust doesn't have a runtime, for example. The Cyclone programming language is a safer dialect of C which also doesn't have any special run time requirements.

Hardening the "file" utility for Debian

Posted Aug 17, 2019 11:21 UTC (Sat) by dvdeug (guest, #10998) [Link]

There are a wide variety of languages wherein buffer overflows and similar tricks can not run arbitrary code. A Scheme program, for example, can crash due to being out of memory, but will never allow arbitrary code execution. Do Scheme interpreters and compilers, and the libraries they use, have bugs? Sure, but it's like driving a rusted-out car across country instead of flying because "there's no such thing as a safe vehicle".

Hardening the "file" utility for Debian

Posted Aug 14, 2019 20:05 UTC (Wed) by Deleted user 129183 (guest, #129183) [Link] (7 responses)

> At this point, would't it be easier to rewrite "file" from scratch with security in mind instead of trying to use "seccomp()"?

Well, I guess that’s exactly the reason that openBSD has their own, seemingly NIH, implementation of it…

Hardening the "file" utility for Debian

Posted Aug 14, 2019 22:55 UTC (Wed) by wahern (subscriber, #37304) [Link] (6 responses)

OpenBSD had a syscall filtering mechanism, systrace, years before seccomp. Unlike the ptrace-based version of systrace on Linux, BSD systrace was incorporated into the kernel. The problem was that nobody used it--it was too low-level. So after several years systrace was ripped out. pledge and unveil is what came about after people chewed on the problem for a few more years.

The original contributors of seccomp were quite familiar with systrace. seccomp only permits filtering scalars because it was through systrace that it was proven how easy it was to bypass string path filtering unless the kernel copied the string. (Later releases of systrace came with a huge warning that string path filtering wasn't secure.) As I recall, seccomp was originally intended for sandboxing Chrome NaCl, which by design only required read and write from the sandboxed process. seccomp was the minimal amount necessary to put into the kernel to make NaCl work. I don't think Google ever intended seccomp to grow into a general purpose syscall filtering or sandboxing mechanism as it was already obvious from the history of systrace that the low-level semantics don't lend themselves to more sophisticated use cases.

So, no, pledge isn't NIH. seccomp is basically a *worse* systrace, and everybody knew systrace was a dead end.

Another alternative is Capsicum. OpenBSD rejected this for the same reasons the file(1) maintainer hasn't yet refactored their codebase: Capsicum, like the original seccomp, is premised on using a multi-process privilege separation model, which requires alot of work, *especially* for preexisting codebases. Capsicum is great model, but it doesn't prove a viable solution for preexisting code.

Hardening the "file" utility for Debian

Posted Aug 14, 2019 23:46 UTC (Wed) by roc (subscriber, #30627) [Link] (3 responses)

You're mixing up the original seccomp with seccomp-bpf. The original seccomp was designed by Andrea Arcangeli, not Google, and only allowed read/write on open file descriptors. Later Google added seccomp-bpf to reduce exposed kernel attack surface from sandboxed Chrome processes, not just NaCl but also Web content processes.

It's very important to keep in mind that implementing a sandbox with just seccomp is usually a terrible idea. In Linux, kernel namespaces are the best way to construct a sandbox. Then you apply a seccomp filter as an extra layer of defense, to reduce the kernel API attack surface exposed to sandboxed code. This is what Chrome and Firefox do. OpenBSD of course doesn't have kernel namespaces. Comparing pledge() to seccomp-bpf for constructing sandboxes is really a mistake, you should compare pledge() to kernel namespaces (with or without an additional seccomp-bpf layer).

> I don't think Google ever intended seccomp to grow into a general purpose syscall filtering or sandboxing mechanism

Perhaps Andrea Arcangeli didn't, but Google certainly did, otherwise their decision to use BPF to express arbitrary predicates is unfathomable.

Personally I'm pretty glad they did. We use seccomp-bpf for selective syscall interception in rr in a way that a dedicated sandbox API like pledge() would never have supported. That feature is critical for low overhead in rr recording.

Dead-end or not, seccomp-bpf is working in practice for Firefox, Chrome, rr, and others.

Hardening the "file" utility for Debian

Posted Aug 15, 2019 0:34 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> OpenBSD of course doesn't have kernel namespaces.
They do have unveil()-based file "namespaces".

Hardening the "file" utility for Debian

Posted Aug 15, 2019 1:52 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

unveil() lets you whitelist filesystem paths. I think it's confusing to call that "namespaces". chroot() is more namespace-like.

Hardening the "file" utility for Debian

Posted Aug 15, 2019 2:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

That's why I put "namespaces" in scare quotes, because in practice it functions similarly to the unshare()-then-bind-mount trick that systemd and other software use on Linux.

Hardening the "file" utility for Debian

Posted Aug 15, 2019 14:41 UTC (Thu) by Deleted user 129183 (guest, #129183) [Link] (1 responses)

> So, no, pledge isn't NIH.

I was talking about openBSD reimplementation of `file`, not about `pledge`.

Hardening the "file" utility for Debian

Posted Aug 16, 2019 0:52 UTC (Fri) by flussence (guest, #85566) [Link]

I think it's incorrect to say OpenBSD's the one suffering from a Not Invented Here problem here.