My first talk is now on YouTube: Secure Coding Best Practices. In it I discuss how C++ is an inherently safe language but how we use it often isn’t. We also look at modern day countermeasures and best practices for producing code that isn’t vulnerable to hacking. I also walk the audience through a buffer overflow exploit and do it live in a VM.
This talk was discussed in two trip reports from C++Now by Bob Steagall and Eva “Bunny” Conti.
And it was also discussed on Episode 151 of CppCast about 9 minutes in.
Abstract:
Computer systems are under siege 24 hours a day, day in and day out. The critical security infrastructure designed to protect those systems, won’t:
- Perimeter security won’t protect you.
- Network analytics won’t protect you.
- Virus scanners won’t protect you.
- Even the users who should know better than to click on that too-good-to-be-true offer won’t protect you.
The other side has the best security hardware and software systems other people’s money can buy and they have all the time in the world to find creative ways to defeat them. Meltdown and Spectre are prime examples of security vulnerabilities that have lurked dormant for decades. Or have they? If your systems are in any way connected to the outside world, the other side will get inside the wire on you. Know that going in.
Whether you write applications, libraries or work in kernel code, the line of code you write today may very well be the vulnerability someone else finds tomorrow. By nature every code base contains hundreds of attack surfaces and it only takes one serious vulnerability to compromise your system.
But what exactly is an attack surface?
While Modern C++ is designed to be secure, the ways we use it often aren’t. And with each vulnerability comes new questions:
- Is it serious?
- If I fix it, do I take a performance hit?
- How do I write efficient, scalable code that’s also secure?
- How do I know which vulnerabilities will compromise my system and which ones are a low enough risk?
Yes, there are trade-offs. We make them every day and security is no different. In this talk, we’ll look at the ways our software often fails. We’ll walk through code samples to uncover their silent vulnerabilities and show how to correct them. And we’ll discuss what trade-offs we can make to balance security vs. performance. Finally, we’ll look at ways to deal with those threats starting at design time, baking security directly into the code from the very first line.
The critical security infrastructure designed to protect your systems is largely out of your control. The one thing you can control is the next line of code you write. This talk is for anyone that uses C++ or Modern C++ for kernel, applications or libraries that run in the real-world and that face real-world attacks.
In today’s world, that’s all of us.
Eratta:
@ 15:38, I said that std::string’s small string optimization might have been lost due to move semantics. It’s actually std::vector’s small vector optimization was lost due to move semantics because it invalidates the iterators. The small string implementation on a 64-bit machine is 22 characters. After that, it’s heap allocated as I stated.
@ 20:20, slide #20 had a code error where I did not include std::back_inserter() in the copy. The line should be: std::copy(src.begin(), src.end(), std::back_inserter(dest)); You can also use direct construction here by passing src to the vector’s constructor like this: std::vector
@ 49:40, I said that popping off an empty vector throws an exception. Instead, this is undefined behavior as pointed out by a member of the audience. You will get a segmentation fault (Linux) or an access violation (Windows) doing this, not an exception. The practical impact is the same, seg faults, access violations and unhandled exceptions all cause abnormal termination. All three can the handled but in different ways. A surprising number of software developers I spoke with at the conference thought the same thing I did so great catch by the audience.
