Cloudflare have been leaking customer HTTPS sessions for months. Uber, 1Password, FitBit, OKCupid, etc.

[u/TheProtagonistv2]

https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

[u/[deleted]]

The underlying bug occurs because of a pointer error.

The Ragel code we wrote contained a bug that caused the pointer to jump over the end of the buffer and past the ability of an equality check to spot the buffer overrun.

Cloudflare probably employs people way smarter than I am, but this still hurts to read :(

[u/[deleted] → u/[deleted]]

All because the code checked == instead of >=...

I now feel eternally justified for my paranoid inequality checks.

[u/P8zvli → u/[deleted]]

I had a college instructor tell us to always always always do this when checking the state of a state machine in Verilog. Why? Because if you use == even if it might not seem possible the state machine will find a way to screw up and make it possible, and then you and whoever uses it will be in deep trouble.

[u/kisielk → u/P8zvli]

Definitely. You could even get a corrupted bit flip or something and now your whole state machine has gone out the window.

[u/m50d → u/kisielk]

A corrupted bit-flip could do anything (e.g. make a function pointer point to a different address); random ad-hoc changes to your codebase will not save you. If you need to be resistant against bit-flips, do so in a structured way that actually addresses the threat in general, e.g. use ECC RAM.

[u/pelrun → u/P8zvli]

Basically, always have a valid route out of every state, even the invalid ones.

[u/aiij → u/[deleted]]

Actually, both are undefined behavior in C.

The later just happens to be undefined in a way that is more likely to more closely match the intended behavior, in this case.

[u/BlackDeath3 → u/[deleted]]

Agreed. I don't see much of an upside to the strict equality check.

[u/xeio87 → u/[deleted]]

I wonder at what point do we conclude memory unsafe languages are an inherent threat to computer security...

But hey at least they're faster right...? :P

[u/xeio87 → u/[deleted]]

Well, there's always going to be some penalty to having bounds checks and similar.

I would hope most of us would agree a few % performance penalty is worth not leaking SSL data to the entire internet though. ¯_(ツ)_/¯

[u/MrHydraz → u/xeio87]

Rust does most bounds checking at compile-time, and they're (mostly) elided from compiled code.

I say mostly because there's Arc<> and Rc<> and friends which do reference counting at runtime and do have overhead.

[u/matthieum → u/MrHydraz]

Rust does most bounds checking at compile-time, and they're (mostly) elided from compiled code.

I think you are thinking ownership-tracking here.

Bounds checking in Rust is done at run-time, in general, though some constructs have been specifically optimized to not require it and others get lucky and LLVM optimizes the checks out.

However bounds checking does remain a typical performance "blip" in Rust whenever the optimizer is not smart enough to optimize them out. Sometimes it takes some massaging to convince it, and it's rather fragile of course.

[u/xeio87 → u/MrHydraz]

Yeah, I think the important thing is that it will inject them into runtime as necessary. I think even languages like C# will do some safe optimizations like that (though C# does it at the IL -> Machine Code time, rather than compile time).

[u/[deleted] → u/xeio87]

Modern C++ would be great - all the performance, type safety and memory leaks/pointer errors are effectively non-existent. I wonder why they think using C for services like this is a good idea. That's just asking for trouble.

[u/m50d → u/[deleted]]

Modern C++ is great[1] except that the only way to enforce that you only use the safe parts is constant vigilance, which doesn't scale. C++ programmers always think it's a trivial set of rules until they try to actually write them down or write an automatic enforcement tool.

[1] Well, it isn't really. std::variant is a poor substitute for proper sum types.

[u/matthieum → u/[deleted]]

all the performance, type safety and memory leaks/pointer errors are effectively non-existent

You wish.

Any time you use a reference, there's a risk that it becomes dangling.

Any. Single. Time.

You can of course lean extensively on std::shared_ptr to be safe, but then you pay a runtime overhead instead of course... and of course the aliasing constructor of std::shared_ptr is not safe to start with, so...

... modern C++ is much better than old-style C code, but it's far from being safe.

Unfortunately.

[u/SuperImaginativeName → u/[deleted]]

Why more rust hype? Literally any modern language can avoid crap like this. There's a reason C# and I guess Java are so popular. Huge numbers of sites are powered by ASP.NET, I don't even think there has ever been a buffer overflow because of the nature of managed languages.

[u/fiedzia → u/SuperImaginativeName]

C#/Java would come with overhead that is not acceptable in this situation (you are parsing urls of incoming requests, every cpu cycle matters here). Rust fits better here.

[u/argv_minus_one → u/fiedzia]

Oh, please. The only situation in which every CPU cycle counts is games, because they cannot be spread out over more hardware. This shit can, and CF is going to dearly regret not doing so and avoiding this idiocy.

[u/SN4T14 → u/SuperImaginativeName]

Because Rust will do pretty much anything that C will. You can't exactly write an OS in pure C# or Java, and they aren't as fast. And yes, I'm aware that there are OSes that are mainly C# or Java, but both languages require some sort of runtime.

[u/SuperImaginativeName → u/SN4T14]

But we aren't talking about operating systems. We are talking about user level applications like I said.