52 Comments so far

• Adam

  June 22nd, 2008 1:39 pm

  Do you mean pen testing isn’t a science, or security isn’t a science (scientific field)?

• Thomas Ptacek

  June 22nd, 2008 1:43 pm

  I don’t know whether either are “sciences”, but I know neither are engineering disciplines, and that that’s what’s at stake in this argument.

• Marcin

  June 22nd, 2008 3:23 pm

  * Building secure systems is an engineering discipline.

• Thomas Ptacek

  June 22nd, 2008 3:36 pm

  Marcin — I know we want it to be, and it’s a fine goal to aim for, but we don’t have the foundations in place to build engineering rigor around.

• Chris

  June 22nd, 2008 5:15 pm

  Good distinction. I guess maybe it is better described as the Art/Science combo versus Engineering… but that’s a lot more syllables. :>

• adamo

  June 22nd, 2008 5:16 pm

  Architecture is an Art. In Greece also it is also simultaneously considered as an Engineering discipline. So there, you can have it all: Art, Engineering and Science together (at least) in one field. And the “gut feeling” has another name too: Experience.

• Thomas Ptacek

  June 22nd, 2008 5:32 pm

  For the record, I agree strongly with Chris’ sentiment — you can get CYA from a checklist and a process, but you can’t get assurance.

• Mangoboy

  June 22nd, 2008 10:14 pm

  Secure systems design…

  Just because we suck at it doesn’t mean it’s not an engineering discipline.

  It took engineers of high pressure steam boilers about a century to figure out how to build ones that didn’t explode and kill people on a regular basis. All the inadequate safety measures designed in the interim still qualify as products of engineering.

  As security integrates into software development processes it becomes more like building bridges and less like slapping poop on a canvas.

• Thomas Ptacek

  June 22nd, 2008 10:16 pm

  We’re going to have to agree to disagree that there’s enough of a foundation in place for us to call secure system design “engineering”.

• Chris Walsh

  June 23rd, 2008 10:30 am

  The hypothetico-deductive method is useful as long as you restrict the domain. Whether this is practical is an empirical question :^)

  It is a testimony to the quality of this blog and its readers that nobody has yet mentioned Malcolm Gladwell.

• cscott

  June 23rd, 2008 10:40 am

  There’s nothing wrong with attempting to apply the rigors of engineering discipline to the process of securing information systems.

  However, to imply that infosec is an engineering discipline in and of itself ignores that infosec is a business support process and not an end-state in itself.

• Mike Tracy

  June 23rd, 2008 12:05 pm

  An argument could be made that the goal of information security (and in this case penetration testing in particular) could be called engineering.

  Take the classical definition in which engineers apply mathematics and science (colloquially) to build something that achieves some goal. For this exercise, that goal includes “security” whatever the context. Those working to provide either security or assurances of security are assisting in the building process, helping to achieve one part (and thus further the whole) of the goal. Whether their discipline alone could be called engineering is, perhaps, incidental.

  [edited for engorish]

• Adam

  June 23rd, 2008 12:15 pm

  I’m still thinking a little on the main question, but wanted to respond to cscott.

  CScott, can you name a single engineering discipline which is “an end-state in itself?” All engineering is aimed at addressing business or social problems.

• someone_not_in_academia

  June 23rd, 2008 1:43 pm

  I am not into academia, but if now they are starting to give security course and security lecture and security is starting to be a hot topic, its probably flawed. Why? Because from its roots security is not part of any computer teaching beside mabey cryptography and still. Mostly they show about optimisation , object oriented design and uses of languages like Java which we all know are “secure by design”. So who need to understand the low level.

  And those people are the one driving the computer industry for years.

  Mabey you can hope that in 10 years your probably get gonna get teachers that once walk the talk.

• cscott

  June 23rd, 2008 1:52 pm

  Engineering: the art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants.

  ————–

  Note the distinguishing phrase of “pure sciences”.

