Why don’t we do that?

Reading a story on the consequences of the theft of Adobe’s source code by hackers, I come across this startling phrase:

The hackers seem to be targeting vulnerabilities they find within the stolen code. The prediction is that they’re sifting through the code, attempting to find widespread weaknesses, intending to exploit them with maximum effect by using zero-day attacks.

What I’d love to know is why we aren’t seeing a flood of developers crying out to be educated in how they, too, can learn to sift through their own code, attempt to find widespread weaknesses, so they can shore them up and prevent their code from being exploited.

An example of the sort of comments we are seeing can be found here, and they are fairly predictable – “does this mean Open Source is flawed, if having access to the source code is a security risk”, schadenfreude at Adobe’s misfortune, all manner of assertions that Adobe weren’t a very secure company anyway, etc.

Something that’s missing is an acknowledgement that we are all subject to the same pool of developers.

And attackers.

So, if you’re in the business of developing software – whether to sell, licence, give away, or simply to use in your own endeavours, you’re essentially in the same boat as Adobe prior to the hackers breaching their defences. Possibly the same boat as Adobe after the breach, but prior to the discovery.

Unless you are doing something different to what Adobe did, you are setting yourself up to be the next Adobe.

Obviously, Adobe isn’t giving us entire details of their own security program, and what’s gone right or wrong with it, but previous stories (as early as mid-2009) indicated that they were working closely with Microsoft to create an SDL (Security Development Lifecycle) for Adobe’s development.

So, instead of being all kinds of smug that Adobe got hacked, and you didn’t, maybe you should spend your time wondering if you can improve your processes to even reach the level Adobe was at when they got hacked.

And, to bring the topic back to what started the discussion – are you even doing to your software what these unidentified attackers are doing to Adobe’s code?

Are you poring over your own source code to find flaws?

How long are you spending to do that, and what tools are you using to do so?

Published Sun, Nov 3 2013 16:11 by Alun Jones


# re: Why don’t we do that?

Is looking at code even a sensible way to find security issues?  It seems more likely that the attackers would be using the source code to help improve their ability to quickly analyze and exploit potential vulnerabilities discovered via other techniques such as fuzzing.

(Well, I guess they might be searching for instances of calls to known-risky functions such as unsafe string copies and examining them manually.  But it still seems an inefficient approach.)

Tuesday, November 05, 2013 9:28 PM by Harry Johnston

# re: Why don’t we do that?

There are a number of automated tools you can use to look at source code - although many of them have analogues that will look at object and/or executable code for errors. You can also use source code to find known dodgy areas of code - SQL statements, authentication, SSL preparations, etc - and then have an experienced human look over that code.

Finally, of course, one area of source code analysis that is often ignored is that of examining the comments. Search for "TODO" or various words that mean "this needs fixing". Developers are often aware, as they write code, that it is incomplete or broken. Sadly, they often forget to come back and fix these broken bits.

Wednesday, November 06, 2013 9:48 AM by Alun Jones

Leave a Comment

If you can't read this number refresh your screen
Enter the numbers above: