CppCast - Secure Coding

Episode Date: August 8, 2019

Rob and Jason are joined by Matt Butler to discuss his perspective on the ISO Cologne meeting and Secure Coding. Matthew Butler is a security researcher who has been using C++ professionally since 1990. He has spent the past three decades as a systems architect and software engineer developing systems for network security, law enforcement and national defense. He primarily works in signals intelligence and security on platforms ranging from embedded micro-controllers to FPGAs to large-scale, real-time platforms. He is on the staff of both CppCon and C++Now as well as a member of the C++ Standards Committee. He spends most of his time in EWG, SG12 (Undefined Behavior and Vulnerabilities), SG14 (Low Latency) and, now, SG21 (Contracts). He is also a member of WG23 (Programming Language Vulnerabilities). He prefers the role of predator when dealing with hackers and lives in the Rocky Mountains with his wife and daughter. News What happened to C++20 Contracts? Fixing C++ with epochs Child Care at CppCon Matt Butler Matt Butler's Blog Links CppCon 2018: Matthew Butler "Secure Coding Best Practices: Your First Line is the Last Line of Defense" C++Now 2019: Matthew Butler "Secure Coding Best Practices - Threat Hunting" P1705 - Enumerating Undefined Behavior Sponsors Errors that static code analysis does not find because it is not used PVS-Studio in the Clouds - Running the Analysis on Travis CI Hosts @robwirving @lefticus

Thank you. sponsored by cpp con the annual week-long face-to-face gathering for the entire c++ community come join us in aurora colorado september 15th to 20th in this episode we discuss the idea of C++ epochs. Then we talk to Matt Butler. Matt talks to us about first podcast for C++ developers by C++ developers. I'm your host, Rob Irving. Join my co-host, Jason Turner. Jason, how's it going today? I'm all right, Rob. How are you doing? I'm doing good. I had a date night with my wife last night. We went axe throwing, which is something we've never done before. It was quite fun.

I have never tried that either. Did you go to a special... Did you have axe throwing in your area? Well, I mean, at the Renaissance Festival, it's definitely something you can do. Oh, okay. No, they have like a bar in Durham, I think a different one in Raleigh. And we went to the Durham one. It was pretty good.

I actually did do a little bit of research to see if I were to do axe throwing in my backyard, is that illegal inside city limits? And it does seem that there is the good possibility that it would be considered illegal. Like if that ax went astray and someone got hurt, I mean, like, you know, akin to using a deadly weapon in your, in your property, basically. Sure. I mean, what if you have it like fenced off or something like that? How much research did you look into this? I don't remember. I think I gave up after like an hour or something. And I don't know.

It's easy enough to just drive into like national forest or, you know, public lands where you could do something like that. Anyhow, it's no problem in the U S we guys, we have lots of public lands. This is true. Well,

I'd recommend you trying it. It's fun. Okay. Does that sound like fun? Yeah. Top of Arizona. Like to read a piece of feedback. Uh, this week we got a tweet from uh barney deller saying i really enjoyed the latest cpp cast with claire mccray i'm particularly pleased to see testing finally starting to become a normal part

of c++ culture and yeah i certainly agree and i kind of wonder about that statement like is c++ testing not as widespread compared to other programming languages and their you know culture around testing i think people who test test and it doesn't matter what programming language you're in that is my impression as a teacher talking to people who are moving from other languages to C++. But there are definitely some languages that have always had like unit test built into the language core feature. And I think we're kind of, you know, reaching the point where it is more and more normal. And C++, we're somewhere in the middle ground, in my opinion. Okay, I hadn't heard of that about testing being kind of built in as a

language feature. What languages have that? Well, there's stuff that makes it really easier, right? Maybe I'm getting some stuff wrong here, but inUnit with the.NET frameworks is really easy to use because it can be easily integrated in with the runtime, the CLR. And JUnit with Java, similarly, no, those aren't core language features. It's true, they are uh things that are really really easy to work with anyhow yeah well yeah i definitely think it's a good thing that we should all be doing more testing and uh yeah it was great talking with claire last week about approval test because that was completely new to me i believe it was new to you as well

right jason yeah i totally learned a lot and um I wish I could have gone back in time and shared that with the class that I had just had before that talk. And yeah, I actually had a discussion with my last class after that talk about the kind of tests that they're doing. And it seems that they're basically already doing something like approval tests there. Okay. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us a review on iTunes and subscribe on YouTube. Joining us today is Matt Butler. Matt is a security researcher who has been using C++ professionally since 1990. He has spent the past

three decades as a systems architect and software engineer developing systems for network security, law enforcement, and national defense. He primarily works in signals, intelligence, and security on platforms ranging from embedded microcontrollers to FPGAs to large-scale real-time platforms. He's on the staff of both CppCon and C++ Now, as well as a member of the C++ Stands Committee. He spends most of his time in EWG, SG12, SG14, and now SG21, the new contracts group, and he's also a member of WG23, which is Programming Language Vulnerabilities. He prefers the role of Predator when dealing with hackers and lives in the Rocky Mountains with his wife and daughter. Matt, welcome to the show. Hey, guys. Thanks for having me on. I'm happy to be here. Matt, I have to take issue with your bio here because it says you've been

programming professionally in C++ since 1990, but as we all know, C++ was first released in 1998. The versions we have now, yeah, but there were one-off versions that you had earlier than that. But yeah, you're're right what we have now is definitely a 1998 yeah i'm just giving you a hard time of course as far as professionally programming yeah it's been since 1990 since so you must have uh had some serious growing pains as i mean because if you were 1990 you you didn't have namespaces you didn't have the stl you didn't have necessarily you had pieces of these things, maybe. Yeah, no, it was the Wild West back then.

