Mitigation

[jayfk]

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?

[akoumjian]

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.

[jayfk]

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

[akoumjian]

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.

[jayfk]

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.

[akoumjian]

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.

[akoumjian]

Looks like it's even easier in npm land. Just have to write the patched version of audit now.

[akoumjian]

I will credit you on the npm version and add you to the github proof of concept by the end of tonight. Very close.

[jayfk]

Awesome, good luck!

[Jwomers]

Incredible, thanks @akoumjian for raising this and working on getting to a solve 🙏

[jayfk]

Started working on this. Are you going to apply for a CVE for this?

[akoumjian]

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 .

[jayfk]

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.

[jayfk]

Going forward, we are going to:

• [ ] release Safety as a binary

In order to upgrade users to the binary release, I suggest to:

• [ ] publish one last Safety release as pip installable package. The package displays a red warning banner with a note to switch to the binary release. It exits abnormally, breaking CI tests for fresh installations.
• [ ] add Safety <=1.8.1 to both the commercial and open vulnerability database. This breaks CI tests for old installations.

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?

[akoumjian]

I think that is a commendable path forward and the appropriate path to take. I will move forward with the CVE process.

[jayfk]

While you are on it, pipenv should be vulnerable, too: https://github.com/pypa/pipenv

[Jwomers]

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 .

[akoumjian]

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.

[akoumjian]

@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.

[jayfk]

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.

[jayfk]

CVE ID for this issue is CVE-2020-5252.