" title="Mu Dynamics Blog">Mu Dynamics Blog - insites into vulnerabilities and secure coding practices

Just finished reading Zen and the Art of Motorcycle Maintenance for like the 100th time. I responded to a recent post on Daily Dave and somehow it seemed to trigger some thoughts about romantic and classical perspectives on software bugs. If you’ve read the book at all, neither perspective is right or wrong, except they are just different ways of looking at the same problem and both are equally valid since Quality is what drives them and more importantly creates them.

To paraphrase, romantic view appreciates how things look from the outside, while the classical view is about how things really work, under the hood so to speak. It seems that in the past decade or so, there’s been a split between the talented engineers that develop software and the security engineers that find faults in them and neither parties seem to agree on their differences. When the so called “security” engineers find exploitable bugs, the software engineers get all defensive, their eyes glaze over and refuse that such a problem exists. In my past life I ended up using what’s now known as an XSS to solve a customer problem (and yes we won that deal). With the knowledge that I have now, that would have been a fun advisory to release. Times sure have changed.

Most talented software engineers are tuned to responding and fixing complex bugs. Inputs that trash memory, race conditions, uninitialized variables, double-free’s and other strange memory leaks that over time cause degradation. Ever since the “Smashing the stack for fun and profit” phrack article, there are a class of individuals that look at these P1 bugs very differently since they control it from the outside. Attack vector is one such name for these bugs since they are not caused by normal operations, but are triggered by the attacker.

So what really is a security vulnerability? I guess a good definition would be: “a bug that’s on the attack surface“. It may not necessarily be exploitable since a DoS in the right context could be as critical as a stack/heap overflow. In the process of using our product, we’ve found bugs in core routers that knock them offline for 5 seconds with just a simple malformed ICMP packet. Is that a vulnerability or a DoS or a P1 bug?

Until we reconcile differences between these two groups that look at Quality as different sides of the same coin, I guess we will continue to have arguments about full disclosure, responsible disclosure, exploits vs. bugs, etc. Maybe it’s time we argued and reasoned for the same cause?