I started out in college, and it was all C. So when this language came out and I bought this book on C++, there was sort of this, I have no idea what this means and how this works. And so it took me about a week of reading and rereading this book and going through the examples to it, finally clicking what object-oriented programming was all about. And ever since then, I was hooked because it just made so much sense at that point. So just out of curiosity, do you remember what that book was? I don't. And every time I bring this up or say this to somebody, I always tell myself,

I'm going to go back and look and find out what that book is, but it was 30 years ago. I mean, it was a long time. Every now and then I go to Goodwill or something, and I go trolling for old C++ books just to see if I can find something really old. And I've been successful once and didn't buy the book, and I should have. But anyhow. Well, I definitely prefer the modern versions of C++, so I'm happy with the new books. Yeah, for me it would be an exploration of

if the stuff that they were teaching then was even bad practice then on the compilers back then, which I think in many cases it was. Like, empty destructors has always been a bad idea. If you didn't have a reason to declare that destructor virtual or something, just having an empty destructor, it's always been a bad idea. If you didn't have a reason to declare that destructor virtual or something, just having an empty destructor, it's always been a bad idea. I guess in full disclosure, I should mention Matt is also a member of my C++ meetup, although at this point I don't know if he's actually attending it more often

than I am with my current travel schedule. I was there last time. And I was not able to attend, yes. Okay, well, Matt, we've got a couple news articles to discuss feel free to comment on any of these and we'll start talking about you know your background as a security researcher and the talk you'll be given at CppCon okay okay sounds good

cool so this first one is a bit of C++ committee drama unfolding on Reddit. We spent a decent amount of time last week, or I guess two weeks ago, talking about contracts being

removed from C++20 at the clone meeting. I guess one of the authors of the original contracts paper wrote this long post on Reddit CPPpp what happened to c++ 20 contracts um and basically complaining that it wasn't removed for a technical reason and i'm definitely interested in hearing your take on this mass since you're now a member of

this new contract study group yeah so we had our had our first meeting this morning for SG21, which is sort of a kickoff meeting for before there wasn't a study group that handled contracts. It was pretty clear going into Cologne just by looking at the reflector that there was quite a bit of back and forth. And typically when you're this close to a release,

you're not wanting to put in any kind of design changes. So a lot of the conversation was about are the changes that people are proposing, are they design changes? Are they just wording changes to try and make things more clear or to tighten up on the feature itself? Monday when we went in, it became clear that, you know, the first vote we took was, do we even want to consider these? And I voted yes, because I think you should consider things even up to the last minute. I actually did have some technical concerns about contracts. We can talk about that here in a little bit, mainly involving security and safety. Then it went on to these were voted in.

And I think that sort of at the end of Monday sort of was the end of contracts coming out in C++20 because there was enough contention on both sides of is this really what we want to do? Do we feel comfortable with what we're putting out there? By Wednesday there was a proposal on the table to remove contracts altogether. I voted against that because I was while I wasn't happy with the current implementation, I do think that there's value in going ahead unless you can come up with absolute stop ship bugs in a feature, go ahead and put it out. Let's get some experience with it. I think that was

probably the most compelling reason to put it out there. And then eventually in the end, the vote went strongly the other way to pull it out. And can understand that there are strong emotions on both sides. That sometimes happens. We saw that with several other features that had to be removed from a standard just before they were due to go out. Then they came back stronger. So that's what I'm thinking we're going to have here is we're going to come back with a much better feature that will be much more useful to the everyday developers. And one of the places we're starting now is we're building all of the use cases as to what do we want contracts to cover, which use cases fit into a's mold. So while it's probably not the ending everybody wanted, I think we're trying to find the right path through and get a really strong feature the same way we have with concepts. So at the moment, are you looking at starting from scratch or looking at starting from where

it was last left off? So right now what we're looking at doing is taking the use cases. I don't think there was ever really a consistent, a broad agreement on what the use cases are that contracts should be able to handle. So right now we're looking at generating all those use cases, going through refining them, and then coming out with a set that says, okay, these are the use cases where we feel contracts apply. And then take those use cases, go back and look at the various proposals and see how they match up against those proposals. Technically, we sort of have a blank slate at this point, but I think we'd all rather take advantage of the last five years of learning and understanding when it came to contracts and see what we can bring forward into the future with us.

So that's where we are right now, and we're working on that for the next several months. I'm not going to ask you to specifically comment on some of these things in here, because I know there's the code of conduct for the members of the committee and commenting on who said what about what thing I do. Well, the actual Reddit article itself is, I guess, strongly worded in some some places implying that they were people who set out to you know sabotage the proposal from the beginning um and that there was originally 2012 and 2014 and that has this really long history and if you read the comments which i read almost all of them it's all people that we know on this discussion. It's all people who are friends of CBP cast who have been on here before. And I think for people who are just kind of interested in the human side of being on the committee, there's, it's just a reminder that there's humans that work on this. It's, it's not automatons who work on the committee, and there's a lot of humanity involved in the process, it seems. Yeah, absolutely. And even if there wasn't a code of conduct,

it's not really fair to quote people who aren't there to sort of say, hey, no, that's not really what I said or what I meant. Right. So, yeah, this is a very human story, if you were to write about what went on in the back end. And sort of as a new member of the committee and sort of not having been involved in this all the way, it was what I was expecting and it wasn't what I was expecting. By what was going on in the reflector, I sort of understood there was going to be a lot of contention and we were going to have a hard time getting consensus. But I will tell you that there are some people who really, in this drama, as you put it, that really stood up and I think made a huge difference. And they I will name.

