Backdoor in ssh-decorator package | Hacker News Reader

Backdoor in ssh-decorator package

reddit.com

50 pointsjbfoo11 comments

The solution to the impersonation aspect of this is commit signing. It is literally built into Git. There are no good excuses for project maintainers to not sign commits at this point. Grab a yubikey or other gnupg smartcard and do it. Else someone is going to impersonate you and use your name, reputation, and repos to spread malware like this. Have your git hosting provider refuse unsigned commits (github/gitlab allow this).

Secondly stop trusting pip/pypi. You -can- upload gpg package signatures but clients totally ignore them. There is no way to verify the author of a pip package except by hand today.

Let me be really clear here. When you install a pip package you are executing arbitrary code from the internet with unknown authorship.

Pip is fundamentally broken until signature validation is implemented. Whenever possible use OS package managers like apt which actually verify authorship and integrity.

I only sign git tags and releases. I don't sign git commits, because it's supper annoying, especially when rebasing large number of commits.

Package signing and verification works for distros, because significant effort is spent on curating keyrings of trusted keys. (And even that isn't foolproof! See https://bugs.debian.org/842939 for the latest example.)

It's not clear how automatic signature verification could work for pip. Who's going to decide which keys are trusted?

That is such a dick move. There should be a blacklist of people that pull these kinds of stunts. I understand that blacklists aren't Sybil resistant but they're better than nothing. At the very least the scum would have to rebuild their reputation.

It's very easy to change identities online. That's why throwaway accounts are a thing... If you start trying to ban based on IP, then you're in the cat/mouse game that IRC folks have been fighting for decades.

You can solve this though a few user interaction metrics. I'm not active on hacker news thus I don't have privileges (karma) to down vote. A brand new account shouldn't be allowed to make a change such as this, getting enough reputation should require active involvement and code review of changes before they are accepted. Just as my karma can drop, people should lose privileges. That this is sensitive piece having high security requirements means that bar can be even higher requiring years of involvement before unverified commits can occur.

Why not a whitelist of users who can make changes to code flagged as security sensitive (or more specifically: security-authentication)?

Edit: digging through Reddit comments more suggests the repo owner may have been hacked as commit blame shows his user made the changes. In this case: a Blacklist wouldn't help and my suggestion may already be in place.

It doesn't matter if it's "security sensitive" or not. Any compromised package can steal your secrets.

Maintainer's response:

https://webcache.googleusercontent.com/search?q=cache:vjUIkP...

https://github.com/pypa/warehouse/issues/3896#issuecomment-3...

It seems there's no way to be 100% certain whether the maintainer (urigoren) is a victim or the perpetrator in this case.

The module starts with "import requests" which should be a red flag even for a cause skim of the source. The "it's open source, I'm sure someone else read over it" excuse only works when the code is popular enough... and some obscure pip package definitely isn't.

The author of the package claims to be a "victim" here, but it's hard to tell. Too bad pip doesn't support package signing.

Two questions:

1) can paramiko.RSAKey handle other encryption schemes (ED25519) ? If not, folks using non-RSA keys wouldn't be affected..

2) Having a (strong) passphrase for your key file would help prevent the perp from doing any harm with the key(s), or at the very least would give you time to invalidate the key(s). Right?

Reply on news.ycombinator.com