I think his argument is that you can have code this:

  user = s->user;
  if(user == bob)
    user->acls[s->idx]->has_all_privileges = true;

And this happens: 1. s->user is initialized to alice 2. Thread 1 sets s->idx to ((alice - bob) / sizeof(...)) and s->user to Bob, but only the intval portion is executed and the capability still points to Alice 3. Thread 2 executes the if, which succeeds, and then gives all privileges to Alice unexpectedly since the bob intval plus the idx points to Alice, while the capability is still for Alice

It does seem a real issue although perhaps not very likely to be present and exploitable.

Seems perhaps fixable by making pointer equality require that capabilities are also equal.

▲ pizlonator 7 hours ago | parent | next [-]

I understand his argument.

Here are the reasons why I don’t buy it:

1. I’m not claiming that Fil-C fixes all security bugs. I’m only claiming that it’s memory safe and I am defining what that means with high precision. As with all definitions of memory safety, it doesn’t catch all things that all people consider to be bad.

2. Your program would crash with a safety panic in the absence of a race. Security bugs are when the program runs fine normally, but is exploitable under adversarial use. Your program crashes normally, and is exploitable under adversarial use.

So not only is it not likely to be present or exploitable, but if you wrote that code then you’d be crashing in Fil-C in whatever tests you ran at your desk or whenever a normal user tried to use your code.

But perhaps point 1 is still the most important: of course you can write code with security bugs in Fil-C, Rust, or Java. Memory safety is just about making a local bug not result in control of arbitrary memory in the whole program. Fil-C achieves that key property here, hence its memory safe.

	▲	lifis 4 hours ago \| parent [-]
		In my understanding the program can work correctly in normal use. It is buggy because it fails to check that s->idx is in bounds, but that isn't problem if non-adversarial use of s->idx is in bounds (for example, if the program is a server with an accompanying client and s->idx is always in bounds when coming from the unmodified client). It is also potentially buggy because it doesn't use atomic pointers despite comcurrent use, but I think non-atomic pointers work reliably on most compiler/arch combinations, so this is commonplace in C code. A somewhat related issue if that since Fil-C capabilities currently are only at the object level, such an out-of-bounds access can access other parts of the object (e.g. an out-of-bounds access in an array contained in an array element can overwrite other either of the outer array) It is true though that this doesn't give arbitrary access to any memory, just to the whole object referred to by any capability write that the read may map to, with pointer value checks being unrelated to the accessed object.

▲ quotemstr 7 hours ago | parent | prev [-]

Exactly. I agree that this specific problem is hard to exploit.

> Seems perhaps fixable by making pointer equality require that capabilities are also equal

You'd need 128-bit atomics or something. You'd ruin performance. I think Fil-C is actually making the right engineering tradeoff here.

My point is that the way Pizlo communicates about this issue and others makes me disinclined to trust his system.

- His incorrect claims about the JVM worry me.

- His schtick about how Fil-C is safer than Rust because the latter has the "unsafe" keyword and the former does not is more definitional shenanigans. Both Fil-C and Rust have unsafe code: it's just that in the Fil-C case, only Pizlo gets to write unsafe code and he calls it a runtime.

What other caveats are hiding behind Pizlo's broadly confident but narrowly true assertions?

I really want to like Fil-C. It's good technology and something like it can really improve the baseline level of information security in society. But Pizlo is either going to have to learn to be less grandiose and knock it off with the word games. If he doesn't, he'll be remembered not as the guy who finally fixed C security but merely as an inspiration for the guy who does.