1,114 karma · joined March 31, 2014
Here's a tweet from the original finder: https://twitter.com/gabe_k/status/1330966182543777792?s=20
Yarden & Ionescu's work are both really top notch. Also anything by Google Project Zero if you want to do a deep dive on the subject.
You're right though, they should at a minimum link to it more prominently.
When writing C or C++, never compare against true.
In the case of t article, the Rubicon has been crossed, and also features "cast" into the silicon can't be fixed (most of the time). But you're right, they aren't actually cast.
It's very Chrome and C++ specific, but the problems will likely be similar in practice.
Tiktok is far smaller, and has a smaller attack surface. If there was money in it, people would audit Tiktok all day.
Similarly, many stack overflow questions are out of date, and good luck getting them updated to reflect current best practices. And if you do ask the same question again trying to resurface a newer, better way to do something it will almost certainly be closed as a duplicate. Huge fan of the resource though.
Ultimately, experienced professionals who are paid full time to be both writers and technologists can do a better job, especially over a long period of time.
CET has two parts, a forwards edge protection (indirect jumps and calls like those necessary to execute a C++ virtual function, a Go interface function, or a Rust trait function), and a backwards edge protection to protect against Return Oriented Programming (overwriting the return address to attacker chosen code).
If I recall correctly, Windows will only use the backwards edge protection, since they already have a superior technology for forwards edge protection (CFG and XFG). The backwards edge protection has an impact of 1.65% according to that paper. Forwards edge protection had no impact.
I have to say, this is well worth it.
* Design consultations early in development to address insecure or risky designs.
* Reading risky parts of the code line by line hunting for buffer overflows and many other things. If you don't have access to the source, you can read the disassembly too, and people find a lot of bugs doing that!
* Fuzzing. Basically hooking up the program to a harness which throws random data at its attack surface until the program crashes, although it can get a lot more nuanced than that.
* Running static analysis tools to search for problematic code patterns.
The C/C++ code which powers all major operating systems and web browsers is rife with security issues. There are also whole other sub-disciplines auditing websites, corporate networks, and cryptography implementations, which generally use analogous techniques.