So Herb, I think, helped get the process through with a minimum amount of collateral damage. Vili, I think, did a fantastic job. He does a fantastic job just running the group because you can be dealing with things and they're very contentious and you do need that strong person who can sort of keep good order and discipline. Michael Wong came in on Wednesday night and was helping to see if there was a path through it to where we could maybe find that we had common ground, which is what we could go forward with. And I wasn't in the room at the time because I'm not part of either of the proposal sets. But from what I understand, he put on a master's class in negotiations and both sides said that. So you definitely had people that were sort of containing this. And finally, in the end, nobody likes to see five years worth of work have to sort of come to a

stop. You do want to have that Hollywood ending where it goes out and people use it, and it's great. But as I said, even I had some technical concerns over it. I just didn't think at this point that there was a compelling reason to stop it. But other people felt differently. But yeah, there are strong emotions, and over time, hopefully those will begin to abate. I certainly can understand Nathan's position because he's been at this for a very long time yeah it sounds like uh i didn't

realize that this person had been involved in it for yeah five years or whatever um i guess it's that's that was before we started the podcast yeah ish or about the same time about the same time okay we sell the same thing with concepts because it was something that came, had to be, you know, they had, they thought they were ready and then they didn't have consensus. They had to pull it out. And then they came back with something that I think the guys talked about last week that I think they're happy with, which is really what you're looking for. You're looking for people to come out and say, yeah, this is exactly what we think it needs. We're 95% away there. Yeah. I certainly hope that, you know,

this committee group that you're a member of does a good job and we are much happier. The whole committee is happier with contracts that we get hopefully in three years, but we'll see what happens. Next article we have is fixing C++ with epochs. And this is from Vittorio Romeo, who we had on the show a very long time ago. A long time ago. Yeah, and he's putting forth this idea inspired by Rust editions that he's saying is now possible

when we have modules to be able to basically have libraries opt in to use a certain version of C++ and kind of make the ability of the ISO committee to introduce breaking changes, you know, more, more easy, more, more doable. I thought it was an interesting idea. Yeah. Yeah. Yeah.

There's a lot to like in this, in his piece. At the end he said, you know, he'd be, he said he'd be willing to do a committee proposal. Yeah, I will go ahead and channel Herb Sutter. We look forward to your proposal. I think it's a great idea, but the details are the place where we tend to get stuck on things. So I would love to see that because I think that's one of the problems we run into is, well, how do you deprecate this? We're going through that with volatile. We're deprecating parts of volatile, adding things.

So it does become a very complicated process to be able to come up with the next generation of the standard where you've got things that are moving in and out. So I'd love to see it. I honestly like the particular things that he wants to do. Replace initializer list with something that allows moves. Yeah, I'm on board with that, but you know, whatever. Like, I mean, I've given an entire hour and a half talk about how initializer lists are broken because we can't move from them. So I get that.

You know, remove type def, be able to introduce a weight and all of those. I'm like, yeah, that's all good. But then when it gets down to the more drastic changes that we could consider const by default and you have to opt into mutable, no discard by default and you have to opt in with discardable, make explicit the default and you have to opt in with implicit. I am on board with all of those i want that like yesterday but those are also all things that we can do with static analysis we i mean we do it right now we can warn you if things are not no discard and could be things that are currently

implicit and could be um uh it marked explicit that kind of thing, too. But, yeah, I don't know. And I should mention, one of the things he's proposing in this is to be able to script going from one version to another or one epoch to another. So if you have something marked, you know, no discard, to be able to just take that out because the default would become no discard, something like that. Right?

Right. Well, and that's where the details become important because I can see some of the things you just listed off, mainly at the end, being a little controversial. So that's where you get the details. That's why you need the proposal. Yeah. Okay, and then the last thing, CppCon is coming up.

We've been talking about it a little bit more lately, and we just wanted to point out that if you're attending cvp con they're now offering uh child care if you're going to be traveling to the conference with your kids yeah the only problem is that the child care facility they're using is about 20 minutes away from the actual gate lord um but uh and there's a limited number of child places available. So if you're interested at all, make sure you go ahead and sign up for it. Make sure you utilize this. We want to encourage the conference to make this thing available next year as well and perhaps make it more convenient if at all possible.

Although I don't think the Gaylord has child care facilities on site, so I don't know how much more convenient it could be. I know people who have seen pictures of the Gaylord immediately say it's in the middle of nowhere. And I, you know, I've gone on record of already saying this, I just want to clarify, it's not in the middle of nowhere, it's just on the edge of nowhere. It is. You've been there, Matt. Yeah, that steep drop off is the edge of town. So yeah,off is the edge of town. But if you've ever wanted to go to a one-of-a-kind conference center to go to CppCon, this is it. This is like a playground. It's a fantastic venue.

It is absolutely beautiful. And there's giant, indescribably large picture windows that face right at... Actually, where do they face? Is that Long's Peak they're facing at? Anyhow, one of the peaks, and it's amazing. Yeah. Okay. Well, Matt, do you want to start off by telling us a little bit more about how you got involved in C++? Well, when I was in college, it was all C, and you used Pascal and a bunch of other LISP.

And there comes a point where you're looking for something that's a little stronger when you're creating large code bases. And one of the first jobs I had outside of college was creating a system that allowed you to do bank failure analysis. And that requires a lot of math and a lot of moving parts. And C++ became a much better choice than trying to do it in C or Fortran. Fortran is very good at numerical processing, but back in the day they didn't have object orientation like they have now. So I found C++, and it was like, this is perfect. And I did what everybody else did when they first started with C++,

