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

On the balance, most likely not.

[Place a name here]

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.

They can't be serious.

[mthamil]

The alternative, which is everyone writing their own mostly terrible implementations, is far worse.

Re:The problem is often maintenance

[murdocj]

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.

Of course not (with caveats)

[bsDaemon]

Code reuse is a fundamental tenant of secure software development lifecycles. You reduce the chance that you introduce new vulnerabillities by limiting the amount of new code per project to the core business logic and leveraging existing modules for the support infrastructure.

That said, if the module you reuse has problems then you aren't necessarily better off. The modules need to be vetted and maintained appropriately. Code reuse isn't the problem so much as taking random crap from the internet that solves your problem without assessing its suitability for inclusion given your threat model or properly assessing it for vulnerabilities.

Monoculture can be an issue from certain perspectives -- flaws in the libssl portion of OpenSSL affect a huge percentage of the internet. However, they only need to be fixed once and consumers of the library can all receive the update, assuming proper patch management in the environment. If your company uses 15 different libraries to perform a specific software function across different product lines without a basis in engineering requirements constraints, you're doing it wrong.

Security being a subset of correctness, I think overall it is b.s. to say code reuse is a problem. You just need to make sure you are reusing correct, vetted and maintained code. I.e., don't take strange code from someone's github to use in your enterprise software without reviewing it.

Depends on the library

[AuMatar]

A well known, maintained library such as OpenSSL? You're far more secure using the open source library. Not only do you need to be an expert to correctly and securely implement that level of cryptography, but it can contain all sort of subtle bugs you're unlikely to catch.

Now if you're talking about some random library you found on github because some guy on stackoverflow said to use it? That makes you less secure. Don't put random things you found on the internet into your program without reading the code, understanding what it does, and doing a full audit on it first.

And there's a special place in hell for anyone who uses gradle, nvm, or anything else that automatically downloads the library for them without specifying an exact version. You're just asking to be screwed by a trojan horse. Leftpad was about the best case scenario, imagine if leftpad had changed their code to be a backdoor instead?

Re:uh, no

[Narcocide]

You're like one of those people who thinks Java was written with more Java and its just Java all the way down, aren't you?

Re:uh, no

[rholtzjr]

How about avoid C common mistakes instead of avoid C would be a better statement. C done right is a solid language to use depending on the project.

Re:The problem is often maintenance

[Dutch Gun]

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.