• someone_not_in_academia

  June 23rd, 2008 1:58 pm

  Might not be related to the topic but, the link below is worth listening.

  http://www.computer.org/portal/site/ieeecs/menuitem.c5efb9b8ade9096b8a9ca0108bcd45f3/index.jsp?&pName=ieeecs_level1&path=ieeecs/podcasts&file=patt_video.xml&xsl=generic.xsl&

• send9

  June 23rd, 2008 2:10 pm

  Even worse than losing the “gut feel” is that the check list approach really limits to you certain systems, and the overall big picture is missed. It’s tougher to demonstrate risk and impact and things, and showing how different risks interact to form a bigger risk is tougher still. Check lists have their place, but I hope no one considers themselves “secure” simply because all their control objectives were met.

• David LeBlanc

  June 23rd, 2008 3:55 pm

  This is funny to read - so few of you have any real idea of what constitutes actual engineering. Just because you do not have a formal mathematical model does not at all imply one cannot practice engineering. We flew early supersonic aircraft without understanding the math. We build bridges all the time without a good understanding of dynamic loading. Real engineers operate all the time in realms where the math either just isn’t there yet, or only gets you close to the solution.

  Many of the security problems we create are because of a lack of a solid engineering approach; the converse is also true - applying a thorough engineering analysis to a system will often reveal substantial numbers of flaws, and better yet, will find them in a systematic manner. This is where threat modeling really shines.

  And as someone pointed out in the thread, just because you’re not very good at engineering secure software yet doesn’t mean it isn’t engineering to do it as well as you can. All the engineering disciplines are in a constant state of evolution.

  If you have an actual engineering degree (CS does not count - that’s math/science), then you’re qualified to comment on what engineering is and is not. The fundamentals of computer security have been in place since the mid-70’s, so there’s certainly enough basis to do real engineering. Most people do not, which is one of the reasons why we have the current sorry state of affairs where there is so much flawed software, and there are so many bug hunters who don’t actually validate software, but just know enough to find a steady stream of bugs because they recognize patterns in much the same way that my horses can break into the barn to steal hay. So you can find bugs - big deal - the hard part is telling people how to systematically avoid creating them (or at least avoid shipping them), and still meet the rest of the _engineering_ constraints around what you’re trying to deliver.

• Thomas Ptacek

  June 23rd, 2008 4:12 pm

  I object to the spirit of your argument, Dave, but not to the literal detail.

  Conceded: it is possible to practice security engineering, using the “fundamentals of computer security that have been in place since the mid-70s”. And I agree, nobody actually does this, just like nobody actually engineers software.

  You’re obviously completely backwards on whether it’s harder to find bugs than fix them. If you have the luxury of defining the entire development environment, it is straightforward to systematically eliminate vulnerabilities. That’s why there’s only ever been one vulnerability confirmed in qmail. For the rest of us, software security is a give-and-take between incremental countermeasures and elaborate evasions of those countermeasures.

• someone_not_in_academia

  June 23rd, 2008 4:16 pm

  If the formal basis where up to date, the story would probably be different. But as environement evolve and threats changes. It is the same story as allways, features vs realiability. As with each new hype comes the new hack.

  How can’t you understand what an eng do if you never took his course? Because you dont wear the ring, and your not legally liable for a decision an eng would have taken, your experience vision and understanding of things is wrong?

• Thomas Ptacek

  June 23rd, 2008 4:21 pm

  You know what, on second thought, Dave, I think you’re totally wrong.

  You’ve read the argument and instead of addressing it, you substituted a straw-man argument that was easy for you to win.

  Nobody is arguing whether it’s *possible* to engineer security computer systems. We’re arguing over whether practices like “secure system design”, in the real world, can practically be considered engineering. “Secure system design” is not engineering.

• Thomas Ptacek

  June 23rd, 2008 4:29 pm

  Ours is the task to remember (and to remind) that, in what is now called “software engineering”, not a single sound engineering principle is involved. (On the contrary: its spokesmen take the trouble of arguing the irrelevance of the engineering principles known.) Software Engineering as it is today is just humbug; from an academic —i.e. scientific and educational— point of view it is a sham, a fraud.

  That’s a cheap shot though.

