Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-3177 #1005

Closed
aws-taylor opened this issue Feb 18, 2021 · 5 comments
Closed

CVE-2021-3177 #1005

aws-taylor opened this issue Feb 18, 2021 · 5 comments
Labels

Comments

@aws-taylor
Copy link

Hello ManyLinux team,

Redhat just announced a new security vulnerability detected in python - https://access.redhat.com/security/cve/cve-2021-3177 - that appears to impact the interpreters shipped in the manylinux containers (or at least 2010). Given that manylinux deliberately ships libpython.a, it seems like teams that are using this container to build portable binary python .whl files may be at risk. At this time, python 3.6 and 3.7 appear to be patched, so I think the fix is simply updating the minor version in the Dockerfile. It appears that 3.8 and 3.9 are not yet fixed.

The related issue https://bugs.python.org/issue42938 has a short test to reproduce:

/opt/python/cp35-cp35m/bin/python3 -c 'import sys; from ctypes import *; print(c_double.from_param(1e300));
Segmentation fault

This may also be a good reason to revisit the discussion in #59 with regards to fortifying the python interpreters.

@di
Copy link
Member

di commented Feb 18, 2021

Thanks! 3.8.8rc1 and 3.9.2rc1 will be promoted on Monday March 1st, I think at that point we can bump all the versions in the Dockerfile and release new images.

@mayeut
Copy link
Member

mayeut commented Feb 18, 2021

@di, thanks for reminding the timeline for 3.8 & 3.9

@aws-taylor , thanks for the info

Given that manylinux deliberately ships libpython.a, it seems like teams that are using this container to build portable binary python .whl files may be at risk.

manylinux does not ship libpython.a (c.f. #91 requesting for it to be added). So no, wheels are not affected, only the interpreters are.

@aws-taylor
Copy link
Author

@di, thanks for reminding the timeline for 3.8 & 3.9

@aws-taylor , thanks for the info

Given that manylinux deliberately ships libpython.a, it seems like teams that are using this container to build portable binary python .whl files may be at risk.

manylinux does not ship libpython.a (c.f. #91 requesting for it to be added). So no, wheels are not affected, only the interpreters are.

Great! Thanks for the clarification. I see now that it was being included via some docker volume/-v mounts that I was passing in my local test.

With regards to python 3.5, is it worth trying to figure out how to turn on hardening since it does not appear that cpython is going to patch this issue or punt since python 3.5 will hopefully be dropped soon anyways per #995 ?

@mayeut
Copy link
Member

mayeut commented Feb 19, 2021

xref #1006 which updates cp38/cp39

With regards to python 3.5, I guess nothing will be done for now and it will be dropped soon.

Please bear in mind that manylinux2010 base image (CentOS 6) has reached EOL. This bug is present (although it's mitigated by hardening) and probably other security bugs that will never be fixed.

Rebuilding everything with hardening should probably be possible (although it might or might not be orthogonal with #59)

mayeut added a commit to mayeut/manylinux that referenced this issue Feb 21, 2021
This does not affect the wheels that are produced by end users as proposed in pypa#59 but mitigates potential security issues in the tools used by manylinux images as mentioned in pypa#1005
mayeut added a commit to mayeut/manylinux that referenced this issue Feb 21, 2021
This does not affect the wheels that are produced by end users as proposed in pypa#59 but mitigates potential security issues in the tools used by manylinux images as mentioned in pypa#1005
mayeut added a commit to mayeut/manylinux that referenced this issue Feb 26, 2021
This does not affect the wheels that are produced by end users as proposed in pypa#59 but mitigates potential security issues in the tools used by manylinux images as mentioned in pypa#1005
mayeut added a commit that referenced this issue Feb 27, 2021
* Use hardening for building all tools & libraries

This does not affect the wheels that are produced by end users as proposed in #59 but mitigates potential security issues in the tools used by manylinux images as mentioned in #1005

* Always update system packages in the final step

Since docker cache is used, system packages are not updated when cache is present. Always update them in the final step.
@mayeut
Copy link
Member

mayeut commented Feb 27, 2021

I'll close this one now that:

  • all pythons that can be updated are indeed updated
  • hardening is enabled on all tools built by the manylinux images, including the 3.5 python interpreter.

@mayeut mayeut closed this as completed Feb 27, 2021
@mayeut mayeut added the bug label Feb 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants