Open jayfk opened 4 years ago
I wish I did. If it was shipped as a standalone binary with its own runtime, I think that would work but you would have to update the tool to scan the filesystem instead of scanning packages in the python package namespace.
Exactly. Even calling pip freeze
under the hood wouldn't work since this could be patched too.
I'll have to talk to the people in charge of the project on which path to pursue, I'll get back to you on this as soon as I know more.
BTW: I suspect the npm cli is vulnerable too, take a look at npm audit
: https://docs.npmjs.com/cli/audit
They are at hackerone but I don't know if npm itself is a eligible package: https://hackerone.com/nodejs-ecosystem
I'll take a look at how nodejs does module loading. I'm not sure if there's an equivalent to the .pth
load time execution that lets you run arbitrary code at interpreter start.
Is the .pth
load time execution even necessary? setup.py
runs at install time, which lets you run arbitrary code. I don't know, how nodejs handles this though.
The new whl
binary format doesn't allow for arbitrary code execution at install time. It has a predefined mapping of options that it executes. So you're correct, that a traditional python source package (or source wheel) would allow you to place something like a .pth
or to replace the reference to the python
binary or something like that.
Looks like it's even easier in npm
land. Just have to write the patched version of audit now.
I will credit you on the npm
version and add you to the github proof of concept by the end of tonight. Very close.
Awesome, good luck!
Incredible, thanks @akoumjian for raising this and working on getting to a solve 🙏
Started working on this. Are you going to apply for a CVE for this?
I will, I was going to wait until you had a chance to mitigate. I am also waiting to hear back from npmjs folks.
On Tue, Mar 3, 2020 at 16:16 Jannis Gebauer notifications@github.com wrote:
Started working on this. Are you going to apply for a CVE for this?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/akoumjian/python-safety-vuln/issues/1?email_source=notifications&email_token=AAFTGJBXXVVKJKD6X3RPDADRFVXURA5CNFSM4K5XGYG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENVF2ZI#issuecomment-594173285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFTGJBXCICEGSQARXTH4WLRFVXURANCNFSM4K5XGYGQ .
You should be able to requests a CVE ID without actually publishing it. Once we have the CVE ID, I can update our patch and the corresponding docs accordingly. Once we are ready, we publish a new Safety release followed by making the CVE public.
Going forward, we are going to:
In order to upgrade users to the binary release, I suggest to:
This provides a clear upgrade path for our users. One might argue that these steps are a bit drastic but I think that users for tools like Safety are not willing to accept shortcuts when it comes to security.
What do you think?
I think that is a commendable path forward and the appropriate path to take. I will move forward with the CVE process.
While you are on it, pipenv
should be vulnerable, too: https://github.com/pypa/pipenv
Great next steps 💯
On Tue, 3 Mar 2020 at 14:43, Jannis Gebauer notifications@github.com wrote:
While you are on it, pipenv should be vulnerable, too: https://github.com/pypa/pipenv
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/akoumjian/python-safety-vuln/issues/1?email_source=notifications&email_token=AAAV6QVJSEHEFT4QX3AQNRDRFWBXTA5CNFSM4K5XGYG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENVOVYY#issuecomment-594209507, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAV6QT2QVH3QRRJXB52L5DRFWBXTANCNFSM4K5XGYGQ .
While you are on it,
pipenv
should be vulnerable, too: https://github.com/pypa/pipenv
I'll include it in the security advisory. Looks like Github will function as the CNA for all parties.
@jayfk Not sure if you saw the email thread, but it looks like you will have to request the CVE. The first step is to add a security.md
to the safety
repository, not sure about the steps from there.
Yes, I just requested the CVE. GitHubs ID is GHSA-7q25-qrjw-6fg2
.
The page states that there's a waiting time of approx 72 hours. I'll update this thread once I know more.
CVE ID for this issue is CVE-2020-5252
.
Hey!
Thanks for reporting!
This is going to be exceptionally hard to fix. Running the tool on a infected system is unsafe, even if we ship the tool as a binary. This would make it harder for someone to patch it but it won't be impossible.
Any ideas other than to update the docs to never run the tool on a system where third party packages are installed?