Yet Another Buffer Overflow

The latest Flash player has a security problem:

http://www.cnn.com/2003/TECH/interne...rns/index.html

Programmer types, notice that it's a buffer overflow exploit. How on Earth can programmers in 2003 still be creating buffer overflows? That's darn near simply irresponsible in my book.

[toddjh]

Quote:

Originally posted by sundog
The latest Flash player has a security problem:

http://www.cnn.com/2003/TECH/interne...rns/index.html

Programmer types, notice that it's a buffer overflow exploit. How on Earth can programmers in 2003 still be creating buffer overflows? That's darn near simply irresponsible in my book.

Programmers are being divorced from the actual framework behind the programming language, thanks to higher- and higher-level languages, which only encourages them to stop thinking about things like that. It's the job of the compiler to warn them about not allocating enough space, and the garbage collector to clean up the mess! It's scary.

On one of the shelves at work, we have a book on server programming that actually says not to bother worrying about memory use because it's cheaper to just buy more RAM than to pay a programmer to write efficient code.

Jeremy

[Walter Wayne]

Quote:

Originally posted by sundog
How on Earth can programmers in 2003 still be creating buffer overflows?

Microsoft Visual C++ with the Microsoft Foundation Classes. Just a theory.

Walt

[shanek]

It's not just Microsoft C++. The Linux "file" command and "sendmail" daemon both have had recent buffer overflows detected and fixed. C and C++ are lower-level languages where bounds checking is up to the programmer, and I agree it's lazy. With higher-level languages, it is indeed a function of the compiler to make sure proper bounds checking is implemented.

I haven't taken the Microsoft Foundation class, but I would hope that "bounds checking" would be drilled into the students' heads and tattooed on the back of their eyelids.

[PixyMisa]

Right. Sendmail in particular is infamous for buffer overflows - which is why I don't run sendmail on any of my servers.

It's a problem to do with C's string handling and the C standard library. There are safe alternatives for all the library functions now, but people don't use them and/or write their own crappy code to put the buffer overflows back in.

Take away their C compilers and give them Ada. If they complain, give them Fortran IV.

[Torlack]

(programming rant)

The problem is, those "safe" alternatives haven't been proven to be any safer. Sure, they sound good, but all too often the claims don't match reality (where are the tests?). I did a review on Scott Meyer's paper on handwritten loops and found that two out of three of his points were incorrect just based on HIS examples. The "right" way was much slower and his "right" way had more obscure bugs that doing it the wrong way.

The scary trend I see from people such as Boost is that in no uncertain terms they are saying that programmers are too stupid to write software. I had a long and drawn out argument with one of the Boost contributors about his own contribution where his "safe" method was known to be problematic and he made totally illogical and incorrect statements about the "wrong" way of doing things. What was so strange was that he repeatedly pointed to a paper saying it supported his claim when in fact the paper devoted an entire section on how to do it the "wrong" way. The paper even pointed out the exact same non-critical problems that I had discussed when using the "wrong" way.

Then you take a look at the standards committee. They included that great "export" (?) feature for templates. Even though they had papers discussing all the problems with the feature and all the compiler vendors voted against it, the feature was included.

Why? Because:

1. It would be embarrassing if the feature wasn't there.
2. Many other languages had the feature
3. (and one other totally silly reason that had nothing to do with science).

