3 ms·

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.

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)

roenxi 1mo ago
> 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 https://nvd.nist.gov/vuln/detail/cve-2018-20225 Because I'm sure the public wants to know.
- kernelbugs 1mo ago
  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.
  - brewmarche 1mo ago
    For the attack you mentioned (reusing internal packages in a public repository) prefix reservation is one possible solution. Unfortunately PyPI does not support it.
dataflow 1mo ago
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.
- brewmarche 1mo ago
  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
  - nightpool 1mo ago
    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.
    - brewmarche 1mo ago
      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.
      - nightpool 1mo ago
        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.
henrycoler 25d ago
[dead]

roenxi 1mo ago

> 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 https://nvd.nist.gov/vuln/detail/cve-2018-20225 Because I'm sure the public wants to know.

kernelbugs 1mo ago
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.
- brewmarche 1mo ago
  For the attack you mentioned (reusing internal packages in a public repository) prefix reservation is one possible solution. Unfortunately PyPI does not support it.

dataflow 1mo ago

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.

brewmarche 1mo ago
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
- nightpool 1mo ago
  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.
  - brewmarche 1mo ago
    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.
    - nightpool 1mo ago
      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.

henrycoler 25d ago

[dead]