• cscott

  June 23rd, 2008 4:47 pm

  One of the things to keep in mind is the difference between assessment and design. Assessment methodologies and approaches today are definitely far from engineering disciplines, and a pure checklist approach is not getting it much further towards the rigor implied by such a discipline.

  I’m going to step back from the discussion about whether design practices can constitute something resembling security “engineering”. I think there are significant deficits in the risk management approach surrounding the vast majority of software development efforts today. We should be asking ourselves why that is the case. Whether or not engineering is the only answer or not may be tangential.

• adamo

  June 23rd, 2008 5:13 pm

  Thomas Ptacek you write: ““Secure system design” is not engineering.”

  As an (Electrical) Engineer I have to disagree with that point of view. I will bring one example that is quite common here (we have a lot of seismic activity here in Greece): A house can be viewed / modeled as a system. If a house is not designed with security in mind, the house will fall on your head faster than you may think.

  So why is it different when we talk about software or systems involving both software and hardware?

• Thomas Ptacek

  June 23rd, 2008 5:23 pm

  Because you know what causes a house to fail, and you don’t know (with any rigor, in common practice, etc etc etc) what causes software to fail?

• David LeBlanc

  June 23rd, 2008 6:42 pm

  I think you’re misinterpreting part of the point. In order of difficulty, I’d rank things like so:

  o Fix an implementation error once known
  o Find implementation errors
  o Fix design errors once known
  o Find design errors
  o Create code without design errors, and without a high density of implementation errors

  Most of the “security researcher” community is oriented around the 2nd bullet. I used to do that, and now find it boring. There are surely some clever people who do these things, but people like Kaminsky and Cesar, who actually find significant design problems are much more rare and valuable to have around. Then there’s Adam, who has the courage to try and solve the really hard problems.

  Some people do actually engineer software. I’ve had the pleasure of working with some people who are very good at it. More people should do it. It’s sad you think no one does this.

  For example, the low bug density in qmail has a lot to do with sound engineering practices, and that’s fundamentally based on Saltzer and Schroeder design principles. It isn’t just that the dev quality was very high - it’s that the design was solid to start with. That’s engineering. I’m frankly surprised you don’t recognize good engineering when you see it.

  As to the argument of new issues coming up all the time, that’s mostly untrue. Int overflows aren’t new. All the C++ stuff Dowd et. al., exploit isn’t new - that’s documented in 15 year old books. Very little comes along that’s really new. Solid code with good design will have few bugs. Solid code with poor design will have more bugs, and junk code with no design will have the most bugs.

  We do know what causes software to fail. Number one problem is failure to design properly. This comes up over and over in the literature. Next is a failure to properly unit test at function/object level.

  But then, I only have 3 actual engineering degrees from top-10 programs, and maybe I don’t know as much about actual engineering as some other people, so this is just my opinion.

