Live data from Hacker News

Dozens of malicious PyPI packages discovered targeting developers

blog.phylum.io

71–80 of 334 posts

Re: Dozens of malicious PyPI packages discovered targeting developers

#71
post #33

can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons .

I think the issue isn't so much malicious authors, it's compromised repositories and compromised repositories as dependencies.

Blue check would gatekeep a lot of noble, new developers.

Re: Dozens of malicious PyPI packages discovered targeting developers

#72
post #58
post #15

Earlier quoted context omitted.

I think this has more to due with the contexts/industries we typically see Python used in over pure popularity. If popularity was the only factor I'd expect to seeing a lot more news about these problems in Java/PHP ecosystems which are absolutely massive.

I mean, PHP is pretty much a domain specific language, and we're only about a year out from log4j.

Log4 wasn't malicious.

Re: Dozens of malicious PyPI packages discovered targeting developers

#73

These sorts of things is why D doesn't allow any system calls when running code at compile time, and such code also needs to be pure. Of course, this doesn't protect against compiling malicious code, and then running the code. But at least I try to shut off all attempts at simply compiling the code being a vector.

I've never understood this position. How often do you add a dependency to your project, compile your project, and then never run your project ever? I can't think of a single case where this would have protected me.

CI/CD servers, dev laptops etc could have more privileges than the production machines. For instance.

Re: Dozens of malicious PyPI packages discovered targeting developers

#74

These sorts of things is why D doesn't allow any system calls when running code at compile time, and such code also needs to be pure. Of course, this doesn't protect against compiling malicious code, and then running the code. But at least I try to shut off all attempts at simply compiling the code being a vector.

I've never understood this position. How often do you add a dependency to your project, compile your project, and then never run your project ever? I can't think of a single case where this would have protected me.

It means you don't need to run the compiler in a sandbox. People do not expect the compiler to be susceptible to malware attacks, and I do what I can to live up to that trust.

I haven't heard of anyone creating a malicious source file that would take advantage of a compiler bug to insert malware, but there have been a lot of such attacks on other unsuspecting programs, like those zip bomb files.

Re: Dozens of malicious PyPI packages discovered targeting developers

#75

These sorts of things is why D doesn't allow any system calls when running code at compile time, and such code also needs to be pure. Of course, this doesn't protect against compiling malicious code, and then running the code. But at least I try to shut off all attempts at simply compiling the code being a vector.

I've never understood this position. How often do you add a dependency to your project, compile your project, and then never run your project ever? I can't think of a single case where this would have protected me.

Build servers?

Re: Dozens of malicious PyPI packages discovered targeting developers

#76
post #70

A lot of people in this thread are asking for a reputation/"verified user" solution for this, but really I think just pulling a gazillion dependencies for applications is just all around bad. I actually think having a reputation system would be even worse, because people would see it and assume that reputation is a guarantee of safety. Trust without verification is where issues can become even worse.

Based on my experience with shady plug-ins for e.g. Photoshop back in the late 90s/early 00s, all that a reputation/"verified user" solution is going to achieve is a very lucrative black market of high-reputation/verified user profiles and credentials.

Re: Dozens of malicious PyPI packages discovered targeting developers

#77

In a previous HN discussion on the topic of rogue Python packages, readers had suggested bubblewrap and firejail for sandboxing. They limit the access a script and its packages have to your filesystem and network. I think that's the better approach - just assume all packages are malicious by default. Can't rely on scanners because of the large number of packages and attacks.

That's not going to help much if code from the malicious attacker is still going to end up integrated into the software product being built.

Re: Dozens of malicious PyPI packages discovered targeting developers

#79

These sorts of things is why D doesn't allow any system calls when running code at compile time, and such code also needs to be pure. Of course, this doesn't protect against compiling malicious code, and then running the code. But at least I try to shut off all attempts at simply compiling the code being a vector.

I'm honestly not sure the benefits of executing code during compilation/install outweigh the bad. Most attacks we have seen leverage this as the attack vector.

CTFE (Compile Time Function Execution) is a major feature of D, and has proven to be immensely useful and liked.

Note that CTFE runs as an interpreter, not native. Although there are calls to JIT it, an interpreter makes it pretty difficult to corrupt.

Re: Dozens of malicious PyPI packages discovered targeting developers

#80
post #70

A lot of people in this thread are asking for a reputation/"verified user" solution for this, but really I think just pulling a gazillion dependencies for applications is just all around bad. I actually think having a reputation system would be even worse, because people would see it and assume that reputation is a guarantee of safety. Trust without verification is where issues can become even worse.

[deleted]
Post reply on HN