We got following CVS:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18348
An issue was discovered in urllib2 in Python 2.x through 2.7.17 and urllib in Python 3.x through 3.8.0. CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument to urllib.request.urlopen with \r\n (specifically in the host component of a URL) followed by an HTTP header. This is similar to the CVE-2019-9740 query string issue and the CVE-2019-9947 path string issue. (This is not exploitable when glibc has CVE-2016-10739 fixed.)
Our docker file is based on python:3.7.5-alpine
We are using eventlet==0.25.0, which depends on the urlib.
How could we fix this Vulnerability?
https://security-tracker.debian.org/tracker/CVE-2019-18348
Issue only exploitable if CVE-2016-10739 is unfixed in src:glibc. This is
not the case in all suites, but the issue is minor in general and would
tend to a no-dsa/ignored tag in those suites.
https://security-tracker.debian.org/tracker/CVE-2016-10739
Fixed in Buster
Since python:3.7.5-slim-buster isn't vulnerable you could use that until it gets fixed in Alpine
The size difference isn't too bad
$ docker images | grep 3.7.5
python 3.7.5-alpine b11d2a09763f 3 weeks ago 98.8MB
python 3.7.5-slim-buster 46cf279fff55 3 weeks ago 179MB
@wglambert When it will get fixed in Alpine? Is there any plan?
First, all of the images here use python built from upstream source, so unfortunately the Debian link for "https://security-tracker.debian.org/tracker/CVE-2019-18348" does not apply, but can help give us clues. The Debian link says that a new enough glibc invalidates the vulnerability, so that it good news for the buster images and @wglambert is correct for those. As for Alpine based images, they don't use glibc but instead musl libc, so we can't rule out the vulnerability (it is possible that it isn't even vulnerable because it is using musl libc).
The bug report on python, https://bugs.python.org/issue38576, doesn't point to any specific releases of python that fix the issue (or even any patches). My guess is that we'll have to wait for the next python release.
Going to close since there's nothing actionable for us to do. Any upstream changes will get propogated into the latest Dockerfiles anyway
Most helpful comment
First, all of the images here use python built from upstream source, so unfortunately the Debian link for "https://security-tracker.debian.org/tracker/CVE-2019-18348" does not apply, but can help give us clues. The Debian link says that a new enough
glibcinvalidates the vulnerability, so that it good news for the buster images and @wglambert is correct for those. As for Alpine based images, they don't use glibc but instead musl libc, so we can't rule out the vulnerability (it is possible that it isn't even vulnerable because it is using musl libc).The bug report on python, https://bugs.python.org/issue38576, doesn't point to any specific releases of python that fix the issue (or even any patches). My guess is that we'll have to wait for the next python release.