4

I am a long-time linux sysadmin, but new to CentOS. I just need to determine if this CentOS server is vulnerable to CVE-2019-18348. To do that, I have to either verify the packages installed are patched, or have a way to test for the vulnerability on the machine.

I have not found any reliable way to test for the vulnerability, so I am left looking at package versions, changelogs, etc.

First, some details about the vulnerability:

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

https://nvd.nist.gov/vuln/detail/CVE-2019-18348

https://nvd.nist.gov/vuln/detail/CVE-2016-10739

Here are version details of my system:

  • centos-release-8.0-0.1905.0.9.el8.x86_64
  • python36.x86_64 (3.6.8-2.module_el8.0.0+33+0a10c0e1)
  • glibc 2.28-42.el8.1

The system is fully updated, but I don't see any security or backports repo enabled. I haven't been able to find any information on whether there is a security updates repo for centos and how to enable that.

[root@host]# yum repolist
Last metadata expiration check: 1:37:46 ago on Fri 06 Dec 2019 07:51:08 PM UTC.
repo id     repo name                                       status
AppStream   CentOS-8 - AppStream                            5,089
BaseOS      CentOS-8 - Base                                 2,843
*epel       Extra Packages for Enterprise Linux 8 - x86_64  3,579
extras      CentOS-8 - Extras

The changelog for glibc does not specifically list CVE-2019-18348. Although if may have been fixed in a previous version, but I haven't found any way to check that.

[root@host]# rpm -q --changelog glibc | grep -i cve
- Add upstream test case for CVE-2018-19591 (#1654010)
- CVE-2018-19591: File descriptor leak in if_nametoindex (#1654010)
- CVE-2018-11237: Buffer overflow in __mempcpy_avx512_no_vzeroupper (#1581275)
- CVE-2018-11236: realpath: Fix path length overflow (#1581270, swbz#22786)
- CVE-2017-18269: memory corruption in i386 memmove (#1580934)
- CVE-2017-14062, CVE-2016-6261, CVE-2016-6263:
- CVE-2018-1000001: Make getcwd fail if it cannot obtain an absolute path
- CVE-2017-16997: elf: Check for empty tokens before DST expansion (#1526866)
- CVE-2017-1000409: Count in expanded path in _dl_init_path (#1524867)
- CVE-2017-1000408: Compute correct array size in _dl_init_paths (#1524867)
- CVE-2017-17426: malloc: Fix integer overflow in tcache (swbz#22375)
- CVE-2017-15804: glob: Fix buffer overflow during GLOB_TILDE unescaping
- CVE-2017-15670: glob: Fix one-byte overflow (#1504807)
- Use execveat syscall in fexecve (swbz#22134)

The changlog for python doesn't show any CVE's, but "rhbz" numbers, which I assume are redhat bugzilla. I have a few subscriptions with RH but apparently not enough to be allowed to view any details for these items.

[root@host]# rpm -q --changelog python36 | grep -i resolves
- Resolves: rhbz#1695587
- Resolves: rhbz#1658271
- Resolves: rhbz#1654867
- Resolves: rhbz#1633534
- Resolves: rhbz#1633534
- Resolves: rhbz#1633561
- Resolves: rhbz#1633534
- Resolves: rhbz#1632637
- Resolves: rhbz#1633534
- Resolves: rhbz#1615727

This Red Had advisory fixes CVE-2016-10739 in package glibc-2.28-72.el8.x86_64.rpm https://access.redhat.com/errata/RHSA-2019:3513

But since this machine is centos and on version 2.28-42.el8.1, and the patch versions between RH and CentOS seem to be different, that doesn't seem to help me determine whether this box is vulnerable.

If anyone can offer insight as to whether this system is vulnerable, or point me in the right direction, I would really appreciate it.

Thanks

user1522091
  • 79
  • 1
  • 5

2 Answers2

5

You are on the right track following the Red Hat Service Advisory. The same package that resolves CVE/RHSA upstream will be released for CentOS. Sometimes it is not available as quickly. There is a build for glibc-2.28-72.el8.x86_64.rpm for CentOS 8, but it doesn't look like it's made it into the repositories yet.

https://koji.mbox.centos.org/koji/buildinfo?buildID=4751

It doesn't help you when the repository metadata isn't aware of a CVE, yet. But, you may want to get familiar with security options to dnf if you'll be running CentOS systems.

DNF(8)                                                                           DNF                                                                           DNF(8)

NAME
       dnf - DNF Command Reference

...
       --cve=<cves>
              Includes  packages  that  fix a CVE (Common Vulnerabilities and Exposures) ID (http://cve.mitre.org/about/), Eg. CVE-2201-0123. Applicable for install,
              repoquery, updateinfo, and upgrade command.
...
       --security
              Includes packages that provides a fix for security issue. Applicable for upgrade command.

Ex:

dnf updateinfo list --cve=CVE-2016-10739
Aaron Copley
  • 12,345
  • 5
  • 46
  • 67
0

Using the below syntax if the CVE info appears then your system is vulnerable; if no output you are compliant.

yum updateinfo info --cve CVE-2019-18348
user35042
  • 2,601
  • 10
  • 32
  • 57
Reda Salih
  • 231
  • 2
  • 7
  • 1
    It is important to note that this only works if there is already errata published for the CVE. The metadata is not yet aware of the CVE, so it will return nothing. – Aaron Copley Dec 07 '19 at 03:28