次の方法で共有

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!

 

QA Guy: Well, that’s true – maybe we ought to switch to Windows NT. (laughs)

 

Dev: (laughs) Oh, yeah, Windows NT 3.1, there’s a pillar of stability.

 

QA Guy: Uh huh – and performance. (laughs) What a joke!

 

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.

Comments

  • Anonymous
    March 09, 2008
    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. Also thank you for the in-jokes embedded in the script.

  • Anonymous
    March 15, 2008
    The comment has been removed

  • Anonymous
    March 16, 2008
    "I make more fun of NT in this piece than I do of NetWare." True, and I thanked you for it.  At first I thought that nwourms wasn't a native English speaker, but on second reading I think that nwourms's irony detector crashed.

  • Anonymous
    March 24, 2008
    "QA Guy:  Well, that’s true – maybe we ought to switch to Windows NT. (laughs) Dev:  (laughs) Oh, yeah, Windows NT 3.1, there’s a pillar of stability. QA Guy:  Uh huh – and performance.  (laughs)  What a joke!" Yep, the first version of NT were slow. NT 3.5 was faster. "Dev:  Yeah.  But you know, I’m seeing more RFPs lately that specify that "the server platform must include Solitaire"." Unfortunately the option to delete Accessories were hidden in Windows 2000. "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." Bought the NetWare vs NT controversy back again.

  • Anonymous
    August 26, 2008
    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.