Think that software library is safe to use? Not so fast!
In todays world of agile software development and fast release cycles, developers increasingly rely on third-party libraries and components to get the job done. Since many of those libraries come from long-running, open-source projects, developers often assume theyre getting well-written, bug-free code. Theyre wrong.
The major patching efforts triggered by the Heartbleed, Shellshock and POODLE flaws this year serve as examples of the effect of critical vulnerabilities in third-party code. The flaws affected software that runs on servers, desktop computers, mobile devices and hardware appliances, affecting millions of consumers and businesses.
However, these highly publicized vulnerabilities were not isolated incidents. Similar flaws have been found in libraries such as OpenSSL, LibTIFF, libpng, OpenJPEG, FFmpeg, Libav and countless others, and these have made their way into thousands of products over the years.
Among the reasons why these bugs end up in finished products is a belief by developers that the third-party code they choose to integrate is secure because it has already been used by many others.
The shallow bugs myth
There is a myth that open source is secure because everyone can review it; more eyes reviewing it making all bugs shallow, said Jake Kouns, CISO of Risk Based Security, a firm that specializes in tracking vulnerabilities. The reality is that while everyone could look at the code, they dont and accountability for quality is deferred. Developers and companies that consume third party libraries are not allocating their own resources to security test someone elses code. Right or wrong, everyone seems to think that someone else will find the vulnerabilities and what is published is secure.
The reality is that many open source projects, even the ones producing code thats critical to the Internet infrastructure, are often poorly funded, understaffed and have nowhere close to enough resources to pay for professional code audits or the manpower to engage in massive rewrites of old code.
OpenSSL is a prominent example of such a case, but far from the only one. After the critical Heartbleed bug was announced in April, it was revealed that the OpenSSL project had only one full-time developer and that the project was being primarily funded through contract-based work that other team members did in their spare time for companies in need of SSL/TLS expertise.
The developers of OpenBSD criticized OpenSSL for maintaining old code for platforms that few people care about and decided to fork the project to create a cleaner version of the library dubbed LibreSSL.
The flaws in open source libraries are often the result of one or more of these reasons: old code or low code maturity, insufficient auditing or fuzzinga process of finding vulnerabilities by automatically feeding unexpected input to applicationsand too few maintainers, said Carsten Eiram, the chief research officer of Risk Based Security. We see that many vulnerabilities being found in these libraries are by researchers simply running some of the latest fuzzers against them, so its often something the maintainers or companies using said libraries could do themselves. Software vendors are quick to implement libraries into their products, but rarely audit or even fuzz these first or help maintaining them.
See more here:
Think that software library is safe to use? Not so fast!