Matasano Chargen - Latest Comments in C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Rudd-O — Fri, 18 Apr 2008 07:53:29 -0000

A Good Craftsman Always Chooses The Right Tool.

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

newsham — Wed, 18 Jul 2007 16:40:43 -0000

Depends on what you mean by 'believer'. Does static analysis replace an auditor? Hell no! (disclaimer: I'm an auditor). Does it point developers in the right direction to finding and fixing security bugs? Yup. People who use static analyzers have much more secure code (there's my bold, unbacked assertion for 2007, you heard it first here!). In fairness, some of the correlation is due to them caring about security in the first place (people who use static analyzers also audit code and run fuzz testers).

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Thomas Ptacek — Sun, 15 Jul 2007 16:43:56 -0000

You're really a believer in static analysis now?

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

newsham — Sun, 15 Jul 2007 02:11:52 -0000

[ptacek] "confirm for me that you really believe that the balance of trivial overflows remaining in mainstream code is scarier than the balance of C++ flaws." Of the C++ code I read (not a lot these days), I don't really see heavy use of C++-isms (biased sample, mind you). I still do see buffer overflow and integer overflows often. I can't speak at all to "the balance."
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).

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Kyle C. Quest — Sun, 15 Jul 2007 01:46:11 -0000

I wanted to clarify what I was trying to say...
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++

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Kyle C. Quest — Sat, 14 Jul 2007 23:46:00 -0000

Quick couple of notes...
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 :-)

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Thomas Ptacek — Fri, 13 Jul 2007 22:37:54 -0000

Tim, confirm for me that you really believe that the balance of trivial overflows remaining in mainstream code is scarier than the balance of C++ flaws (say, iterator invalidation, smart pointer aliasing, and exception safety) in mainstream code.

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).

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

newsham — Fri, 13 Jul 2007 22:00:58 -0000

What!? Programmers are still managing their own memory!? What time is it? (2007!)

[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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Hal — Fri, 13 Jul 2007 05:45:50 -0000

Tom, great write up, point 6 and ref link to best book on market for basic pen/vaap. And thank you for the stl ref book. I had only seen Secord's till this point. Looking forward to Hat and Woot.

Just days away, I think Elvis is being queued up somewhere....

Best, Hal

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Mark Wrobel — Fri, 13 Jul 2007 05:28:02 -0000

Try and take a look at Java's fail fast iterators. It's pretty easy to do the same thing for invalid C++ iterators.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

dugsong — Fri, 13 Jul 2007 00:17:12 -0000

shee, hi Tom...

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! :-)

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

D Smith — Thu, 12 Jul 2007 18:29:40 -0000

I'd recommend giving Ada a look-see for large, collaborative projects. My personal experience is that switching from C/C++ to Ada was like going from a street-tuner Honda to a Roll Royce.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Walter Bright — Thu, 12 Jul 2007 17:45:53 -0000

In D, the normal practice is to use the garbage collected heap, so wild pointers into memory are not going to happen.

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Thomas Ptacek — Thu, 12 Jul 2007 15:24:51 -0000

The D programming language? Can I be devil's advocate and propose that D is exactly the wrong approach?

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

kelsey — Thu, 12 Jul 2007 14:16:24 -0000

My .02 -

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Killall-9 — Thu, 12 Jul 2007 13:46:08 -0000

Some aspects of STL add lots of complexity (and potential bugs) for very little benefit for the programmer. That's why we had to reinvent the wheel - again! - and write our own classes. Yes, I wrote another String, List, Iterator. We had only one DoS vulnerability that was related to code logic.

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

vmy — Thu, 12 Jul 2007 13:18:11 -0000

How about TCL?

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Walter Bright — Thu, 12 Jul 2007 13:08:38 -0000

Many of these difficulties of C++ are fixed in the D programming language, which is a reengineering of C++.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Thomas Ptacek — Thu, 12 Jul 2007 10:55:22 -0000

Cutting and pasting from a reddit comment of mine:

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Sultan — Thu, 12 Jul 2007 10:53:14 -0000

It should be very much straightforward to avoid memory lifecycle problems when dealing with abrupt stack unwinding due to thrown exceptions. The general idea is to create objects on the stack which hold and manage pointer references. When the exception is thrown, the destructors of objects on the stack always get executed! Have you heard of auto_ptr for instance? I think I wouldn't hire a C++ programmer who has such difficulties with these concepts.

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Thomas Ptacek — Thu, 12 Jul 2007 10:27:29 -0000

Eng, I think I agree with you that all the extra machinery in the C++ language (for instance, operator overloading, or polymorphism, or whatever) provide opportunities for exploitable errors.

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Thomas Ptacek — Thu, 12 Jul 2007 10:24:56 -0000

A bad tool routinely screws the craftsman.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

eng — Thu, 12 Jul 2007 09:47:32 -0000

You don't get away from these types of problems in any language. You can write software that runs in a JVM or in a CLR and still have vulnerabilities. You can sometimes even find vulnerabilities in the underlying language that the JVM and CLR were written in (which is most likely going to be a mixture of C++ and assembly).

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Thomas Ptacek — Thu, 12 Jul 2007 09:02:04 -0000

cucu: two problems with that argument, which is old as the hills:

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.

Re: C++: A Cautionary Tale, or, 1 Hour Of Your Black Hat Trip is Spoken For

Reemus Kumar — Thu, 12 Jul 2007 09:01:50 -0000

A Bad Craftsman always blames the Tool.