Hacker News Reader

Comment by 2sk21 | Hacker News Reader

Open source is very vulnerable to manipulation. Some years ago, I spent some time trying to understand the PAM module LDAP module on Linux (PAM is used to enable external authentication so its critical code). I found it to be completely impenetrable. We take such components for granted but if someone could inject malware into such code, it could be catastrophic.

View on HN

Not to mention it must be trivial for a large and determined adversary to subvert Debian, Arch or other distributions' packaging process, for example by getting a "sleeper" rogue developer in there. As someone into security and using open-source systems exclusively, it would be somewhat embarrassing to become a security problem yourself that way.

I don't distrust Linux distributions' respective security guidelines; but it can't be that hard to find a loophole in community-driven system/software development and the damage would be substantial if a popular Debian package would have been subverted and have gone out with updates.

The same statement could be made about any organization. If you get a sleeper agent into Apple, Google, Microsoft, whatever... There is a certain amount of goodwill we rely on in this world.

Exactly, no organisation is immune to sabotage.

It's not quite the same thing as, AFAIK, the debian project doesn't have the same power as an employer does to do background checks before hiring.

There's a significant level of risk around open source projects changing hands, something which may be invisible to the users of those projects, especially as they become more heavily used and therefore more tempting targets for attackers.

Employers only have that power because you grant it to them. Of course you don't have a lot of choice if you want the job.

In theory, Debian or any organization could do the same background check, but is that the best use of their limited resources? And would they want to do it anyway given the ideals of the general OSS community?

Sure, my point was companies do do that checking and Debian doesn't do that checking, so from the perspective of this risk, it would be harder for an attacker to do this to a large corporate like Microsoft than it would to do it to an open source project like debian.

Most large software companies do continuous scans of their own source code looking for potential backdoors. Obviously this is not guaranteed to catch such attempts but definitely necessary in the current environment where Zero days are so valuable.

Most of the tools I know in this space look for known issues.

OSS teams could spend the time and money running these tests, but this seems like a good area where governments and companies can step in to help.

But companies wouldn't give commit access to somebody they just "hired" over the internet that "wants to help", and they'd (hopefully) have multiple layers of code sign-off before it ends up in the repository. Having worked in PCI-DSS environments, it would not be easy to get code into production without anybody else noticing.

Open-source projects often have random people "from the internet" working together with a great deal of individual autonomy (authority doesn't go down well when you are contributing for free). This ad-hoc style works well for open-source development, but it does make some kinds of code/system subversion a lot easier and we'd do well to keep that in mind.

Besides, I'm into open-source and security exactly because I don't want to rely on the goodwill of Apple, Google and Microsoft. ;)

I'm pretty sure this is somewhat unique to the history of pam_ldap and its stewardship by PADL Software compared to other PAM modules; its dense nature encourages commercial engagement for those who care enough to know how it works or want to use it for their own purposes. They're not motivated to make it easier to understand (i.e., for outsiders to contribute to or maintain).

pam_sss is easier to understand and its functionality expands upon it, but it was a redesign.

This is really fascinating - I agree that PAM LDAP appears to be especially obscure compared to other modules.

I think that is an unavoidable consequence of the openness.

Reply on news.ycombinator.com