• Thomas Ptacek

  June 23rd, 2008 7:00 pm

  Really. That’s what you think? There’s nothing new in vulnerability research, because you can find a 15 year old book that describes the root cause of anything Mark Dowd comes up with?

  Obviously, I recognize and appreciate solid design when I see it, which is why our mail server runs qmail. Consider, though: the one vulnerability we know of in qmail was a 64-bit integer problem. qmail did an impressive job of handling every flaw Bernstein was aware of in 1995, but slipped on a later attack.

  There are other things you and I appreciate differently. When someone walks up to the whiteboard and redesigns a whole system in an attempt to resolve some a priori threat model, this to you appears to be “solving a hard problem”. Sometimes it is. Most of the time, it’s just vanity. How many “secure-by-design” systems do you know of that have survived direct, high-touch, mainstream use unscathed?

  On the other hand, when someone accepts the constraints that the real world needs to deal with — for instance, devising the best possible incremental improvements to a legacy codebase into which hundreds of millions of dollars have been invested, this is “solving a boring problem”. I concede, reshaping the world to your whims is a lot more interesting than finding the exact single X86 opcode that needs to change to leave a system impervious to all known attacks. If you’re, I don’t know, KAMINSKY smart, maybe your reshaping will have a more lasting effect than simple bughunting. We’ll have to wait and see.

  There are 15 year old books we can look to for concurrency and distributed systems theory. I’m sure we can crack the spine on Atomic Transactions (don’t choke on the dust) and find ways to break a commit scheme. But how likely is it that our best efforts are going to survive concurrency vulnerabilities? I spent the better part of 5 years working on variants of distributed commit, and there is nothing in the world I would less rather debug.

  It really feels like you think we’ve sussed out the bulk of the software security problem. People thought the same thing in 1999. I’m sure Ranum thought so in 1994. Let’s check back up on this in 5 years. By then, I’m sure your employer will have eradicated flaws — at least in every product designed starting today, when sound engineering practices have taken root.

  But then, I tool political science and psychology, and never came close to finishing. So I’m sure I don’t know as much about actual engineering as you — or Djikstra, and Knuth, who, probably because they are scientists and not engineers, disagree with you.

• Thomas Ptacek

  June 23rd, 2008 7:14 pm

  It’s also not true that all this C++ stuff that’s been talked about has been well-known since the ’90s. Sutter’s exception safety paper, late ’90s, extremely general, nothing to bridge it to the TOCTTOU and reentrancy stuff that makes it exploitable. Smart pointer aliasing? Iterator invalidation? Just a few years back, unless I’m missing a Dinkumware feature you know about.

• Thomas Ptacek

  June 23rd, 2008 10:59 pm

  With a few hours of thought I will add: it is true that if people thought and worked more like Dave LeBlanc, our software would be much more secure. Dave’s just wrong about why that is.

• Statler and Waldorf

  June 24th, 2008 12:18 am

  Yeah, yeah, sure, you’re a PhD. Just don’t touch anything, okay?

• John McDonald

  June 24th, 2008 1:26 am

  IMHO, finding design errors requires the same thought processes and creativity as finding *interesting* implementation vulnerabilities. Design errors are in some respects easier because the propositional logic you are evaluating is usually only a few bullet points as opposed to the complex meshes you get deep inside a complex corruptible running program. And, they are in some respects more difficult because your ability to attack the system isn’t bounded to a machine so attacking it is more non-linear.

  For one, you need to know low-level machine and language details, and, for the other, you need to know crypto fundamentals and business-informed security requirements. Both have mundane findings and intricate findings, and both require a smart and creative professional to be performed well.

  I used to get offended when people equated us implementation-level jerks with dull-minded pattern-recognition monkeys, or, more recently, ravenous hay-seeking horses. It doesn’t really bother me anymore, as I’m still pretty sure we’re handy to have around. Also, horses are pretty awesome except that I’m pretty sure they are evil.

  I’d agree that designing and implementing a secure system is a different thing entirely, and if you want to put that on a higher intellectual plane than security assessment, I won’t begrudge you that.

  Yes, much of the C++ stuff has been well-documented from different perspectives. Sutter’s Exceptional C++ is pretty much an illustrated handbook on problems that are likely to have security implications. We added some things to the discourse imo, but we made no claim of originality, besides a handful of lower-level exception-handling related attacks we outlined.