(Doesn't that sound like a woo-woo?)

What a great example of computer science at work. I was so furious that I even wrote Randi to see if he thought I could do anything to help them to see how flawed the process was. (BTW: Even though they now admit the error, they still don't realize that the process that caused this problem is flawed.)

Even Herb Sutter warns against some of the garbage we are seeing today. People are told things are "right" or "wrong" and are never told WHY. Thus they don't realize that things aren't as black and white as they have been told. "Gotos are evil". "Global variables are evil". Even Dikstra in his famous article says that gotos have their place. Be we all have been taught the 5 second lesson and not the whole story.

I once took a standard part of C++ and rewrote it to improve performance by a factor of 4. When I told people that under certain conditions the standard implementation of a hash map we all know and love performs poorly, people accused me of not knowing how to use it or being too stupid to test it properly. So I had to explain in great detail the implementation assumptions that SGI made and how they can impact certain applications. I have another example of how lower_bound performs worse than brute for on some containers because the iterator addition operator performs worse than the actual comparison. (BTW: lower_bounds is documented as being O(logn) but it is actually O(n) on some containers due to the iterator problem. It is assumed that the iterator adjustment executes in O(1) when for some containers it doesn't.)

I use a mix of C and C++ because I understand the limitations of both. Time and time again on programming boards I see people who say "my program is running like a dog, what can I do." I look at the code and they are using standard STL the way they should. I point out that if they used more tradition C in SPECIFIC cases then performance goes through the roof. They have been taught the "right" way without being taught that the right way comes at a price. Sometimes when all aspects of a problem is reviewed, the "wrong" way is much better than the "right" way.

[Torlack]

Quote:

Originally posted by PixyMisa
Right. Sendmail in particular is infamous for buffer overflows - which is why I don't run sendmail on any of my servers.

It's a problem to do with C's string handling and the C standard library. There are safe alternatives for all the library functions now, but people don't use them and/or write their own crappy code to put the buffer overflows back in.

Take away their C compilers and give them Ada. If they complain, give them Fortran IV.

The problem is that even if you use the "safe" methods, you have to use them properly. People are lulled into thinking that just because they use the safe method, there will not be problems. It just isn't true. The autoptr failure in STL is a perfect example of people not using it properly and causing all sort of problems.

Now many people would say "well, what do you expect, they didn't use them properly". Well, C strings work perfectly when used properly.

I have yet to see a real case study in the real world to see if any of this new fancy "safe" stuff is really producing better code.

[PixyMisa]

Quote:

Originally posted by Torlack
The problem is that even if you use the "safe" methods, you have to use them properly.

Well, yes. They are safer, but they are not a cure for stupidity.

Quote:

People are lulled into thinking that just because they use the safe method, there will not be problems. It just isn't true. The autoptr failure in STL is a perfect example of people not using it properly and causing all sort of problems.

Now many people would say "well, what do you expect, they didn't use them properly". Well, C strings work perfectly when used properly.

I have yet to see a real case study in the real world to see if any of this new fancy "safe" stuff is really producing better code.

It really depends on what proportion of problems are language or library design issues and what proportion are application issues.

You can make a language that doesn't let a programmer do anything harmful, but such a language won't let you do anything useful either. But you can work to improve things.

[shanek]

Quote:

Originally posted by PixyMisa
If they complain, give them Fortran IV.

Hey, now, come on! They do have 8th Amendment rights, you know!

Quote:

Originally posted by shanek

I haven't taken the Microsoft Foundation class, but I would hope that "bounds checking" would be drilled into the students' heads and tattooed on the back of their eyelids.

Wrong kind of classes.

[Occasional Chemist]

Quote:

Originally posted by PixyMisa
Take away their C compilers and give them Ada. If they complain, give them Fortran IV.

{puts on chemical engineering hat}

And what's so bad about FORTRAN???

{removes chemical engineering hat}



edited to add: In my experience, people who hate FORTRAN just aren't using it for the right thing.

[Iconoclast]

Quote:

Originally posted by Walter Wayne
Microsoft Visual C++ with the Microsoft Foundation Classes. Just a theory.

Walt

Walt

I'm interested in what you base this theory on. I'm assuming you know what MFC is, so what makes you say that this particular set of class libraries inherently causes programming errors.

I'm also assuming (hoping) that you're not trying to say that the Win32 APIs are preferable to MFC, since a quick glance at the MFC source reveals it countains a very large amount of error checking, since that's why it was created, to build a wrapper around the APIs that's safer and more convenient than using the APIs directly.

[PixyMisa]

Quote:

Originally posted by Occasional Chemist
And what's so bad about FORTRAN???

Fortran IV???

[Occasional Chemist]

Quote:

Originally posted by PixyMisa
Fortran IV???

AKA FORTRAN 66, right?

It's not THAT bad - for the right applications. We're not going to write a web browser in it.

[PixyMisa]

Quote:

Originally posted by Occasional Chemist


AKA FORTRAN 66, right?

It's not THAT bad - for the right applications. We're not going to write a web browser in it.

I HATE WEB BROWSERS!!!!!

Just thought I'd mention that. Yes, I've been thoroughly enjoying my new job as a web designer and the delightful way that every browser is broken, but no two share the same set of brokennesses. BLEAH!

The desire to just make everything one big gif becomes overwhelming after a few hours and I have to go and have a lie down

[Cecil]

Everybody should just use BrainF*ck.

http://www.muppetlabs.com/~breadbox/bf/

[Walter Wayne]

Quote:

Originally posted by Iconoclast

Walt

I'm interested in what you base this theory on. ...

I base the theory on 8 months of using MFC's around 1997. The application I created had memory leaks although the stuff I did only included one non-MFC class and modification to there document and view classes. (Trying to recall the specifics here).

I never tracked to the leaks, but it appeared I ran out of memory faster when said application was run then when not.

However, it may have been MSVC++ and not the classes as I nearly always ran my app from there.

Having said that, my comment was half tongue-in-cheek.

Walt

[shanek]

Quote:

Originally posted by sundog


Wrong kind of classes.

Sorry...having worked at a computer training center for 6 years I got stuck into a mode of thinking. There actually is a Microsoft Foundation class, although as I said above I haven't taken it.

[shanek]

Quote:

Originally posted by PixyMisa
Yes, I've been thoroughly enjoying my new job as a web designer and the delightful way that every browser is broken, but no two share the same set of brokennesses. BLEAH!

Code to the standards, not the browsers. I've found that if I stick to the HTML 4.01 Transitional/CSS1 standards it looks fine the first try in Mozilla, Netscape 6/7, Opera, and most other browsers, and only needs minor tinkering in IE (it always sucks in Netscape 4.7 no matter what; I've given up on trying to code for that piece of crap).

The HTML Validator is of invaluable help here.

And PHP is by far and above the best scripting language for making web pages that work, providing you stay clear of a very few caveats.

[bPer]

Hi all,

I have the solution for all your buffer overflow exploits - hardware buffer protection.

I work on Unisys ClearPath NX's, previously known as Burroughs mainframes. All words of memory are marked as data, code, pointers, etc., and all data buffers are surrounded by memory-protect words. Try to walk off a buffer, or index off into la-la land, and you will generate a memory-protect hardware interrupt. No range-checking compiler code required.

Not only that, only a program marked as a compiler by a privileged user like myself can generate code, and only a compiler-generated codefile can be executed, so no user program can be built that itself builds code and then branches into it.

Combining these two features, you just can't get a buffer overflow exploit.

And this has been around since the '60s.

bPer