is they started building these really deep hierarchies of objects. So you have these inheritance hierarchies that were miles tall, and then you quickly found out after having to maintain the code for a couple of years that that was not a smart idea. A flat hierarchy works a bit better than these mountains of inheritance classes. What does bank failure analysis mean? So one of the problems we have with banks is they generate a lot of numbers. So there's a lot of metrics like their income and earnings and things like that. But the problem is, how do you and they have a lot of so there's probably about 200 different things that a bank has to report to the Fed that has to do with their health. So the problem becomes, how do you look you look at that data and draw any conclusions as to which banks are close to failing and which banks are really safe?

Because if you just look at this minefield of data, there's no way to really tell which banks are having a problem. This was right after the S&L crisis where you had a lot of zombie institutions which looked really good on paper, but the minute that the interest rates flipped on them, they suddenly started failing left and right. So the Fed was really concerned about being able to look at the data and make some, because they had scarce resources, make some determinations about which banks they would actually go and audit, just based on their numbers. So the bank failure analysis was really a way of going and looking at those numbers and finding, believe it or not, we used earthquake analysis for it, which was sort of strange, but it worked beautifully. I mean, we had a really high success rate of being able to predict

which banks, 6, 12, and 18 months out, were going to find themselves in trouble. By looking for tremors? Exactly. That's what you're really looking for, is you're looking for little things that are sort of hidden and things that aren't particularly obvious. But if you let the numerical analysis do its work, you find that it will spot things that you don't normally see. And that's how I got into signals intelligences, because you're really looking for the pieces of the signal that tell you something but are sort of lost in the noise of the background. All right, so I'm going to go ahead and ask this,

although it kind of sounds like you already answered it. How then did that C++ with bank failure analysis move into your interest in security? Actually, that had nothing to do with it. I went to, as soon as I got out of that, that was how I put myself through graduate school. And then when I got out of graduate school, back then it was called Information Systems. So it was an IS shop. And I worked there for a few years, did C++, several other languages. But then my next stop after that was a company that did defense work.

And so in order to be able to work in that, you have to have a clearance. And suddenly everything is about security. And if you're working in a SCIF, which is a classified facility, there's all these processes you have to go through. And then, of course, they have to do this massive background, you know, going back to birth to make sure that you're okay. And it was really there and living in sort of that where you're developing systems that now become targets

for people looking to get in. You know, if you go back and look at the cuckoo's egg, that was sort of like even back in the war games era where you had a hacker from Russia trying to use all of the Berkeley computers to jump off into all of the military sites to be able to gather classified information and bring it back. We were really naive at that time about security. And at that time, the only people who really got hit by any kind of intrusions were military facilities or later on it would wind up being their contractors because people realized that they had weaker security than military sites did. So that was where it began.

And I would work – the next job after that would be in network security where I was writing software that was specifically designed to defend networks from attacks. And then after that would be another cleared capacity where in one case, they had no network when I walked in, they just had a bunch of machines and a work group. So I put in a domain controller, but my IT budget was exactly zero. So there was no parameters, no perimeter security or anything. And we got hacked by russia and china in the same month and i was the one who had to call the fbi and so that was sort of the the way that sort of i had to really just in both cases sort of learn while under fire it sounds like a bad week at work if your job involves calling the fbi

yeah they were very understanding the first time. The second time, not so much. And then they wanted to come and help us, which I was defenseless to protect our network because I had nothing that I could use. My boss at the time freaked out when I said, oh, yeah, the FBI will be here tomorrow. They want to talk about our network security. And he absolutely lost it.

We are not having the FBI in here. It's like, well, you've already had Russia and China. So why not? So so most of where I got into security was really sort of being on the receiving end of the inbound ordinance. And after a while, you realize, no, there's there's a better way to do the things we're doing. And so many of the things we do are just self-inflicted wounds because people don't really understand that security is not that difficult to understand as a concept. You just

have to have it in the back of your mind when you're either building a system or writing code. I wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high quality code as well as the methodology of static code analysis. In their blog, you'll find many articles on programming, code security, checks of open source projects, and much more. For example, they've recently posted an article which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly use static code analysis. Speaking of which, another recent article shows how to set up regular runs of the PVS Studio static code analyzer on Travis CI. Links to these publications are in the show notes for this episode. Try PVS Studio. The tool will help you find bugs and potential vulnerabilities in the code of programs written in C,

C++, C Sharp, and Java. So let's go into more of writing code and how you can do that with security in mind. What are some of the topics you talk about with C++ and security? So one of the things that I was, I read that Twitter comment that you got that you talked about at the top of the show. I think testing sort of becomes, it depends on your value proposition. We as engineers have a tendency to be very focused on designing and building things. And then we test

it and we're happy with it. And we tend to test just the happy path. We don't tend to think about software in terms of, and it doesn't even have to be someone trying to exploit your code. It could just be somebody accidentally using your code incorrectly. So you're building a library, you've got an application, and they do something you don't think that you didn't consider that they would normally do. So I learned a long time ago just from being on the front lines of this that an excellent QA organization will save you every single time because they will find the things you don't think about. They're experts at doing that. So I really appreciate the fact that there is a value proposition,

and I see this a lot in C++, is that we're so focused on other things we don't think about testing. And I appreciate the fact that we've got people like Phil Nash who are showing us how to do unit tests. One of the things I talk about in my class coming up at CPCon, the entire second day is nothing about testing, nothing but testing strategies for how do I take my code that I've got this wonderfully designed piece of code, now how do I go break it? But how do I break it in a controlled banner so that I know I've checked all those corner cases? And so we start with things like threat hunting,

