Elixir recently added hex diff, which I've found quite useful. E.g.: https://diff.hex.pm/diff/jiffy/1.0.7..1.0.8
Malicious PyPI packages stealing credit cards and injecting code
141–150 of 230 posts
Re: Malicious PyPI packages stealing credit cards and injecting code
#142I wonder how many Python packages have a justifiable reason for using `eval()` to begin with. I've been writing Python professionally for almost a decade and I've never run into a use case where it has been necessary. It's occasionally useful for debugging, but that's all I've ever legitimately considered it for. It's neat that JFrog can detect evaluation of encoded strings, but I think I'd prefer to just set a stati…
I don't think there's a good reason to have eval in interpreted languages. Sure the REPL uses it but it could be implemented internal to the REPL instead of exposing it in the language.
Re: Malicious PyPI packages stealing credit cards and injecting code
#143This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…
Sorry, I don't quite see how this would protect against supply chain attacks. If an upstream dependency is back-doored, they just have to silently add their code in an otherwise reasonable sounding release, and now you will happily download that version, add it to your internal mirrors, and pin its version forever. Unless you actually read the diff on every update, which I think is impractical (although you're welcom…
I think part of the idea is that if you only use versions that have been released for a little while, you are hoping SOMEONE notices the malicious code before you finally update.
There are a number of issues with this approach, although the practice still might be a net benefit.
One, you are going to be behind on security patches. You have to figure out, are you more at risk from running unpatched code for longer, or from someone compromising an upstream package?
Two, if too many people use this approach, there won't be anyone who is actually looking at the code. Everyone assumes someone else would have looked, so no one looks.
Re: Malicious PyPI packages stealing credit cards and injecting code
#144This is why our build systems don’t use public repositories directly, and why we always pin to an exact version. Any third party dependencies (js/python/java/c/you-name-it) are manually uploaded to our Artifactory server- which itself has no internet access. All third party libraries are periodically checked for new versions, any security announcements etc, and only if we are happy do we update the internal repo. It…
Yes, this is why I implemented hash-checking in pip ( https://pip.pypa.io/en/stable/topics/repeatable-installs/#ha... ). Running your own server is certainly another way to solve the problem (and lets you work offline), but keeping the pinning info in version control gives you a built-in audit trail, code reviews, and one fewer server to maintain.
Doesn't Poetry do this by default in its lockfile too?
Re: Malicious PyPI packages stealing credit cards and injecting code
#145I am surprised this doesn’t happen to NPM all the time
Re: Malicious PyPI packages stealing credit cards and injecting code
#146Earlier quoted context omitted.
Right, but I wouldn't have expected that processes outside of chrome could get at its internally managed db (or encrypted properties), especially if it's using an authenticated (chrome) user profile. Windows doesn't have any application firewalls by default? I thought that was the whole thing that came in with Vista that people were upset about. (Of course, thinking it through, Linux isn't any better, assuming the pr…
I know in Chrome on Windows, I am asked for my Windows login password if I want to view any saved passwords. Really hope that's not just a "UI" feature, and those passwords really are encrypted.
>Really hope that's not just a "UI" feature, and those passwords really are encrypted.
It's definitely a ui feature. If you want to extract the password all you have to do is visit the login page, open the developer console, and type $("input[type=password]").value
Re: Malicious PyPI packages stealing credit cards and injecting code
#147Earlier quoted context omitted.
My read was GP is implying they do read the diff every time, and only change the pinned version after a manual review- "only after we are happy." This does seem impractical at even a modest scale.
What does "modest scale" mean? Some people have to have all dependency updates reviewed and have some level of independent security team monitoring dependency changes. Not everyone has this, but the context is key as some domains have this consistently. Some of this is cultural in addition to being paranoid about security, or having strict compliance requirements. For your average startup, they may not have any time…
> What does "modest scale" mean? Some people have to have all dependency updates reviewed and have some level of independent security team monitoring dependency changes.
Who? Seems totally intractable to me.
Re: Malicious PyPI packages stealing credit cards and injecting code
#148It seems to me like one low hanging fruit to make a lot of these kinds of exploits significantly more difficult is protection at a language level about which libraries are allowed to make outgoing HTTP requests or access the file system. It would be great if I could mark in my requirements.txt that a specific dependency should not be allowed to access the file system or network, and have that transitively apply to ev…
I started building this at one point. Basically there's an accompanying manifest.toml that specifies permissions for the packages with their checksums, and then it can traverse the dependency graph finding each manifest.toml.
It also generated a manifest.lock so if manifests changed you would know about it.
Then once it built up the sandbox it would execute the build. If no dependencies require networking, for example, it gets no networking, etc.
I stopped working on it because I didn't have time, and it obviously relied on everyone doing the work of writing a manifest.toml and using my tool, plus it only supported rust and crates.io
TBH it seems really easy to solve this problem, it's very well worn territory - Browser extensions have been doing the same thing for decades. Similarly, why can I upload a package with a near-0 string distance to another package? That'd help a massive amount against typosquatting.
No one wants to implement it who also implements package managers I guess.
Re: Malicious PyPI packages stealing credit cards and injecting code
#149Earlier quoted context omitted.
I did a bunch of nodejs stuff at my last gig. These teams had the of practice keeping packages up to date. Drove me frikkin nuts. So much churn, chaos. Is this a JavaScript thing? Carried over from frontend development? Exasperated, I finally stopped advocating for locking everything down. Everyone treated me like I was crazy. (Reproducible builds?? Pfft!!) Happens with enterprisey Java, Sprint, Maven projects too. (…
Java/Spring/Maven should have locked down dependencies by default. They have to go out of their way to not do that. Not that some people don't, anyway. Typos: > I stopped advocating for locking everything down. started? > Look down dependencies. lock?
AFAIK Maven and Gradle don't have any built-in way of locking down dependencies (direct or transient), unless I missed something.
Re: Malicious PyPI packages stealing credit cards and injecting code
#150I don't think that it's good to just delete the packages. Same goes for Android Apps in the Google Play Store or for Chrome Extensions.
These compromised packages should have their page set to a read-only mode with downloads/installs disabled, with a big warning that they were compromised.
This is specially troublesome with Chrome Extensions and Android Apps, where it is not possible to get to know if I actually had the extension installed, and if I had, what it was exactly about.
Chrome Extensions getting automatically removed from the browser instead of permanently deactivated with a hint of why they can't be activated again, and which was the reason why the extension got disabled, is a problem for me. How do I know if I had a bad extension installed, if personal data has been leaked?
This also applies to PyPI to some degree.
----
Eventually the downloads should get replaced with a module which, when loaded, prints out a well defined warning message and calls sys.exit() with a return code which is defined as a "vulnerability exception" which a build system can then handle.