• Dan Kaminsky

  June 24th, 2008 1:41 am

  Well, this came out of nowhere.

  There’s an astonishing collection of false dichotomies here. Design vs. Implementation! Old bugs vs. New bugs! Art vs. Science vs. Engineering! Kaminsky vs. Dowd!

  What?

  For the record, I hope to some day in my career contribute to something as significant to computer security as The Art of Software Security Assessment, or for that matter, Writing Secure Code. (I’ve got a few ideas — gimme a while )

  Implementation flaws matter. It remains a depressing truth that I have not yet found a developer (outside of MS) who can recognize a multiplicative integer overflow, despite the words “attacker controlled” and big scary arrows pointing inside the malloc. Design flaws matter. DJB could not write a secure desktop file dropper. Code has to match intent, and the intent must not be fundamentally misguided. Get either one wrong, and — well, what was once a curiosity of software obscura, is now something rather more.

  Anyway, there’s always something of a continuum between implementation and design. Can you really understand by-design behavior, without teasing apart the duct-tape-and-bailing-wire lashed-together implementations we see in the field? Does it make sense to fix thousands of implementation flaws in a network service that shouldn’t even be anonymously available in the first place? What is true is that we have better tools for tracking buffers than tracking trust. That will change.

  Regarding the whole Art vs. Science vs. Engineering question, the harsh fact is that engineering discipline is driven by dead bodies, and since software barely kills anyone, it can get away with much looser controls. Equally harsh is that while it won’t kill anyone, it will take their money, and possibly their perception of privacy as well. So there’s definitely demand for security — it’s just not driven by corpses, and the costly retribution they demand. But that software engineering does not have the same drivers as aeronautical engineering, does not mean software can’t be engineered — or, more importantly, tested.

  I’ve had something of a painful quote burned into me: “If it wasn’t tested, it wasn’t written.” Someday I’ll get to tell the story of the bug that spawned that. The reality is that testing is a core element of any successful engineering effort, regardless of field. Software is harder than most things to test: Networks change many orders of magnitude faster than atmospheres (for now anyway), and weather is not known for being intentionally hostile. That does not make it “not engineering” to adapt to this much more difficult environment. It does however mean that a checklist will never entirely suffice for security analysis. Process is required to avoid the Cicada Defense for bugs — there’s just so many flaws, your defenders can’t possibly catch ‘em all — but attackers won’t stick to the list, and neither can you.

• John McDonald

  June 24th, 2008 2:07 am

  <– Kaminsky fan-boy

• Steve Christey

  June 24th, 2008 2:22 am

  Every year, CVE is at least 50% full of issues where David LeBlanc said: Most of the “security researcher” community is oriented around the 2nd bullet.

  But, the differences between “integer overflows are generally bad” and “integer overflows are security problems” (or, say, NULL pointers?) are initially found by the handful of Dowd’s of the world.

  The sad part is, some really interesting work gets lost in the shuffle when researchers find stuff that can’t be published due to NDA, or the researcher had the misfortune of making an interesting discovery in software that nobody cares about. I’m generally talking implementation bugs here.

  Maybe it’s just my own ignorance, but we don’t know crap about secure design, even assuming people follow the timeless truths from the 70’s.

• Thomas Ptacek

  June 24th, 2008 11:31 am

  Yeah. What Steve Christey said.

• Matt

  June 24th, 2008 11:58 am

  @Thomas: Congrats, it looks like you’re going for a record in ratio of length of discussion to length of original post.

  /has an opinion, going to keep it to himself

• Thomas Ptacek

  June 24th, 2008 12:23 pm

  Matt: You don’t do this blogging thing for 3 years without learning a thing or two about leverage.

• philosophy_guy

  June 24th, 2008 3:23 pm

  Wittgenstein says you’re all idiots who will likely and necessarily argue definitions into eternity.

  THANKS!

• Marcin

  June 24th, 2008 4:55 pm

  @Dan, I beg to differ. Software can and does kill people. Just read Geekonomics by David Rice. Anton did, and it changed his life!

• Dan Kaminsky

  June 24th, 2008 6:28 pm

  Marcin–

  Software can absolutely kill people, but lets be clear — far more people are killed by crashing windows, than by Windows crashing. Look around you. The paint on the walls, the empty soda can, the whiteboard marker, the chair you’re sitting on, the electricity lighting up the room, the lights themselves — any of ‘em can kill you, and not with a terrible amount of difficulty. Humans parse chemicals, sometimes badly. Humans do not parse bits.

