-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/914/c-a-cautionary-tale-or-1-hour-of-your-black-hat-trip-is-spoken-for/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
"Map has the important property that inserting a new element into a map does not invalidate iterators that point to existing elements."
So you might want to rethink point 4. Your claim, however, is definitely true for vectors.
1. The bugs we're talking about are so easy to create that the "best" minds in C++ had to write articles about how the features they involve should be removed from the language because they were so easy to misuse.
2. You can say the same thing about any exploitable C code bug; my premise is that C++ is less safe than C, and you're not addressing that.
C++ is less safe than C? Back in the DOS days, I hosed my entire partition table by accidentally writing to an invalid FILE pointer. I can do this in C++ too if I want to. So which one is better?
You still have buffer overrun problems in C. You still have memory leak problems in C. You still have security problems in C. You still have buggy code in C.
What you don't have in C is the ambiguous meaning of operators. The -> operator in C means precisely that you are accessing a member from a pointer. In C++, it doesn't always mean that. If you're a C++ programmer with experience, it isn't a problem. If you're a C++ programmer without a lot of experience, well then yes it is a problem. C++ programmers have to be aware of what they are doing or else they run into the problems your article describes. Isn't this the same with any implementation regardless of the technology behind it?
This, of course, leads into the argument of maintainability of C versus C++ code bases. Limiting your implementation options to C based on an ambiguous idea of it being more secure isn't going to mean squat if you find a security hole that requires you to rewrite the whole program to fix.
One thing to keep in mind is that aside from new bug classes, C++ definitely provies a myriad of new exploit toeholds. Everything in C++ is indirected; there are zillions of function pointers at predictable offsets.
Actually, I kinda like Joel's articles, but I read the linked one about exceptions, and I think he is in the wrong this time. I personally in favor of performance-oriented code, and I generally don't use exceptions, but they have clearly a place and use which is not insignifficant or buggy.
Yes, RAII addresses much of the problem with exceptions. SafeSTL addresses the problem of insecure iterator invalidation (at a cost). Vector addresses the problem of array destructors. Good programming addresses the problem of bad programming.
The problem is, as a security practitioner paid to search through the codebases of the largest, best-known C++ products, I keep finding bad stuff. Knowing the right thing isn't enough. A CS freshman knows not to stuff a 200 character string in a 100 character stack array, but that vulnerability still happens.
I admit being a Qt fan. These days its non-GUI classes provide a pretty good choice. If its GPL license were available sooner it would have save a bunch people hours of debugging.
my problem has always been crazy deadline pressure from manangement / marketing makes it all that much easier to miss something obviously problematic. In which case, I am more concerned about making the deadline than I am about security concerns.
My point is - it's not always enough to be a "good programmer" and be aware of the various exploit classes if you aren't afforded the time necessary to do the job right.
D's memory model resembles "managed C++". But it still provides direct hardware access, along with malloc and free. Programs written directly to hardware inherit memory lifecycle vulnerabilities.
What troubles me is when languages go through effort to paper over that problem. C doesn't. If you understand C, you know that fundamentally you're working with raw memory. C++ tricks you into believing maybe you're not, until you delete something out of a container and one of your iterators turns into a wild pointer. Doesn't D do the same thing?
I think the issue here is, lightweight/static runtime versus heavyweight/dynamic runtime.
It does allow you to call malloc directly, and such, but while in C these are necessary, in D they are very rarely necessary, and so it is much less work to audit the few cases where they do occur.
The idea is to make the easy, straightforward way to code things also the safe, efficient way. To do things the unsafe way, you have to do extra work.
For another example, variables and fields are always initialized. To leave them uninitialized requires you to do specific extra work. In contrast, C/C++ by default leave them uninitialized, which is a far more error prone situation.
i've not "given up on security" to "go do something meaningful" - this is crazy talk. that may have been how you felt about NAI, but i'm glad to have had the opportunity to save the internet with you at Arbor. :-)
Stuart Staniford may be a better example for your purposes:
http://www.econbrowser.com/archives/2007/05/nor...
i'm sorry i'll miss horizon and duke's talk, which promises to be amazing (and never were there two nicer guys in the industry). i keep hoping someone takes on Python next, and a Li Gong finally emerges in that community.
see you at WOOT07! :-)
Just days away, I think Elvis is being queued up somewhere....
Best, Hal
[ptacek] "On balance, the bug classes C++ introduces are way scarier than the ones it takes off the table." We've gone through all the low hanging fruit. I think lots of buffer overflows are scarier than a few hard to understand and hard to exploit flaws.
[kumar] "A Bad Craftsman always blames the Tool." A good craftsman also knows the limitation of his tools, wishes for (and builds) better tools, and groans when he realizes how many bad craftsmen are using inappropriate tools. I don't think one or two bad craftsmen are the problem here. We've got a pandemic.
You'll probably mostly be telling me something about how effective you think auditing is (ie, have we squeezed most of the silly stuff out yet).
Note one...
Sure C++ has new things that can be screwed up and that can have potential security implications, but it's true for anything new. This applies not only to languages, but also to applications. Let's say a solid product A just introduced a new feature. There's a good chance that this new feature might have a vulnerability or two :-)
Note two...
Have you heard about hash maps... They are now in STL, so you can have your hash tables :-)
Thomas is right on the money saying, "C++ is less secure than C". It just seems like it's stating the obvious. Besides, C++ wasn't designed to be more secure. It was designed to be easier for things like object oriented design while still retaining the performance potential of C. As for STL. STL is not a part of the C++ language itself, so it shouldn't be thrown in the mix.
As for people who say that C++ is more secure than C they:
a. Know nothing about security and
b. Know nothing about C++
I don't know that we've "squeezed all of the silly stuff out"... there's a lot of old code that's been cleaned up a bit, but there's still plenty of new code being written and not everybody is statically analyzing their code or auditing it. Then you have a lot of people who just plain arent using C++ or C anymore. Good for them, I say. (Nothing against C, I just don't think its the right tool for most people. Programming speed, correctness and code size are so much more important than cpu speed and memory and disk footprint these days. And next year it will be 1.5x more important).
Tools help us out. Writing and auditing code is hard. Static analyzers show us some bug potentials deep in the code that we might not have considered, especially if there is a lot of distance between the source of the data and the code that incorrectly handles it. Similarly fuzzers show us some bugs that are fairly shallow in the code that we might not have considered simply because the corner cases are slight and easily missed. Both of these tools miss lots of issues that a programmer who understands the code well might notice.
C++ Is Not It.
I'd love if you could write a post about Python and security. I'm subscribed to your blog so I won't miss it.