which is a threat modeling of a system, which is a way of looking for attack surfaces and attack vectors. But it actually also has a lot to do with how well is your system designed? When I go through this with a team, I'll hear comments like, oh, I didn't know that's how that worked. Or why are we holding that data? We're not actually using it anymore. So

you go through this analysis of your architecture and people will find that there are things in there, especially as architectures evolve over time, there are things that sort of get lost to antiquity. I just had a case where I found a feature that had a major security vulnerability in it that had been put into a product over a decade ago, and nobody knew it was there. It was listed in the documentation in sort of an orthogonal way, but until I looked at the code, and I was like, what are they doing here? And that's where you get into some of these testing strategies and looking at your architecture. Then after that, the next step you want to do is things like we've talked about

static analysis, and that's where contracts is going to help. We have dynamic analysis where we're looking at looking for undefined behavior. You're looking for thread problems. So you've got sanitizers that you can run against operational code, but in order to have those work correctly, you have to have a really good test set to make sure you're catching all those corner cases. You've got as much coverage over your code as you possibly can. And then, of course, you've got things like fuzz testing and penetration testing,

which is actually really the fun part. I'll have to admit, in all these years, I much more prefer playing offense than defense, because it's just really a lot of fun to break things. So we've done a backdoor introduction to your class. Why don't you go ahead and actually tell us the name of the class, when it is, that kind of thing. Okay, so the class is, in fact, it's at the same time Jason's teaching his class. Uh-oh.

Uh-oh, yeah. It's called Exploiting Modern C++. And I've had some people come up and say are you going to show us how to exploit modern C++ yes, sort of what I'm really going to teach you is how do you go and do a code review to find the deeper bugs we do, I think as an industry a somewhat poor job at least in the companies that I've been involved with,

of doing code reviews that are something more than variable names and line lengths. If something's really obviously wrong, we'll catch it. But what we're really looking for is catching those deep bugs that maybe are not quite so obvious. Like one of the first things I teach people is you go in. The first thing I look for is, where are you touching memory? Because you're almost always going to get that wrong. That's where you have

off I1, buffer overflows, code pointer exploits. These are, and you just sort of begin to, over years, begin to sort of pick up the, sort of how that, how code gets written and how these mistakes get put in. So, Exploiting Monitor C++ is not about teaching you how to be a hacker. What it is is it's about

teaching you how to write software that is correct, that is well-structured and well-architected, giving you testing strategies on how to test your code to make sure it's not going to fail in the field. Whether it's a hacker or somebody else that makes it fail,

we all want to produce code that is going to do, it's going to stand up and do everything that we need it to do, and we have very few bugs going out the door. And so these are the strategies sort of from an end-to-end, from architecture to release that we're going to be talking about in this class. So it's a two-day post-conference class? It is a two-day post-conference class.

And who should take this class? It's hard to class? Yeah. Well, if you, it does not have to be anybody who has even an interest in security. I mean, this is security is sort of the, the aspect that I come at it from, but if you have any interest in producing well-constructed code, that's been thoroughly tested, that you know going out the door, you've done a really great job on code review, so you've caught majority bugs. Now you want to know how to use static analyzers. What are their strengths? What are their weaknesses? What kind of dynamic analyzers are out there that you can use? How do you set up a test plan to make sure

that what you're doing in those dynamic analyzers is going to get those bugs that are deeper than the code reviews are going to find. So it's really for anybody that wants to produce high quality code going out the door, whether you're worried about hackers or not. This is really about writing code that withstands sort of living in the world where there are hackers, but there are also users that will do things with your products and your libraries that you weren't expecting. So if you want correct code, you should take your class. If you want correct, well-tested, hardened code that can withstand the punishment of the world

that you're going to release it out into, yeah, this is a great class to take. All right. Okay. In addition to your class, you're also giving a talk at CppCon this year? Yes, it's called If You Can't Open It, You Don't Own It. It's going to be a little bit different than the talk that I gave at CppCon this year? Yes, it's called If You Can't Open It, You Don't Own It. It's going to be a little bit different

than the talk that I gave at C++ Now. I'm taking four, what I think are legitimately called super hacks, involving hardware. So we all know about foreshadow and a lot of the side channel attacks that we have seen. We all know about foreshadow. I do not know about foreshadow. Okay, so, well, it's a derivative of the side channel attacks that we have seen. We all know about foreshadow.

I do not know about foreshadow. Okay, so, well, it's a derivative of Meltdown. Okay, we do know about Meltdown and Spectre, yes. And Spectre. So these are all side channel attacks. But hardware is particularly vulnerable to side channel attacks because it emits a lot of things. And so what I do in that example is I take a side channel attack

and say, okay, this is how you would do this against hardware. How does this apply to your software? And then we're going to begin looking at C++20 because it's coming out the door next year. What are the things that are in C++20 or in 17 or some of the other revisions that can either help you or hurt you when it comes to security in your products. And we'll deal with other things like roots of trust, which is, you know, we have sort of this implicit trust relationship. Hardware is specifically vulnerable to that, but software also has that as well. And we'll look at how these things begin to, the lessons we can learn in software, specifically C++, and then how the new language features coming out are,

or the ones that we're considering for the future releases can help us in dealing with some of these vulnerabilities that we have. And it's no small irony that, you know, Capital One just now became the poster child for the worst hack in the world. And that was an oversight. And that's the thing that I always teach students. Everybody will ask me, is C++ a safe language? And my answer is, yes, if you know how to use it. But in reality, it is not the big things that get us. It's not your failure to do template