• Marcin

  June 24th, 2008 8:41 pm

  Bits that parse humans… sometimes do it badly

• David LeBlanc

  June 24th, 2008 10:31 pm

  Lots of comments to respond to -

  Tom - you keep using words like “never”, and “nothing new”. These are polarizing and inaccurate. It’s unusual for something really new to come along. It does happen, just not often. What’s more typical is to see some existing, known problem be recognized as exploitable when it was not in the past. This happens largely because we keep moving the goalposts, and no one can do very well looking for strcpy these days. This is why I argue to just fix the bugs. If it crashes, fix it. If it goes down the wrong code path, fix it. I can’t guess now what will be exploitable 10 years down the road when this software nears end of life, and it is very possible a given piece of code might be in use for much longer than that. We now run some code written 15-20 years ago.

  I find the defensive aspect of the problem more interesting, since it’s harder. My assumption is that nearly any programming flaw can be turned into an exploit. Even usability bugs can be exploits.

  Though I have not looked at the exact flaw you mention in qmail, it isn’t that DJB didn’t know about an exploit pattern. I don’t think he was especially worried about what implementation flaws were or were not exploitable. Flaws are bad, and should be avoided. He just made a mistake. A good dev should understand how a computer represents numbers, and not just to avoid exploits. We’ve had rockets blow up and all sorts of other undesirable things happen because of lack of understanding of how a program models numbers.

  You also can’t have it both ways. You previously claimed that qmail was not secure because of solid engineering, now you claim it is. Glad you now agree with me (while telling me I’m wrong - whatever).

  John - whoa - I did NOT say anywhere that you’re at the bottom of the heap. Nor did I say that about Mark, and I certainly didn’t say he was less skilled than Dan - you’re all 3 extremely talented people. I have not said and will not say any such thing. I do not know Mark as well as I know you, but you’re quite capable of finding design flaws, and advising on how to fix them. You’re actually one of the best at this that I’ve seen, and certainly rank among the best in this business in my estimation.

  It’s also a very different skill set to determine new exploit patterns (not to be confused with new classes of flaws) than it is to merely poke at something until an issue is found that was learned from you or someone else. Explaining that to people in a way that can be understood is another skill, and your book is certainly one of the best out there. It’s one of about 6 that ends up living on my desk.

  There’s also significant value in explaining to the people doing much of the pen testing what a C++ bug looks like. Most of them aren’t good at C++, don’t recognize flaws, and will miss things in a review.

  To Steven’s comment that checklists will not suffice, he’s right, but checklists are not really engineering to me. It’s a fairly mindless approach. Checklists can be helpful, but are not sufficient.

  A key aspect of a proper engineering approach that is lacking from most software development is expecting faults, and putting guards in place such that faults are not catestrophic. For the most part, it is not a good idea to distinguish between ordinary flaws and exploitable flaws. You could wake up one morning to discover that something in the ordinary category had just become exploitable. Flaws are bad, but unfortunately, cannot be completely avoided. This is why we need layers of mitigations to get to higher levels of reliability. We all want to think that security is really something special. It is not. It’s just another way to have a reliability failure.

• Thomas Ptacek

  June 24th, 2008 10:48 pm

  You and I agree about the quality of DJB’s design. qmail is one of the best-designed programs of the past 2 decades. There are aspects of it that pioneered secure design in POSIX environments. And I’ll preemptively agree that those aspects were themselves straightforward extensions of Saltzer and Schroeder — least common mechanism and least privilege.

  You and I totally disagree about the real-world value of that design. Besides being a superb designer of systems, Bernstein is also simply a superb C programmer. The guy just breathes high quality systems code. If you read his code back through the Usenet archives — go grab his compression system — there’s absolutely a pattern of him reinventing the platform. Very few systems developers are also good library developers.

  You didn’t actually read up on Guninski’s qmail finding, but you seem happy to make an argument based on it. Go look at it, and then respond:

  There are two observations I make about qmail security:

  (1) It fell not to a simple coding error but to a mistaken assumption about the safety of an input. Bernstein fell victim to the idea that “parsing” is a security problem. Inputs are a security problem.

  (2) When it fell, the whole system fell. The value of Bernstein’s privilege-separated design was tested only once, and it didn’t work.

  I can think of a lot of worse systems where the “Design” of the system was considered carefully and separately from the “Implementation”, and those systems suffered for it.

