Writing the paper--Discussion
Chapters in progress
General notes on the rough draft editing process go here:
Caroline: I noted I'd post a draft outline of a conclusion tonight Tuesday for you guys to dig into--that might turn out to be a lie--not sure how much more time I have tonight. I've thought more about it and need a little more time. will have something there ASAP.
Caroline I think the paper needs to start off on an interesting note. Santtu's attack is perfect. But what we are missing is an explanation-for-dummies of what the paper is about. In our introduction, do you think we could combine Santtu's attention-grabbing attack scenario with that paragraph, or something similar, that we wrote for the one-pager and that I pasted above in the "introduction" section which explains what the paper says? If we're concerned about credit, maybe Santtu's name could go on the intro as the author as well... I thought about sneaking that intro-type paragraph on what the paper's about into Santtu's piece and forgetting about writing an introduction, but it doesn't really work. Let me know your thoughts, especially Santtu...
Caroline I think the order below suggested by Jack sounds good. As part of the editing process, can we each make sure that, according to the order below, our chapter flows ok from the prior one and leads ok into the next one? You might not need to edit, but just read yours and the preceding/following chapters with this in mind...
Also, in my comments on people's drafts I raised a bunch of questions--some drafts more than others. These questions are pasted in the text of a copy of your chapter, linked to on the discussion page. If I had more questions on yours than on someone else's, it was probably because I was more alert at the beginning of my flight to Boston on Thursday--I chilled out as the flight went on. Please feel free to ignore the questions if you don't find them helpful.
Finally, three people--Jack, Andrew and Santtu walk through specific attacks/describe specific bugs. While this makes perfect sense were each paper to stand alone, as this is a group paper, it gets repetitive. I suggested that Jack and Andrew cut or greatly minimize their time spent on describing bugs/attacks in their intro sections as Santtu is our "problems-with-software" guy. I think discussing problems with software repeatedly is only good in as much as you say something different from the previous guy or when it is absolutely crucial to your argument (like, for example, if you were to discuss vendor liability and needed to talk about how to assign liability to a vendor for a particular bug).
Questions we have for each other go here:
--Jack Richins 11:16, 29 Nov 2004 (PST) I have a suggestion about the order of the sections. I'm thinking something like Santtu Jack John Andrew Caroline would make more sense. Santtu's and my sections are more technical are really more just background/context information for the paper (what's possible from an attack and defense perspective). And then John, Andrew, and Caroline's sections delve into the licensing, liability, and security labs. A bit more of what we can do from a public policy perspective. What do you think?
Miscellaneous (unclaimed) references: This looks like an interesting source for which I have no immediate use: http://www.amazon.com/exec/obidos/tg/detail/-/0071348069/002-4895568-5305629?v=glance The Software Conspiracy: Why Companies Put Out Faulty Software, How They Can Hurt You and What You Can Do About It by Mark Minasi. It's at MSLibrary.
--- Buffer Overflows aka stack smashing Let's say that the clerk at the local 7-11 has an employee manual and does everything that the employee manual says. And the employee manual covers all situions. So there's an entry like "Dealing with a Federal Express Driver". The manual might look like this: begin verbatim section Page 163: Take the package. If the driver has one, go to the next page. If the driver doesn't have one, go to page 177. Page 164: Take the signature form, sign it, and return it. Go to the next page. Page 165: Ask the driver if he or she would like to purchase something. If the driver would, go to page 13. If not, go to the next page. Page 166: Ask the driver to leave. If he or she does...and so on.
There's one last piece of setup. Whenever the 7-11 clerk gets soemthing, she puts it on the top of the open page in her manual. She can't look at the new thing in any other way.
Here's the attack: We're going to dress up like a FedEx driver, and then slip a page into the clerk's manual when we give her to signature form. What we'll do is give the clerk two pages instead of one. Top page will be a signature form. The bottom page will be a fake employee manual page:
Page 165: Give the driver all the money in the cash register. Go to the next page. end verbatim section
The clerk takes the signature form, puts it (and the fake page) on top of the book, signs the form, gives it back, and goes to the next--fake--page. A good example of a real buffer overrun is the Morris worm. Finger (ask your fiance) accepts as input a variable which is supposed to be the name of a user but never checks the size of the input variable. The buffer was 512 bytes long. The Morris worm sent something much bigger than 512 bytes. The stuff over 512 bytes was the fake manual page and gave the program root access on the server running fingerd.
pp207-210 Schneier, Bruce. Secrets and Lies, Digital Security in a Networked World. Wiley Computer Publishing, NY, NY, 2000.