metaprogramming correctly. It's not your failure to whether this constructor had an implicit conversion. It's those little things where we don't validate data. We forget that the buffer is really only so wide, and we put more data in that can fit there. We don't check the values coming in before we put them into a strongly typed enumerations were created in order to help us deal with the fact that you could have undefined behavior with just putting a value too large for an enumeration in there. So there's all these little small things that we do that sort of become the gotchas. And if you go back and look at Equifax, you go back and look at what happened with Capital One last week, or it's been a couple of months, they just announced it. It's those little small things that wind up burning us. It's not the, oh, the language has a massive vulnerability in it, we need to fix the language kind of thing.

So if you can give us a sneak peek, you said you'll be covering some of the C++20 things. Is the language getting better or worse from a security perspective? So one of my biggest concerns about contracts was where contracts are really a statement about what should be true. But in the software, the problem is you live in a world where almost nothing is true. Most of what you will get is exactly what you don't expect. And in contracts, one of the features of the current contracts was, what happens when a contract fails? Well, it calls a handler, and then it calls terminate. That right there is just a DOS attack waiting to happen,

because it really doesn't matter how deep in your code it is, as long as I can trigger that by fuzzing your interfaces, then now I know that I've taken your software down. I just keep doing that over and over and over again. Now that's a denial of service. Denial of service attacks usually tend to be masks for other things that are going on in environment because you're focused on why is this crashing. The next step in that, though, is there is this concept of continuation.

So in other words, the contract fails, but you've said, no, go ahead and continue. Well, in reality, that makes the contract meaningless because it's no longer true. You have something that has failed, but you're going to continue anything. So everything after that is now suspect. I mean, if your contract is a null pointer and you tell it to go ahead and continue, well, then what happens on the other side of that continuation is you've still got a null pointer wreaking havoc in your code. So some of these things, and there was other places where we were introducing undefined behavior. And where I see undefined behavior, that's where I start as somebody who likes to

penetrate systems. Whenever I see undefined behavior and I see somebody's using a feature that has undefined behavior in the code, that's the first place I want to attack. Because I know at some point in time, they're likely to trip over that. And if I can make it go into undefined behavior, again, I can make the system go down. And that's one of the problems we run into, especially on the hardware side, is that you're talking about systems that are fairly critical. You know, somebody's pacemaker, an airplane, you know, things that you really don't want the hardware going into reset on. So that's one of the reasons why things like exceptions don't get used in hardware at all. It's not just that they have overhead associated with them.

It's the consequences of throwing an unhandled exception in the hardware world are pretty horrible. So with concepts, I had sort of some of these concerns of, okay, we're going to put this out there, and somebody's going to go put this where they are trying, they're going to use contracts to try and analyze data from an untrusted source. And we have to educate them, but then that education tends not to sort of take, and you find people in critical systems at a bank or somewhere else using this particular feature inappropriately and in the wrong spot. And then suddenly you have a breach like this or you have something horrible happen to people. One of the things that I really liked is contracts, because I think I heard you say this on the last show, is that contracts help with correctness of a program. I like the fact that rather than me sending something in that may or may not fit what that function really wants, I like the fact that there is a defined contract that can come in and say, this is what you have to give me in order for me to operate correctly. And that way I know

as a developer what I should be sending them. We have a couple of proposals on the horizon. I'm going to look at my list here. One is secure clear. So one problem we run, we've seen this quite a lot, and this is a side channel attack. I bring in a password, I unencrypt it, I use the password to log on to whatever asset that I'm trying to get to. I go in and I clear the memory, and then I go on. I think I've cleared the memory, but the compiler looks at it as, well, there's no side effects to the clear because you're not using it again. So I don't have to do the clear. It helps me optimize your software.

The problem is that is now sitting out there in memory where it can now be read using a side channel attack. So each of the different vendors came up with their own version of SecureClear. And SecureClear just sort of puts it in the language so that now we've got a platform in an independent way of when I have some vital piece of memory that I absolutely positively need to clear, I can use SecureClear to do it. And to be clear, that's not in C++ 20. That's a proposal upcoming.

It is a proposal that I like coming up in 23. The other big one that we discussed a lot here in Cologne was the zero overhead abstraction of the zero overhead determinants exceptions throwing values. Oh, that's Herb's, right.

Herb's exceptions. Herb's exceptions. It's like gore routines, right? Yeah, it's funny how those things morph. One of the reasons why exceptions don't get used, I personally don't like exceptions is because I see people more often, they're using them for flow control.

Whereas an exception should be thrown. So I was in a system the other day and they were looking at validating the data. And when a piece of data wasn't correct, they'd throw an exception. That's absolutely the worst thing you can do simply because that's not an exceptional event. And in the hardware world, you don't have a huge amount of exceptional events, you might run out of memory, but then that's an event where you're putting the hardware into reset and starting over again. So their exception sort of became one of those things that nobody had this really great use case for them, so everybody sort of filled in with what they thought they should do,

and flow control seemed to be the easiest one. And then worst case when I see a lot of times in code is I'm throwing an exception out of one function, but it's not going to get caught for another four or five levels. So now you have separated the cause from the effect, and it makes it very hard to reason about how that's going to work in code. I like a lot of the things that he's got in his proposal. Yes, it's great that there's zero overhead, but one of the biggest problems we run into,

and I think my bias really just comes from having come in the hardware world so often, is that unhandled exceptions are a disaster, and it winds up, we don't have a good mechanism for saying, I'm about to use a function that could potentially throw an exception, but I'm not catching it. It's sort of up to the developer to catch that. And one of the nice things about Java is that they will fail to build if you're doing those exactly kind of things. And I don't think we've got that capability built in. I was hoping modules might give us that. No, I mean, the original throws statements theoretically had, you know, some basis for that, but it was unchecked and no tools, you know, actually caught any of it. So it was removed from the language in the favor of no accept, basically.