• David LeBlanc

  June 24th, 2008 11:09 pm

  Got a link to the analysis of the problem? Considering where I work, I don’t just go looking at random code on the Internet. You stated it was a 64-bit int problem, so that’s what I know at the moment.

  DJB is an excellent programmer, but I have been told that it is difficult for others to read and maintain the code. It’s also easier to write solid code if there’s only a small number of people involved, and they’re all good. It’s a harder problem when there’s 1000 people involved.

  As Dan said, if it’s not tested, it isn’t written. Proper way to test such a thing is to substitute arbitrary_evil.exe for the component you’d like to protect against, and see what happens.

  You’re right about not considering design and implementation together being a problem. Kind of like designing a wing without specifying the material. You’d build it differently if it was carbon fiber, another if it were aluminum. Again, this is why we need to adopt engineering practices to get better at this. Despite the fact that software security engineering is not well advanced, doesn’t mean that continuing to try and design by the seats of our pants is a good approach.

  BTW, please do not put words in my mouth. I did not say “Mark Dowd’s no Dan Kaminsky.”

• Thomas Ptacek

  June 24th, 2008 11:23 pm

  (1) Google “Guninski qmail”.

  (2) I agree, it’s harder to write secure code at Microsoft than in a lab at UIC.

  (3) You’re missing my point. You could use a pencil and paper to see that there are implementation flaws that will give up the whole system. My point is, if you don’t get both right, you fail. I’m refuting your argument that design (and design assurance) is inherently more valuable than implementation.

  (4) I’m not making the argument that we should avoid engineering. I’m making the argument that we are avoiding it, almost universally. I don’t think we know enough about software quality to make assertions like yours.

  (5) You didn’t say that. Sorry. You just said something that sounded a lot like it. You also said I have no business arguing with you because you have a Georgia Tech degree. I’m happy to stop the meta-argument here, though.

• David LeBlanc

  June 25th, 2008 12:58 am

  Interesting. I keep telling people that 2GB might not be enough for everyone. There’s a reason that strlen and friends return size_t. I expect this class of bug to be more common over time, since porting to 64-bit can be difficult, and ints do weird things going from 32 to 64-bit. Many people do not expect size_t, ptrdiff_t, uint_ptr and int_ptr to be different sizes. I think we’re both right - he just didn’t recognize this as a flaw, so despite being a good programmer, he appears to be not so good with integers.

  As to design vs. implementation, this really depends. Hard to argue one is more important than the other, so I agree you have to have both. It is true that most of the bug hunters are bad at finding design flaws, so implementation flaws are more likely to be found. However, if a design flaw _is_ found, consequences could be ghastly. I’ll use DNS as exhibit A.

  Good engineering practices will find both types of flaw. For example, we design a wing, then we build one and see that it perfoms to specifications. When we put it into production, we test each and every component along the way. A sampling of rivets is tested out of every batch, and so on. So we first design, then test the design, then test the implementation, starting from a low level. Engineering isn’t just design - it’s validation along the way. Likewise, we don’t build a water treatment plant on the computer, then roll it out - we test scale models, vary inputs, and so on. If we built software this way, we’d be better off. For example, I built a system where one process operates as a server to another less privileged process. I also built a test rig, and that found bugs that could never have been consistently found in the field.

  It also depends on what you’re building - see my blog on when TM’s are worth it or not (Threat Modeling the Bold Button is Boring). Some apps are heavy on implementation issues, others design.

  I agree we’re not as an industry doing solid engineering, and that’s a bigger problem every day. We build things that affect lives, and ought to pay more attention.

  You can argue all you like - your blog. Thanks for apologizing - I don’t want to start a brouhaha with Mark and John, especially when the reality is that I think they’re some of the smartest people doing this. I did spend a really silly amount of time studying at GT, so do know a bit about actual engineering. Just because we don’t know much doesn’t mean we can’t do engineering - we just need to learn more to do it better.

