Digg this story   Add to del.icio.us  
Bad-Code Blues
Don Parker, 2008-07-08

The current state of secure software development by corporations both large and small is a mess.

We are still cursed with half-baked software, and as a result, a never ending stream of vulnerabilities. Secure coding practices and active quality assurance (QA) efforts are now more mainstream, but that still hasn’t made much of a dent.

Today’s Internet experience is marred by the ever present threat of the malicious hacker, and what gives these malicious hackers the ability to compromise a computer is quite simply poorly written code. The prevalence of insecure programs has reached epidemic proportions. Take a look at the full disclosure lists and other sites which host exploit code repositories. While you may find that not every exploit on such sites affects enterprise applications it does point to a disturbing trend in shoddy coding and of complacency on the part of software vendors.

Software vendors need to realize that they must begin exercising due diligence when producing their software products. Microsoft dedicated itself to secure development practices some years ago, yet its developers are still taking months to fix reported vulnerabilities. If an industry giant like Microsoft cannot get a grip, it really does not bode well for the rest of the industry.

While many companies make a passing attempt at improving their software products all too often other pressures win out. Software companies that will delay a products launch for the sake of a code audit, third-party threat testing, or an extended quality-assurance (QA) cycle are few and far between. Sadly, the secure development life cycle (SDLC) is not always adhered to by the software vendors, and the first casualty in this process is typically quality assurance.

This is just one of the more obvious failings on the part of the software vendors. Others are not so obvious.

Many have said that it is realistically impossible to expect a human to generate perfect code. Even more so, once a software program's code tree begins to number in the hundreds of thousands of lines of code. Some people believe the answer is to use programs which will perform automated code audits. Yet, this is not a comprehensive solution. While these tools often catch some low-hanging fruit, they are still labor intensive and also have one big downside -- a high false-positive rate.

Despite the claims and tough-to-corroborate statistics of vendors who sell such code-auditing programs, a hybrid approach to securing program code is best. A preferred method of the security professional is to disassemble a program and look for bugs in it, a technique known as black-box testing. One advantage of this type of audit is that it does not require access to the source code, but only to the program. It is, however, a very time consuming process and requires a high degree of skill.

Yet, this method is likely how most of the full-disclosure lists today get populated with the never ending series of exploits. One can, and many often do, combine this method with source code auditing tools if they have access to the source code.

Of vendors and researchers

In many cases, the affected software vendor never finds out about the results of a black-box analysis on its applications, because vendors and researchers continue to fail to see eye-to-eye on the issues surrounding disclosure.

Software vendors should be very happy to have these bugs reported to them in the ethical manner most researchers use, but many vendors react with legal threats, outright indifference, and, at times, with a professional attitude. It is still rather puzzling then that some vendors treat researchers with hostility or indifference when they are in essence donating a good deal of free QA testing.

One reason why this hostility and indifference is prevalent today is that the vendors know that their consumers are a captive audience. Fortunately, or unfortunately, the vast bulk of today’s computers run a flavor of Microsoft Windows, and all programming is done for that operating system. Far fewer people use the open source alternatives -- such as Linux or BSD -- or a Mac alternative. Those operating systems and their third party programs are not bug-free, but if they had provided a viable alternative to Microsoft's software in the past, then we might have seen a distinct improvement in the quality of Windows-based programming today.

It’s not all doom and gloom

A fair number of companies begun operating under the mantra of secure coding. While this does take more time then the normal practice of churning out lines of code, it pays huge dividends in the end.

Yet, it also takes management to buy into training for the in-house programmers to learn how to properly approach coding, and more importantly, do so with a secure-code mindset. This approach comes with a very real price, one that is measured in dollars, as it takes longer to bring a product to market. In the end, however, the company has a product that is not regularly gracing the electronic pages of a full disclosure list and possibly adversely affecting a company’s reputation.

Yet, perhaps the best way to drive better security in the marketplace is through economics.

Companies looking at purchasing a software program can take some simple steps to ensure they are getting a quality product. Insist that the vendor produce documentation which clearly demonstrates that they have completed a third-party audit of their program. Completing such an audit speaks volumes about the vendor’s commitment to their product.

After all, expecting due diligence on the part of software vendors should not be too much to ask.

Don Parker, GCIA GCIH, specializes in intrusion detection and incident handling. In addition to writing about network security he enjoys a role as guest speaker for various security conferences.
    Digg this story   Add to del.icio.us  
Comments Mode:
Bad-Code Blues 2008-07-09
Bad-Code Blues 2008-07-09
Anonymous (1 replies)
Re: Bad-Code Blues 2008-09-09
Bad-Code Blues 2008-07-09
Bad-Code Blues 2008-07-18
Anonymous (1 replies)
Re: Bad-Code Blues 2008-07-21
Don Parker (1 replies)
Re: Re: Bad-Code Blues 2008-08-05
Brad Cox
Bad-Code Blues 2008-07-28
Purple Ronnie


Privacy Statement
Copyright 2010, SecurityFocus