Yeah, and it is a tooling. It's a tooling solution. It's not something that you can, putting it in the language, I don't think really helps. You have to have the tooling that does this. Right. Kind of wanted to go back to something you said about contracts. And I'm just kind of wondering what some of your thoughts are to improve the contract proposal. I mean, you said that, you know, it could be used

to DDoS a system by, you know, just sending some bad data that would trigger the contract. What are your thoughts on improving that? So this is actually one of the places where I think exceptions really do excel. I mean, a failed contract is an exceptional event within a system. If you've run out of memory, no matter what kind of system you've got, you pretty much are at the end of the line. You don't want it to be flow control,

but this is one of those cases where you have an exceptional event that happens that now I can actually do something about it. So you throw that exception back to the calling function. Now it knows whatever it sent was incorrect. Calling terminate just sort of takes that out of my hands of being able to deal with whatever that issue was of why that function didn't like that. One of the things that I would like to see improved is I can see a use case where I may want to have part of my code with contracts turned on, but part of my code with contracts not turned on. We do that a lot

with asserts. So asserts typically, when they get built, they get built into the debug versions. But the minute you push this up to Jenkins and it starts building and going out to QE, those asserts are all gone. So if you're using those for protection um they're not going to be there in when when the heaviest amount of testing gets done so one of the things i'd like to be able to do is not only have the ability to turn it off at different points like maybe go ahead and have contracts on for the first few releases that go through the qe cycle and then the last few last two or three just before i cut my release candidate, I go ahead and have those turned off. The counter argument is yes, but now you're affecting how the application

works because contracts are now changing, and that's fine. I'm happy doing that because I'm changing other things in the middle of a QE cycle anyway. So I'm fine doing that in a QE cycle. What I don't want is sort of this division of they're either all on or they're all off or they're all at one level. And I think one of the things that people wanted to change was the idea in contracts where you either had them turned on at some build level, you had them turn up, but it

was system-wide. There are some things that are very sensitive that I would definitely want contracts active through a few QA cycles, but not necessarily across the board when you start to go into a test cycle. Makes sense. I'm still kind of curious, and I don't recall if you directly answered this, if you have some direct connection between C++ and security, or if you just like C++ and you like security and you like putting them together.

Well, C++ is the language I've used most in my career going back almost three decades now. Security was sort of something I backed into because it wasn't something I ever intended to do. But because you have so many critical systems that are written in C++, mainly because of its speed and its flexibility, you do have this, you know,

it sort of is the the best of both worlds for me and that was one of the reasons why i joined the standards committee was um i would look at some of the decisions especially undefined behavior i will talk to people and say oh we're going to do this and then that's just going to be undefined behavior and and we tend to say that in sort of a cavalier manner as if, you know, that's not the razor blades and shredded glass and the punji sticks that we run into in the language. And, again, with like contracts, you know, you can see things that potentially could become security vulnerabilities. And that becomes – that was the reason why I joined the community to begin with was to begin – they've got several people who sort of are in that same arena. But it was a – I guess I'd say it's a happy confluence because I love the language.

I think it's fantastic for what I do for a living that I can't think of a better language out there for it. And then, yes, most of my career has been in some way involved in security. So it sort of married both of those together because C++ is ubiquitous. It's everywhere. And that means it's going to be under daily attack from somebody on the outside. There was something interesting you said the other day. In fact, you brought this up with – I forgot which one it was, but he works for Mozilla. And he was – you said you had heard that Rust, that they were moving to Rust for their backend.

And he said, yes, and you were talking a little bit about the interfaces. And he said, Rust is the future. And when I was listening to that, my ears kind of perked up. And I thought, yeah, and that should be really concerning to the standards committee. Because one of the biggest reasons why we have Rust is because it is designed to be secure. You can't have dangling pointers. You don't have null pointers.

In other words, they've taken some of those sharp edges away. And I'm not an expert in it, so I don't know how they handle issues like undefined behavior. But it should be a concern because we tell ourselves, and I think there's a bit of cognitive dissonance here where we say, well, there's five and a half million C++ developers and there's 25 billion lines of code written in C++, so it's going to be around for a very long time. That's not necessarily true because if someone like Mozilla is beginning to migrate away in the long-term future, as he said, is Rust, there's a reason why they're doing that. And I think at no other time in C++, you know, I was sort of in the prehistory of C++, not the one we have now, but sort of in the prehistory. And at no other time has there ever been this many options to C++ that either have the same

or fairly good performance characters. I mean, even Java can, if you tune the garbage correctors correctly, you can get pretty good performance out of Java. And there are companies that are beginning to rewrite their backend with it. Because from a CEO's perspective, what I want to hear my CTO tell me is, this is what I'm doing to make us more secure. And the easiest button for that CTO to push is, I'm changing languages from one that the market considers insecure, whether it's truth or not, to a more secure language called Rust. And as a CEO, that's what I want to hear.

Like you said, it doesn't matter if it's true. The point is it's market. And from my perspective, it's free. I don't have to spend $20 million getting penetration testers to come in and do a full sweep on all of our systems. So if you're something like Saudi Ramco, you're going to spend that kind of money just getting people to go in and test all your systems. They've got something like 50,000 just desktops. That doesn't even include servers.