• adamo

  June 25th, 2008 3:04 am

  David LeBlanc says: “I think we’re both right - he just didn’t recognize this as a flaw, so despite being a good programmer, he appears to be not so good with integers.”

  Do we really know that DJB designed qmail for 64bit systems? I mean if he only had 32bit systems in mind when designing qmail and the only flaw found is when it runs on a 64bit platform, does this count as a design flaw from his side? Does it count as an error in judgement for those who decide to run qmail outside its working domain?

  (I have not looked at qmail code either, so feel free to flame me).

• David LeBlanc

  June 25th, 2008 3:37 am

  Whoever did the port would be the one to make the error. I think the main flaw, which is a very common one, is not to follow the current standard for the C/C++ CRT, which says that sizes ought to be type size_t, and instead assigned it to an int. Second error is in either not using a compiler that will warn about 64 to 32-bit truncation, or ignoring warnings. This is one place a good checklist could have saved them - compiling /W4 clean as cpp might have caught this.

  IMHO, this is a pure implementation flaw, but one could argue that a proper design would (as Tom points out) consider the implementation limits, and if there’s ints running around everywhere, would then limit all inputs to 2GB so that ints make sense.

• John McDonald

  June 25th, 2008 6:54 am

  @David: Ah, no worries.. I misread your post slightly but didn’t take it personally, and Mark is a soul-less internet killing machine so it’s hard to interpret his reaction in normal, human terms. :> Naturally, the respect is mutual. (Christ, we should all just get a room.. mmm… MSFT-sponsored mutual-respect rooms..)

  I really just wanted to make the point that, in so far as the design/implementation distinction is meaningful, design and implementation assessment have a lot in common when they are performed well.

  @Thomas: You have to admit that djb’s code is at least a little bit crazytown. I mean, wasn’t it a point of contention at some point as to if he actually wrote it in C originally? Granted, it appears that this is the kind of alien technology of which we could use more.

  @philosophy_guy: Nah, I think you’ll find that most of us are interested in sketching out common ground, synthesizing information, and moving forward. (Except Thomas, who is mostly interested in leverage and exploiting our various personality disorders. :> ) The work itself tends to necessarily cause us to reach similar ideas and conclusions, though we call them different things and tend to conceptualize them in ways that glorify ourselves.

• John McDonald

  June 25th, 2008 8:42 am

  One quick point - I mentioned Sutter’s “Exceptional C++” as a book that covers a lot of good C++ information that can be re-interpreted in a security context. I got slightly confused, as this is a great book, but we actually got a bit more mileage (for our purposes) from Meyers’ “Effective C++.”

• Thomas Ptacek

  June 25th, 2008 9:53 am

  There’s an essay at the end of Meyers MEC++ on exception-safe programming that I go to alot. An even better book for modern C++ is Effective STL Programming. Just look for the opposite of effective STL.

• Gabriel Kent

  June 25th, 2008 6:34 pm

  Fail.

  Though I am not a security professional, I am rather good with semantics

  Let’s start with the basics::

  Engineering - the art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants.

  Art - the quality, production, expression, or realm, according to aesthetic principles, of what is beautiful, appealing, or of more than ordinary significance.

  Science - systematic knowledge of the physical or material world gained through observation and experimentation.

  Hmm… I was going to insert a lengthy analysis here but come on, don’t tell me you still fail to see the answer.

  When arguing semantics, RTFM.

  (;||<

  (http://www.randomhouse.com/catalog/display.pperl/9780375426056.html)

Leave a reply

name (required)

email ( will not be shown ) (required)

website