LWN: Comments on "Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)"

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

pabs — Tue, 31 Dec 2019 01:40:24 +0000

IIRC ASan is not meant for production use. In 2016 compiling setuid binaries using it could result in local root exploits:

https://www.openwall.com/lists/oss-security/2016/02/17/9

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

HelloWorld — Mon, 30 Dec 2019 23:36:43 +0000

> There are many programmers who would use bounds checking in C if it could be as simple as adding -fbounds-checking to the command line.

Well you pretty much can do that with -fsanitize=address, and yet not many people seem to be doing it.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

dvdeug — Fri, 13 Dec 2019 14:25:32 +0000

Something that you're implying is that Python programmers are more concerned about security than C programmers, who prefer to dodge any responsibility.

> It's just the C implementations don't do that because "enable a user to implement his own memory management" is a C feature.

C implementations don't do bounds checking because C doesn't make it feasible to do that. There are many programmers who would use bounds checking in C if it could be as simple as adding -fbounds-checking to the command line.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

dfsmith — Mon, 09 Dec 2019 22:43:18 +0000

New thing I learned: the term "typesquatting" now incorporates "copy-and-paste-squatting". Good to know!

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

Cyberax — Sun, 08 Dec 2019 21:10:28 +0000

> That was supposed to be the point: There are a lot of way to cause damage via software and focussing on programming language implementations[*] will not necessarily avoid "damage".
Except that C is pretty much THE worst possible language. It allows vulnerabilities that are by far the most severe compared to other languages.

With Java or Python you really have to work hard to allow remote code execution, with C it's just a misplaced bounds check.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

rweikusat2 — Sun, 08 Dec 2019 20:08:49 +0000

>> The notion that it must be safe to use code written in a language with a more restrictive runtime environment than what a typical >> C implementation provide is wrong.
>
> This statement is true but the claim that it denies is a straw man. I don't think reasonable people would postulate that code written > in a language like Python is automatically “safe”.

Not explicitly, obviously. But implied every time this comes up. It's usually claimed that the problem is the programming language *and* *not* certain code written in it.

> the example at hand illustrates that deliberately introducing malicious functionality to an otherwise innocuous software package
> works regardless of the programming language used. IOW, if you want to be secure against this type of attack, “a more restrictive
> runtime environment than what a typical C implementation provides”

That was supposed to be the point: There are a lot of way to cause damage via software and focussing on programming language implementations[*] will not necessarily avoid "damage".

[*] There's actually nothing which would stop a conforming C implementation from doing array bounds checking, at least not theoretically: The C standard leaves the behaviour of out-of-bounds accesses undefined, hence, terminating a program via some signal in case of one would be perfectly acceptable. It's just the C implementations don't do that because "enable a user to implement his own memory management" is a C feature. The obvjous drawback of that is that users have to care more about memory management than when using a more restrictive language (in this respect), which probably isn't worth it on 'current' hardware in a lot of cases.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

anselm — Thu, 05 Dec 2019 21:43:29 +0000

The notion that it must be safe to use code written in a language with a more restrictive runtime environment than what a typical C implementation provide is wrong.

This statement is true but the claim that it denies is a straw man. I don't think reasonable people would postulate that code written in a language like Python is automatically “safe”. It may avoid some of the more obvious traps and pitfalls of languages like C, but if anything, the example at hand illustrates that deliberately introducing malicious functionality to an otherwise innocuous software package works regardless of the programming language used. IOW, if you want to be secure against this type of attack, “a more restrictive runtime environment than what a typical C implementation provides” by itself isn't going to be sufficient, but we don't see anyone arguing that it is.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

Cyberax — Thu, 05 Dec 2019 18:42:06 +0000

So far C's track record has been abysmal - all large codebases have had multiple memory unsafety vulns.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

kushal — Thu, 05 Dec 2019 18:37:14 +0000

My talk in this year's PyCon US was related to this kind of attacks and mitigation, the things we do in SecureDrop project.

https://www.youtube.com/watch?v=wRHi8Ui5vWA

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

rweikusat2 — Thu, 05 Dec 2019 17:33:48 +0000

It is possible to write "C code without security issues" and there's also no confusion here: The notion that it must be safe to use code written in a language with a more restrictive runtime environment than what a typical C implementation provide is wrong. Even when code wasn't deliberately written to harm its users, the same bad habits (such a "lack of input validation") will cause different kinds of security problems, eg, SQL injection.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

micka — Thu, 05 Dec 2019 16:58:05 +0000

There's a small logical confusion here.
"It's not possible to write C code with no security issue" is not the same as "only C code has security issues".

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

rweikusat2 — Thu, 05 Dec 2019 15:57:59 +0000

Considering that this code wasn't written in C, it's clearly impossible for it to cause any "security issues".

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

smurf — Thu, 05 Dec 2019 08:00:41 +0000

There are a few lists of similar-looking glyphs out there. A simple-but-effective canonicalization algorithm could just use them (plus Unicode normalization: throw away all spaces and zero-width parts) to map all package names.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

marcH — Thu, 05 Dec 2019 05:04:01 +0000

> I know some people like to complain about vendoring and static linking around here

4 days old: https://lwn.net/Articles/805840/

> "vendoring" which is the newfangled way to say "compiling statically".

Newfangled "vendoring" means hard coding the version of a possibly forked dependency. Linking statically is the obvious way to do it but it's not required. It doesn't even need to involve a copy.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

cpitrat — Wed, 04 Dec 2019 21:26:56 +0000

Vendoring is irrelevant to this problem. The best illustration of that being this news being about Python and PIP where vendoring is not used.

I know some people like to complain about vendoring and static linking around here but please try to keep it for when it's actually on-topic ...

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

hkario — Wed, 04 Dec 2019 19:42:19 +0000

for go and rust the go-to way of solving dependencies is "vendoring" which is the newfangled way to say "compiling statically". So there's not much even distributions can do about.

But I guess if one doesn't break API in every release, it means the code is not moving fast enough... /s

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

JoeBuck — Wed, 04 Dec 2019 19:33:24 +0000

If I understand correctly, jellyfish is trying to solve a different problem than typosquatting: identifying strings that sound the same, not strings that look the same. Is there any free code that tries to solve the latter problem? The idea would be that a repo would refuse to register a new project if its name is too close in appearance to an existing project.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

mageta — Wed, 04 Dec 2019 18:57:58 +0000

Well, why would it only happen to npm and rubygems... I am surprised it only happens on such a scarce pace, the effort necessary doesn't seem terribly high.

This seems to be an ambivalent thing about development models like npm, gems, or pypi. For one its good practice to reuse functionality instead of reinventing the wheel all the time, and doing all the mistakes again; on the other side the current class of package manager doesn't do a good job at preventing this sort of thing, and I admit it's not clear to me how they could, without adding a kind of government like in app-stores or such.
The current Linux-distribution model is probably a good filter, or has been so far, but it seems they also struggle with these new language-environments, and the pace at which components turn over. Python maybe less so, but definitely javascript, go, or rust.

Two malicious Python libraries caught stealing SSH and GPG keys (ZDNet)

bangert — Wed, 04 Dec 2019 14:19:09 +0000

Jellyfish "a python library for doing approximate and phonetic matching of strings" becomes a victim of typosquatting.
Oh irony...