Security in C++ - Hardening Techniques From the Trenches - Louis Dionne - C++Now 2024

[@Voy2378]

Amazing to see Louis Dionne back, he is one of my all time favorite C++ persons. Few quick comments(kind of related to Bjarne's unhappiness that people ignore he spent 30+ years to make C++ safer than C): 1) would be nice if examples were more C++ style than C. I know there is ton of legacy code that is just C compiled with C++ compilers or uses C APIs, but I wonder in which cases "nice looking C++ code" is dangerous, since it obvious(to me at least) C code is dangerous. 2) would be nice to see what real code in CVE issues are. In particular in relation to 1) : are they crappy C style code written in 2009 or are there many cases of fancy modern C++ code written recently that is still a security problem... 3) this is very hard question, but does P2300 solves most/all threading problems issues? I mean I know you can write crap threading code with any standard/library, but if you do it "proper default P2300 way" are there still ton of opportunities for security exploits.

[@szaszm_]

to 2), I can't compare to C code, but even in modern C++ code, there can be plenty of bugs that these tools could cover. I've seen logic errors, synchronization problems resulting in UAF, and just normal programming mistakes that were not spotted during review.

[@SergePavlovsky]

@@szaszm_ this doesn't answer question about CVEs

[@PaulTopping1]

Excellent, clear presentation!

[@guiorgy]

Great talk! You can get memory issues in "safe" Rust too if you try hard enough, so making the default safer would be a huge step forward already

[@mileselam641]

"if you try hard enough" And there's the important bit. You don't have to try to mess up in C++. C++ programs are basically one big "unsafe" block where you must be constantly hypervigilant no matter how tired or distracted you are. Setting safer defaults in C++ is better, but without breaking backwards compatibility, will it ever be even close to enough? More and more companies are finding the answer is increasingly "no".

[@madonobel]

Does C has similar hardening Modes at compile time

[@vasiliigulevich9202]

22:07 dereferencing null is a safety issue, because it can be optimized out and crash will not happen

[@SergePavlovsky]

why is it a safety issue if it was optimized out?

[@kartikmahajan4405]

we build our own tool chain, i.e compile llvm/clang. Does compiler have to be build with this macro for projects to enable this? e.g we use -DLIBCXX_HARDENING_MODE="none" while building llvm, so I guess we can't use it in our projects which are build using clang? Or can we?

[@AlfredoCorrea]

I think you are confusing the building of the compiler with the compilation of your code using of the standard library (libc++). You can still activate the hardening for the code you compile.

[@adamrushford]

declassified and disseminated apparently... this is my meat and potatoes right here... god I'm an idiot for wanting to make games, being so young I started with C++, being so old that I can't switch away, and stupid enough to attempt what all other companies seem to have proven impossible

[@perghosh8135]

BigTech companies do not want competition. This is the reason why move away developers from C++.

[@tikabass]

Hardening techniques haven't changed in 40+ years. The main security issues come from young inexperienced programmers who truly believe they can code like Turing in person right out of school when they obviously can't, lack of proper training in said schools, and lack of supervision.

[@szaszm_]

You can't blame everything on the individual. Even the most experienced programmers make mistakes. Sure, inexperienced programmers make more of them. But either way, when tools make it easier to avoid or catch those mistakes, less of them will end up in production. I'm aware of my limitations in spotting bugs in review, and I would take these extra safety guarantees any day over not having them. But in my experience, those who are the most confident in the perfection of their skills tend to perform the worst.

[@vasiliigulevich9202]

Wrong. The issues are caused by managers, who assume that a cheap hire can author reliable software in a language with undefined behaviors. Therefore, the hardening techniques have changed - system level is now considered elite, and script kiddies do not touch C.

[@tikabass]

@@szaszm_ I am blaming academia. Youth will always be youth and have faith in their infallibility.