Hacker News Reader

Comment by pizlonator | Hacker News Reader

It’s cool that this mentions Fil-C but it also undersells it. TFA also undersells CHERI. Fil-C doesn’t just “find a lot of temporal-safety” bugs. It closes off memory safety bugs (special and temporal) for exploit writers and ascribes a tight semantics to the whole language. CHERI makes some different trade offs but also gives a tight enough semantics that memory safety exploits aren’t going to work. Both CHERI and Fil-C are more comprehensive than Rust, since they attack the problem at the ABI level (and so you don’t get the problem that the protection only applies to the parts that were rewritten in the safe subset of a new language). Rust could be claimed to be better in that its compile time, but that doesn’t make a significant difference if you’re worried about the definedness of semantics or exploitability.

View on HN

Both only attach provenance to allocations. The common example is:

    struct User {
        char name[100];
        bool is_admin;
    };

Where a buffer overflow can still overwrite `is_admin`.

Both also require recompilation of everything, which might be possible for CHERI but not for Fil-C - which is why, for example, there cannot be Fil-C support for Windows or macOS.

No, CHERI supports sub-object capabilities.

Nice, didn't know that!

It's a safe/stable operation to derive a more limited capability (pointer) from a more capable one. An example would be an arena allocator having a pointer valid for the whole arena, but then only handing out a derived pointer that's valid for the size requested.

You can also limit access permissions IIUC; I'm only going by old memory here, but you'd be able to hand out a read-only pointer derived from an RWX pointer.

Fil-C used to as well. It's not a fundamental limitation; it's more policy: if the programmer takes a pointer to `name`, and then uses arithmetic to get to the `is_admin` field, do we allow it or not? If we allow it, then this hypothetical example becomes a security vulnerability. If we disallow it, then a huge number of C/C++ programs stop working.

This "name overflows to is_admin" example doesn't come up in real code or real CVEs. It does come up in HN comments on Fil-C threads though.

CHERI is less compatible than Fil-C, in terms of how many changes you have to make to code to make it work, and this is an example of a policy decision that causes that result.

My personal anecdata from C++ side:

It is interesting that C++ decided to disallow it in compile time evaluation ( constexpr contexts ).

I have already seen fixes where code that used pointer arithmetic to go from one struct member to another generated garbage in real-world gamedev projects. That code had been like that for 20+ years and worked fine, then suddenly broke after toolchain update.

IIRC Filip said that Fil-C can be modified fairly easily to catch those overflows, but that breaks a fair bit of C code.

You're showing an example of something that could be a security bug if someone wrote that code, but you are missing the plot when it comes to memory safety and its connection to security.

What makes memory safety so important is that in C/C++, a missing bounds check on `name` gives you access to the entire heap, not simply the other fields within that allocation. Attackers aren't using missing bounds checks to look for `is_admin` fields in the same object. They're looking for a pivot to full memory control, so they can plug in their RCE exploit chain. So, the only time that attackers are looking for an intra-object overflow is if they have something like `struct { char buf[100]; void* ptr; }`, since that does lead to a pivot to full memory control. Fil-C protects that; you can't use that overflow to corrupt `ptr`'s capability.

This is why memory safety tech like MIE, MTE, and Fil-C focus on allocation granularity. If I wanted to support subobject granularity, I could; it's not a huge change to the capability model. Fil-C's first two capability models (back in late 2023, early 2024) supported subobject granularity. I'm choosing not to support it now because I understand the security implications well enough to know that it's not worth the complexity.

Fil-C started out as a macOS project. Fil-C supports Windows and macOS today via APE. Requiring recompiliation of everything is a luxury I can choose to support on Linux that results in memory safety of the whole process. If you find Fil-C useful and understand compilers, you could probably get a variant working that has FFI and then expose Windows and Mac API to it. You'd get something with a weaker safety guarantee, but no weaker than what you get today from Rust or Java.

There have been real exploits that were built off of one-bit overflows. It is not enough to just protect beyond struct boundaries.

There are lots of those kinds of exploits if the one-bit overflow gives you control of a pointer. That doesn't work in Fil-C; the pointer's capability is protected in that case.

There are many orders of magnitude fewer real exploits using intra-struct overflow without pointer control than there are exploits using vanilla logic bugs (like the programmer forgot to check the is_admin bit before proceeding to the admin privileges business logic).

So, obsessing over intra-struct overflows in a language that prevents ptr-int type confusion is missing the plot.

(Believe me, if intra-struct overflows over primitives were a big threat, I'd change the Fil-C policy.)

Reply on news.ycombinator.com