Comments on: Evolve or Die

By: Michael Dickey

Michael Dickey — Fri, 31 Aug 2007 11:47:14 +0000

Just to clarify…code security can change:
- due to changes in assumptions (such as Dan’s underlying libraries in the above comment)
- due to changes in the actual code (patches, tweaks, rewrites)
- due to changes in the attackers or environment (new discovered methods of compromise
- due to changing standards/specifications (we didn’t care before that sales people had access to the data this code protects, but we do now because of outside compliance, which changes the original spec of the code)

By: Michael Dickey

Michael Dickey — Fri, 31 Aug 2007 11:44:11 +0000

I’m with Ryan’s comments above. The code doesn’t necessarily change or wear out, but subsequent patchings (if they occur) can degrade old code, plus new techniques like fuzzing can reveal inherent flaws and bugs that were always there, just never found before.
Those consultants may have done a fabulous job and, in that day, the code may have been as secure as they knew how to secure it. But…time reveals all…

By: Dan Weber

Dan Weber — Wed, 29 Aug 2007 13:00:40 +0000

Software can definitely become more vulnerable over time.
I can write a piece of software which includes libfoo.so, but uses one of the library calls in an undocumented way. However, with the version of libfoo.so that I’m using, my software is absolutely unexploitable.
A year down the road, the libfoo maintainers release a new version, fixing some other security problems, and changing the way that my library call works. Now I am exploitable, even though my code never changed.
I suppose that one could stretch things to say that my use of the library in an undocumented is the vulnerability. But then I could change my scenario to one in which the library maintainers change their documentation so my use at the time was within the library’s spec at the time, even if it isn’t now.
This example really isn’t that far-fetched, because in a Web 2.0 world pieces of the running software are everywhere. Instead of changing libfoo.so, the web browsers and protocols and operating systems change all around you, like Marty McFly finding himself in a stange new world because Biff changed the world.
For example, you rely on JavaScript to enforce the same-source policy in the ECMAS spec, but there are common browsers out there which ignore it, which lets your users have all their cookies stolen. Oh, sure, it was the browser that had “the bug,” but do you think your customers care?
Do you think CSRF attacks are a flaw in the web browser or in the web application? Should a web application written in 1997 have cared about someone browsing the web with multiple tabs? Or with a browser that has a version of Javascript that lets the refer(r)er location be altered?
And, really, does it matter? Unless you’ve written some weird contract that says you get to force the people who wrote your “secure application” 10 years ago to fix the vulnerabilities in it that were always there, does endless semantic arguments gain anyone anything?
(Well, maybe it does, if Bruce Schneier manages to get any traction with his “make developers responsible for the vulnerabilities they make” proposals.)

By: Ryan Russell

Ryan Russell — Wed, 29 Aug 2007 11:52:56 +0000

I wish to argue semantics.
The vulnerabilities were there the whole time. Only more of them are found over time (yes, due to new techniques.)

By: Iang (It's your job, do it.)

Iang (It's your job, do it.) — Wed, 29 Aug 2007 11:25:56 +0000

I think in the future we are going to change track. Bringing in the rafts of consultants and know-it-alls to fix what we did wrong didn’t work.
For a start, there just aren’t enough consultants to go round, and that’s even before we filter out those who are narrowly focussed on their little patch, and are therefore out of sync with needs.
It seems fairly logical, inescapable even, that if the consultants can’t do it (for whatever reason) then it’s the client’s job. He has to do it. The client has to build the security system, to suit needs. Outsourcing security is negligence.
In the future, we may be bringing in teachers instead. The goal is to learn how to do it right, ourselves. (Yup, Microsoft probably got that principle right.)

By: Pete

Pete — Wed, 29 Aug 2007 10:36:53 +0000

My comments here: http://spiresecurity.typepad.com/spire_security_viewpoint/2007/08/can-your-unchan.html [Fixed URL-ed]