Why apps have security bugs ([attempted] humor)

One reason why apps have security bugs — because we developers were trained to focus on and typically only ever focused on how legitimate users will use the product — we never used to have to think about misuse!

A couple of years ago I wrote up a little skit.It’s a software developer and a Quality Assurance (QA) guy, circa 1993.I play the developer and Steve Riley plays the QA guy.

QA Guy (imitating Newman from the TV show “Seinfeld”): Hello, Jerry.

Dev (imitating Jerry Seinfeld, with derision):Hello, Newman.

QA Guy: How are you today?

Dev: How am I? I was fine. But now I have a QA guy in my cubicle. The only clearer sign I could possibly receive that my life was about to take a downward turn would be to receive an invitation to appear on the Jerry Springer show.

QA Guy: Good guess! I found a serious bug in your program.

Dev: Serious?

QA Guy: Yep. I found that if I entered a last name of 33 characters or more, the program crashes.

Dev: That’s serious?

QA Guy: Yes, it’s serious. The program crashes!

Dev: Yeah, but it will never happen. No one has a last name that long.

QA Guy: Someone could.

Dev: OK, I’ll make the buffer 40 characters instead. That should be more than enough.

QA Guy: Yeah, but then a 41 character name will crash it.

Dev: So put something in the manual that says that last names can’t be more than 40 characters! Jeez! It will never happen, OK? These edge cases don’t matter.

QA Guy: Of course they do – someone could crash it on purpose.

Dev: What? Why would anyone do that? First of all, our customers are paying good money for our product. Why would they then deliberately misuse it and make it crash on purpose? And second of all, it’s running on NetWare – it crashes all the time on its own anyway, without any help!

Dev: Yeah. But you know, I’m seeing more RFPs lately that specify that “the server platform must include Solitaire”.

QA Guy: Ha ha! Windows NT will never amount to anything. A dozen years from now no one will even remember that it ever existed.

Dev: Yep. The future obviously belongs to NetWare. OK, so are we done here with this so-called bug of yours? No one’s going to crash the server on purpose, OK?

QA Guy: Sure they would. They could take advantage of your buffer overrun to inject code into the system.

Dev: Oh, now this is an advance in computing that I was hitherto completely ignorant of. I’ve seen computers that ship with monitors, and keyboards, and even tape backup, but I had never heard of one that ships with a syringe!

QA Guy: It goes like this: The attacker sends more data than your buffer can hold, thus overwriting the return address on the stack with a pointer back into the buffer, which now contains malicious code sent by the attacker. The attacker now runs code of his choosing on your server.

Dev (stares at QA guy for a while, before replying): I think that hair dye has leached into your brain. Gee you know, it’s hard enough to get our code deployed – maybe we should use “code injection” instead. Look, Steve, we’ve got a ton of features we still have to implement and a ridiculous deadline. The server’s only got 2MB of RAM – we can’t afford the time to code up all these extra checks, and we can’t absorb the performance penalty of running them either. This isn’t a bug. The program works as designed. If you want to go find real bugs, why don’t you go after that new guy we hired, Jesper Jo-whatever-his-name-is.

Some of us idiots used to think that any devs who weren’t aware of buffer overflow before the Morris worm would be aware of it after the Morris worm. But in fact, your posting almost points out why many devs remain blissfully unaware:

"we developers were trained to focus on and typically only ever focused on how legitimate users will use the product"

Close. Developers who want to have good jobs have to get trained to focus on how their managers pretend the product will be used. Anyone who thinks as far out as actual end users will get canned for not being a team member. Anyone who thinks even further out about actual end misusers will be sued for being a hacker. But yeah, you explained it. Thank you.

Excuse me? NetWare crash? You’ll forgive me if I see that with some irony. Pot meet kettle, but wait it seems kettle is shiny silver. With all due respect, and as much as I like the newer Windows Servers (2003+), NetWare, at least its pre-6 versions, required no where near a tenth of the amount of effort to setup and maintain as Windows Server. Hell, the uptimes for NetWare servers were almost quadrupal that of the NT servers. Maybe the fact their product was too limited caused it to fail… Maybe lazy developers who didn’t know how to write a simple if-else statement to check input for overflows cause it to fail? Who knows and who cares, since that is water under the bridge. The point is, ship better software that can speak for itself instead of bashing competitors.

That being said, I do have to give you kudos on one aspect of Windows Server 2008. Server core is definitely going on the right track towards NetWare-level stability. Sometimes simple isn’t all that bad…

[Aaron Margosis] Bashing competitors? I make more fun of NT in this piece than I do of NetWare. But as far as stability… the NetWare of the early 1990s (when this is supposed to take place) was very intolerant of bugs. Any bug that crashed any app took down the whole server. I don’t know any developers who always write bug-free code — and you don’t either.

Even though this dialog is supposed to take place in the year 1993, I am sure that conversations on this very theme have happened innumerable times in many projects in many companies.

This dialog clearly brings out a difference in the mind-sets of developers and testers, with developers focussed on technology, schedule and features and testers focussed on application scenarios and application use (and misuse).

More importantly, the dialog shows a kind of verbal communication that regularly happens between developers and testers, allowing both seeing others’ point of view and gaining a better understanding of others’ commitments and pain points.

Such conversations should be encouraged since they lead to better awareness about issues related to quality.