pizlonator

I think that the frontier labs knew what they were doing when they invested in cybersecurity starting in the spring (or maybe earlier). They knew it would create hype. They knew it fit with their narrative that they are building a dangerous thing (something they believe because it’s fun to believe in doom, because it’s a great story for investors, and because it’s not inconsistent with a moat - in fact it makes a moat via regulatory capture).

I wrote one and kept iterating by using it to fix bugs in itself

I still also use other harnesses, but mine is already at the point where I prefer it more often than not

You should totally keep working on yours. It’s a cool learning experience. And you might stumble on some good ideas that nobody else has had

> I see this as a pretty sneaky way of avoiding your security vulnerabilities going public and all the bad media exposure that goes along with it.

No, it's a way of making sure that Apple can fix the security issue and deliver the fix to customers before it can be exploited.

OP is being a big man about this

Good shit

> Well, if you write a library in the scriptc subset, it will also work in regular JavaScript runtimes, for free.

Not quite for free. You’d have to target the subset of both TS and scriptc and differential test, since there exist programs that work in both TS and scriptc but produce different output

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.)

I confirmed, it's faster than the Go version, which is very surprising, and super impressive!

Caveats:

- I don't think it's right to say that it's "written in TypeScript". In fact, it's written in the subscript of TypeScript that scriptc supports. scriptc isn't just a subset of ts; it even diverges from ts semantics in sneaky ways to facilitate its optimizations. So, these folks have really created a TypeScript-like native language with some kind of RC-GC hybrid and a bunch of caveats. Not clear if this is any better than just creating a new language.

- Very likely that it was codeveloped with scriptc, so it's getting maximum benefit from exactly the sorts of idioms that scriptc supports well. And, I would bet they landed optimizations to scriptc specifically to get this result.

This could be useful, assuming they invest in supporting it, and you're the sort of person who needs 2x faster ts compiles.

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.

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.

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.

Good point.

Oracle stock is up today.