Slashdot Mirror
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?
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?
If you use a third-party library that has a bug in it, you'll be exposed to the same bugs that everybody else using that library are. On the other hand, if you go at it alone, your implementation will have bugs of its own. And if the library is well-maintained, it'll have fewer bugs than the thing you make from scratch.
Implementing the common functionality from scratch can easily become another kind of "not exercising due diligence", particularly when dealing with complex code. Or to put it another way: code reuse may endanger secure software development, but not reusing code may also endanger secure software development.
The alternative, which is everyone writing their own mostly terrible implementations, is far worse.
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).
The problem is that if software is working, and you "upgrade" it, two things can happen: it can continue to work, or it can fail, often mysteriously. Given that, it's not shocking that people tend to leave software alone if it is currently functioning.
Don't you think some code that has been run 10 times might be more secure than code that has been run 10 million times? After all it's less worn out.
I want to agree with you in theory (especially about how apps often get made worse for no good reason), but practice, it's simply not practical to leave most software alone - at least, not if you want it to have any sort of reasonable lifetime. The difference is that modern software rarely lives in isolation. The ecosystem on which it runs... the OS, it's system libraries, third party libraries, the tools on which the software was developed... these are all moving forward in time.
If you leave a piece of software alone, it experiences "bit rot" NOT because it's changing, but because everything around it is probably changing. More importantly, the more time occurs between updates, the more difficult those updates tend to be, until it becomes easier to actually rewrite the damned thing, since the original development system on which it was written may not even exist in the same state anymore. You may argue that software shouldn't always be changing, but you might as well ask for the Earth to stop spinning. Security issues alone will force a minimal level of change will occur.
Updating continuously has its pain points, but any issues that come up tend to be smaller issues, and can be dealt with more quickly. For example, just the other day I realized MacOS's system Cocoa libraries slightly changed something which broke my code in a number of places, even though I wasn't doing anything sketchy with the API. But a slight change in definition meant I needed to cast some interfaces explicitly, and add new interface functions to retrieve those explicit interfaces. It was a bit of work to track this down and solve it, even for the relatively small amount of code I was dealing with.
I saw one person on StackExchange say they "solved" it by linking their project against the older version of the library. That "solution" just stacked some technical dept on some poor future programmer, even though it 100% works for now. It may even allow such code to propagate in the future, making the eventual conversion even worse when it happens.
Moreover, leaving functionality alone and patching only security issues becomes a game of maintaining a *very* long history of supported versions of software. How long does support last? Yes, this is the correct answer for some software, but remember that companies generally pay very well for these long-term support versions, even for Linux, because maintaining a current build is expensive (I have some recent experience with this). For most consumers, the simplest and most economical option is just to keep everything up to date, and yeah, that means taking the bad with the good.
Irony: Agile development has too much intertia to be abandoned now.
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.