Does Code Reuse Endanger Secure Software Development? (threatpost.com)

msm1267 quotes ThreatPost: The amount of insecure software tied to reused third-party libraries and lingering in applications long after patches have been deployed is staggering. It's a habitual problem perpetuated by developers failing to vet third-party code for vulnerabilities, and some repositories taking a hands-off approach with the code they host. This scenario allows attackers to target one overlooked component flaw used in millions of applications instead of focusing on a single application security vulnerability.

The real-world consequences have been demonstrated in the past few years with the Heartbleed vulnerability in OpenSSL, Shellshock in GNU Bash, and a deserialization vulnerability exploited in a recent high-profile attack against the San Francisco Municipal Transportation Agency. These are three instances where developers reuse libraries and frameworks that contain unpatched flaws in production applications... According to security experts, the problem is two-fold. On one hand, developers use reliable code that at a later date is found to have a vulnerability. Second, insecure code is used by a developer who doesn't exercise due diligence on the software libraries used in their project.
That seems like a one-sided take, so I'm curious what Slashdot readers think. Does code reuse endanger secure software development?

Comments

Code reuse is a good thing

[davidwr]

Granted, if it's closed-source you have to trust the library vendor. If it's open-source, you either have to do due dilligence or trust someone else who claims to have done so.

I assume we are talking about re-using source code, linking with staticly-linked libraries, and using and "private copies" of shared libraries binaries (e.g. /usr/local/bin/applicationname/lib/lib1.so or C:\Program Files\Application\DLLs\MyDll.dll). With "public" shared binaries (/usr/lib/sharedlib.so or C:\Windows\...\MSDLL.DLL), you are relying on the library or OS vendor to keep things patched.

Here's an example:

I know of a popular product that uses its own private copy of Java. If the vendor doesn't update their customer's versions of Java on a regular basis, an attacker can exploit it, even if the user is updating the "Oracle" version of Java on a regular basis. That's bad. On the other hand, they would probably be in a worse of a position of the vendor re-wrote the functionality of Java in-house, as that code would have its own set of bugs and it would likely NOT be as maintined as Java is. The solution is to use the "Oracle" version of Java instead of a private copy, OR push out updates to the private copy within a day or two of Oracle pushing out their updates.

Re:On the balance, most likely not.

[beelsebob]

The issue isn't even "using 3rd party code", it's "static linking 3rd party code". If people learned to dynamic link libraries, rather than compile them in, then this wouldn't be a problem at all. If the OpenSSL guys learned that distributing only as a static library is a bad thing, and learned to make their ABI stable, then heart bleed would be a lot less of an issue.

Secure Software

[ledow]

What's needed is better operating system management, not better development practices.

Once a piece of software is patched, the problem is fixed. That's not the issue at hand. The issue is that that fix then does not make it back to production systems in a decent time.

What's needed - and I've posited this a number of times for a number of things - is a central repository which lists which, say, linux packages are secure and which are not. Which algorithms, hashes and cryptosystems are compromised or not.

Then there needs to be an API - running a production system live on the Internet? It will check its version numbers and package hashes against the centralised "uncompromised" versions service. If there's a discrepancy -a package that's been marked as potentially compromisable, but which has an updated or patched version available - the OS is tainted much like the kernel is tainted. If MD5 is retired and any software on the machine still utilises it, the system is marked as tainted as soon as it checks into the centralised API.

We've needed this for hashs and crypto systems for a long time. SHA-1 is retired, but how do you KNOW that? And how do you know what uses that? Nobody would recommend building a system using WEP or MD5 in this day and age but nowhere is that listed in a queryable manner.

And then you start saying "Why weren't Facebook checking their systems against the Secure Software Database? Their own fault if they were compromised.", "Why did Yahoo not re-hash with a listed-good algorithm as soon as their existing hash was obsolete?", "Why were they compromised? Because they turned off database checks and updates? Idiots".

There needs to be a way for production systems to algorithmically say "This is no longer acceptable practice" and start making a fuss such that the system maintainers are forced to start upgrading, with specified timescales (the API could easily obsolete stuff on a set timescale, with warning enough to test changes to newer algorithms).

Then, if you're compromised because you ignored this, or because you hard-coded MD5 instead of using libraries, all the fault will be in the your third-party, unlisted libraries. And then you might be able to actually start forcing vendors to publicly state "All our software uses the latest database-compatible algorithms, software and patches" rather than just hope that someone at Google isn't just running Slackware 2.0.

The software can be fixed in a trice. The problem is getting that fix out to production systems in good time, and not being able to sufficiently shame those who don't manage their systems (it's easy to blame a hack on the software, rather than your lax update practices).

Re:The problem is often maintenance

[nmb3000]

Disagree. Software is not a washing machine nor a car. It does not break down over time, it is not susceptible to the elements, and it does not age in any notable way. There is literally no reason a program written and working in 1970 cannot continue to execute as well today as the day it was written. And it does! Industrial control systems, ancient government and finance mainframes, and primitive vehicle control systems all do it every day. Software doesn't rust and bit-rot is not a thing. Telling people that they need to keep their programs polished to prevent tarnish sounds like something a sketchy Geek Squad-esque computer shop might do to squeeze a hundred bucks out naive customers.

I update my software sparingly and with caution. Generally speaking, it's much more likely that usability to be lost or features broken than a serious security issue fixed. If it's a mobile app, it's much more likely that ads were added or made worse, or a feature I've used for 2 years was removed or horribly changed, or increased permissions are requested so that my personal info can be sent away to some third party than any features I actually want were added or bugs fixed.

Today's model of always-updated has some advantages but every single one is counterbalanced by the negatives. Auto-updating browsers help prevent the mire of zombies that was IE6, but it also means you're at the mercy of Microsoft, Mozilla, and Google when it comes to feature removal and their incessant need to screw around with the UI for no valid reason. Or that addon you really like and rely on suddenly stopped working because the author hasn't updated it yet.

Yes, updates to address security problems is an important topic, but all too often those updates are bundled up with all sorts of crap that few people want. It would be real nice if software companies would keep the two separate, and make it clear just what has changed between versions.

Re:uh, no

[ewanm89]

I suppose you know how timing side channel attacks are done? All those layers of abstraction make it possible to accurately predict and alter code path length? Oh, and they do automatically handle things like proper memory scrubbing of keys when no-longer valid? Right?

These things need low level hardware access to manage, and are hard even then where there is less in the way screwing with it. It is nearly impossible to handle properly on highly abstracted languages running in managed virtual environments like Java and C#.

Yes those abstractions help avoid specific classes of vulnerabilities, but can open a whole host of just as bad context specific ones when talking about security stuff like encryption. This is why we should only let specialists in that specific field do such implementations and have them vet each others code.