But something like if I were Capital One and if they were saying, look, we've got this language in there and we've just got hit, I would want to hear my CTO say I'm moving to something that, reasonable or not, sounds really good to a CEO. And those decisions, those business decisions will often overrule the technical decisions where, well, C++ technically might be the right decision, but if there's another option, I'm going to go with that option even if it's not quite as good, not quite as fast, but it's considered more secure. And at no time in our history in C++ have we had this many options of things that you could actually do to get the same kind of performance curves, to get the same kind of flexibility. I think right now the only thing that keeps Rust from really sort of breaking out is the fact that it's new. It hasn't been around that long. C++, I think, turns 40 this year. Sounds about right, yeah. Yeah. So that's something I think the committee needs to listen to,

not in a panicky mode. I'll often have people come and say, oh, you're giving the scary talk. I'm just like, no, if you're walking away afraid from anything that I'm saying, either I'm communicating badly or you're missing the point. This is not about fear, it's about education. It's about dealing with reality, but dealing with reality deals with you. Now that you're a part of the committee, are there any papers you're actively working on

to try to help C++ become a more secure language? So the two that I named, Secure, Clear, and Zero Head Determinants and Exceptions, I'm not working on them. They're part of the committees that I'm on. One of the things that I'm doing, the course that I'm teaching is actually a course that goes with the book that I'm writing that is going to be published through Pearson. So it'll be out sometime in the spring or summer of next year. Oh, okay. And it's got the same name. One of the proposals that I really liked, and it's actually something that was sort of along the way I was thinking about how the book is evolving, is it's P1705, Enumerating Core Undefined Behavior.

So, Jason, I know you read the standard a lot. Oh, yeah. I've actually read it cover to cover. I did that this morning. Yes, I know you read the standard a lot. Oh, yeah, I've actually read it cover to cover. I did that this morning before we did another one. You know, the reality is that the standard is not written for developers. It's written for compiler designers, and it's written for standard library implementers. Some of it's almost impossible to read. If you want to understand undefined behavior around object lifetime,

you have to read like seven different sections of the standard. It's terrible. Or you just send Richard Smith an email and he'll tell you. Yeah, I actually pulled that trigger on Twitter the other day because I had a question I couldn't answer that my students had and I copied him on Twitter and I got an answer back within like 30 minutes. It was really handy. It's fantastic, isn't it? So here's the problem. If you just restrict this to the core language, there's a lot of places where undefined behavior is very murky and at best opaque to developers in their data until they step on it. And then they don't know why things are blowing up and then they go and they find somebody who has done that themselves. So one of the things this particular paper is doing,

and one of the things that I think becomes vitally important, is there's got to be a chart, maybe a Tony table, where we deal with undefined behavior. And by the way, this is what it says in the standard. This is what it means in plain English to you as a developer. And then this is the code that will trigger that so that they can actually see where is undefined behavior in the language

that I might trip on. And I even made the mistake in a talk where I said something like, if you pop off an empty vector, then it throws. It actually doesn't throw, it's undefined behavior. But I didn't know that because it was buried deep enough in a document that I find almost incompreh enough in a document that I find

almost incomprehensible on a good day. So that's one of the things that I think we can, one of the papers that I really like and one of the things that I was doing sort of for my project is defining where are the areas of undefined behavior, what are the implications, and here's how you avoid it. And there are a couple others. We didn't get to talk about the – there's another zero overhead deterministic failure paper, a unified mechanism for C and C++. What they're trying to do is they're trying to unify the C and C++ mechanisms for dealing with failure paths. Okay.

I don't know a whole lot about it. We didn't cover it in committee, so it's probably something we'll talk about a bit later. So I mentioned WG23, or it was in my bio, WG23. That is actually a group that studies vulnerabilities in programming languages. So they actually have their own sets of papers and documents that they're creating for us to be able to define where security issues are in other languages. And even languages like Ada that are considered to be secure, which is why the government loves to use it in a lot of their projects, of the 65 categories that we outline in that document, they hit 50.

So they have their own. Even JavaScript has its own issues, even JavaScript has its own issues and Java has its own issues. So there is no language that is sort of exclusively secure. And that's, I think, sort of the problem. And the reason why I think C++ sort of gets a bad rap as being an insecure language. I don't think that's true. I think there are ways that you can use it insecurely, but you can also, there's a lot of freedom and a lot of capabilities in C++ that you just can't find in other languages except possibly Rust. Okay. Before we let you go, is there maybe one feature you think you would want to remove from C++ to help make it more secure?

You get only one. Just one. Just one. So I can't say undefined behavior i mean i realize it's not a feature but we do tend to treat undefined behaviors i guess you could say that if you want to say oh if you want to remove all undefined behavior that would be tricky well when there's 300 instances of undefined behavior and c plus was 17 i have to ask do they all have to be undefined because those are the sharp edges of the language that people tend to run into.

So if I had one thing that I could go to the committee and say, listen, if you would deal with one thing, it would really help. It would be undefined behavior, because not only is it opaque, the compilers can optimize based on undefined behavior in ways that I don't really understand. And as a developer, and I make my living as a software engineer, I teach on the side, and I write books on the side, and I do all the other stuff. It's really opaque to me is where undefined behavior can rise up and bite me, and it'll always do it at the most inopportune time. So that would be my, the one thing I wish we would take out of the language is undefined behavior. There's a quote in there somewhere, undefined behavior doesn't wait for a

good time or something. It always shows up when I don't want it to. Okay. Well, Matt, it's been great having you on the show today. Definitely let us know when your book is out. Oh yeah, I will. For sure. I did not know you were working on one. That sounds great. Yep. Thanks guys for having me on. I really had a great time. Thanks. Thanks. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in,

or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com.

Theme music for this episode is provided by podcastthemes.com.