4

I'm curious as to whether there are any noteworthy cases historically of people deliberately placing exploits in open-source code libraries used by others, either something relatively obvious with the hope nobody will check, or with something underhanded that's easily exploitable as a back-door?

It seems to me like the rise in the types of developers who blindly glue libraries together would lead to a world where this is much more common, but I'm having trouble identifying any actual cases of it occurring.

It would seem to me that injecting arbitrary unvetted code from untrusted third parties is a pretty high-risk endeavor that startups are throwing around with reckless abandon, so I'm just wondering why I'm not aware of any catastrophes yet.

Improve this question
3
  • related because it is a similar attack vector: Typosquatting programming language package managers
    – Steffen Ullrich
    Commented Jul 13, 2016 at 5:13
  • not a backdoor, but the transmission torrent client was infected with ransomware recently: theregister.co.uk/2016/03/07/…
    – Jay
    Commented Jul 13, 2016 at 8:02
  • the more gluing they do, the safer the code gets because more people gripe when something doesn't work, or when it fails one place for the first time. combine that with attached unit tests, and it's been reliable.
    – dandavis
    Commented Jul 13, 2016 at 8:41

1 Answer 1

Reset to default
1

You're right, deliberate injection isn't common in the open source world, in part because the process makes it expensive, but mostly because it's not necessary.

Most open source projects that gain traction have users who exercise lots of use cases and need careful custodians who respond to problems and know their committers, so arbitrary pull requests from new developers go through a vetting process, and in order to get their code in, participants have to be invested in growing a reputation and building trust. This all makes deliberate injection of vulnerabilities difficult.

And it's not necessary because software is vulnerable by default. From an attacker's perspective, there is no reason to go through a trust charade to inject vulnerabilities, because there are already going to be some in any codebase, you just have to look for them. And because the code is open, you can look for them without anyone knowing you are looking for them.

In the closed source/commercial world, injection is much more common, for instance:

https://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/

For those attackers at that scale it makes sense to build and then sacrifice trust, though that is a very expensive exercise. The infamous case of Dual_EC_DRBG is instructive, because it was an injection in a world that resembled open source in terms of dynamics, with the result that a previously trusted actor (NSA) working in a previously unblemished open process (NIST) has forever sacrificed their own and the process' credibility. Check wikipedia for details.

The model you suggest- third parties utilizing a process that does not require trust to inject attacks or vulnerabilities- accurately describes the delivery model for web malware.

Arbitrary, unauditable, and precisely targeted third party code- layers of javascript, flash, and so forth that delivers ads, captures metrics, provides sharing buttons and does tons of other stuff- are loaded into the browser on behalf of the first party domain the user is visiting, usually with very little to no awareness from the first party or from the user. It's highly risky for users and of course catastrophes happen all the time:

https://www.proofpoint.com/us/threat-insight/post/massive-adgholas-malvertising-campaigns-use-steganography-and-file-whitelisting-to-hide-in-plain-sight

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .