Hacker News Reader

Comment by brewmarche | Hacker News Reader

Yes, I’ve also experienced this kind of attitude. Some scanning tools can detect that certain CVEs do not apply because the specific functionality is not used.

I hope your team was OK with you uninstalling the VMware package manually (this is actually not a bad outcome if you don’t use that package)

There are also ridiculous CVEs like CVE-2018-20225 for pip, which will not get fixed as that behaviour is by design (but here as well it might be a good idea to strip pip if it’s not used)

View on HN

> An issue was discovered in pip (all versions) because it installs the version with the highest version number, even if the user had intended to obtain a private package from a private index.

https://nvd.nist.gov/vuln/detail/cve-2018-20225

Because I'm sure the public wants to know.

To be fair this behavior + extra-index-url definitely allowed for dependency confusion attacks. Now it's a bit silly for the CVE as written, but IIRC this was before you could use index-url to point exclusively to an internal package host so there were (and in other ecosystems still are) dependency confusion attacks going on in the wild where attackers are publishing "internal-package-a@999.9.9" on any public package host (NPM, PyPi, etc) to try to compromise companies that have internal packages of the same name.

For the attack you mentioned (reusing internal packages in a public repository) prefix reservation is one possible solution. Unfortunately PyPI does not support it.

I don't understand what's ridiculous about that pip CVE, could you explain? Just because something is by design that doesn't mean it's not a vulnerability or somehow unexploitable.

Maybe I was too harsh. It’s the CVE in conjunction with its high severity, the maintainers’ decision and the bundling of pip with CPython. In the end what can you do about it as a dev given that the pip maintainers have decided not to fix it? The only option is not to use pip at all (and sure, you can see the CVE as a critique of pip in a way), or discuss with your security team in hope for some exclusion. And since pip or at least ensurepip are part of Python you get a lot of these scan results

E: and if you decide not to use pip I don’t think there’s an official way to remove ensurepip, I typically rm -rf inside of site-packages, it works but doesn’t feel correct

The CVE looks relevant to me. If you're trying to get a package from a private repo, and someone publishes version 999 of that package on a public repo, then you're executing their code instead of your own. Just because the pip maintainers refuse to fix it doesn't mean it isn't a security vulnerability that could lead to remote code execution and needs to be controlled for in some other way.

One could argue that this is not an issue with pip, the software, but of the index used. I mean, if you control both index and extra-index there is no problem (and one solution to this is to use your own mirror with a set resolution order). This could very well be addressed in PyPI, for example NuGet allows to reserve package prefixes.

We also do not create a CVE for curl because you can use it to download the wrong bash script. If this was an alert for suspicious usages of pip instead of pip itself, I’d be less critical of it.

One could argue that, certainly, but I think it's a little disingenuous. Pip makes it impossible to use extra-index-url safely, in the ~only use-case that option has. There is no world where you use extra-index-url and you're not vulnerable in some way or another to dependency confusion.

Reply on news.ycombinator.com