CppCon 2018: “Secure Coding Best Practices: Your First Line Is The Last Line Of Defense (2 of 2)”
HTML-код
- Опубликовано: 17 сен 2024
- CppCon.org
Matthew Butler “Secure Coding Best Practices: Your First Line Is The Last Line Of Defense (part 2 of 2)”
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/Cpp...
-
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.
While Modern C++ is designed to be secure, the ways we use it often aren't.
In part one of this talk we'll see:
* How hackers think and how they identify weaknesses in our systems.
* How to identify hidden attack surfaces, attack vectors and vulnerabilities in critical systems.
* Where the most common vulnerabilities in Modern and classic C++ are and how to avoid them.
* Why avoiding parts of the language doesn't help.
* Where we can trade off security for performance.
At the end of part one, we'll do a walkthrough of a classic buffer overflow exploit to see how it works and what we've added to the operating systems and compilers to protect against them. Then we'll use it live to run a privilege escalation exploit and gain admin access on a system.
In part two, we'll see:
* Why common guidelines and static analysis tools often fail to find vulnerabilities.
* How to use Threat Modeling to analyze complex systems and built security into our systems at design time.
* How to use Trust Boundaries to protect critical infrastructure.
* Why open source and third-party libraries are fast becoming hidden liabilities in our software and how to protect ourselves against their vulnerabilities.
* What the best practices for protecting our code from attack are.
At the end of part two, we'll do a walkthrough of an exploit that can be successful today in spite of the safe guards built into our operating systems and compilers. Then, as before, we'll use it live to penetrate a system.
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.
-
Matthew Butler
Matthew Butler has spent the last three decades as a systems architect and software engineer developing systems for network security, law enforcement and the military. He primarily works in signals intelligence using C, C++ and Modern C++ to build systems running on hardware platforms ranging from embedded micro-controllers to FPGAs to large-scale airborne platforms. Much of his experience has come in either building systems that defend against attackers or building highly sensitive systems that are targets. He is actively involved in the C++ community and is on various planning committees for C++Now and CppCon as well as being a speaker at both.
Over the past thirty years, he has learned the harsh lessons on how we often write systems that fail, not because they don't scale, but because they aren't designed to be secure.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/reg...
*-----*
Fantastic pair of talks.
1:30 another thing he said, is "If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle. Hence to fight and conquer in all your battles is not supreme excellence. Supreme excellence consists in breaking the enemy's resistance without fighting." - This is also true about making a secure system. If you don't know how a Hacker thinks, you are going to have a hard time making your system even a bit secure, possible, but hard. If you don't know any side, you're going to be an easy target. The last part is even more true. If you break their will, e.g. by having a weird network architecture, or a honey pot (network), you can already do a lot.
"Water shapes its course according to the nature of the ground over which it flows. The soldier works out his victory in relation to the foe whom he is facing. Therefore, just as water retains no constant shape, so in warfare there are no constant conditions." - Hackers are always going to use the easiest point of entry in your system, not the strongest, they are also going to change strategies if one doesn't work.
This is why including C headers should be compiler warnings unless an -I-promise-I-know-what-Im-doing flag is passed to the compiler.
And then someone will make a commit to the main header file without a comment:
#DEFINE -I-promise-I-know-what-Im-doing
Sadly no mention of how to secure your code if you're developing for Windows. Nothing about crtdbg.h (making memory leaks insanely easy to find and fix since about 1993), secure C runtime functions (strcpy_s, etc), enable warnings about not using secure C runtime functions, making those warnings errors so insecure code won't compile, SAL, Code Analysis, etc.... These things are built into Visual Studio, no need to go install half a dozen other packages...
Excellent feedback, thank you. I do cover those when I do training along with the analogs for Linux. Unfortunately, with the time I had I did a more general talk that applied to secure coding on any platform. Sounds like a great follow-on for next year, though. Thanks again for your feedback.
Good idea! Secure secured data with more secure functions to check on whether the other secure functions are actually secure, and if they are not, just use more secure functions, because that should in theory make the insecurity packed in securely, at least. Security is so easy.