Episode 207

Posted on Friday, Sep 1, 2023
This week we cover reports of “fake” CVEs and their impact on the FOSS security ecosystem, plus we look at security updates for PHP, Fast DDS, JOSE for C/C++, the Linux kernel, AMD Microcode and more.

Show Notes

Overview

This week we cover reports of “fake” CVEs and their impact on the FOSS security ecosystem, plus we look at security updates for PHP, Fast DDS, JOSE for C/C++, the Linux kernel, AMD Microcode and more.

This week in Ubuntu Security Updates

83 unique CVEs addressed

[USN-6305-1] PHP vulnerabilities (00:53)

  • 2 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04)
  • One interesting issue in the handling of XML - PHP uses the libxml library for XML handling which maintains global state for things like whether XML external entities should be loaded. However PHP also uses ImageMagick for image handling, which also uses libxml (for say SVG parsing etc). As such, ImageMagick may end up configuring XML EE to be enabled, which then in turn enables it for all of PHP and so allows XML EE attacks - which can then be used to read and disclose the contents of local files.
    • Fixed by making PHPs use of libxml set a local context which explicitly turns off XML EE handling rather than relying on the global context
  • Stack buffer overflow when reading dirents from PHAR archives

[USN-6306-1] Fast DDS vulnerabilities (02:28)

  • 7 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04)
  • C++ implementation of DDS standard - pub-sub model for connecting software components, used in various contexts like Adaptive AUTOSAR in the automotive industry and others
  • DoS via traffic flood - fixed by implementing an exponential backoff for authentication requests
  • various other DoS through different assertion failures, unhandled exceptions and a couple heap buffer overflows for good measure too

[USN-6307-1] JOSE for C/C++ vulnerability (03:33)

  • 1 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
  • C library implementation of Javascript Object Signing and Encryption (JOSE) standard
  • AES/GCM decryption would used the tag length value from the Authentication Tag provided in the JWE header rather than the fixed length of 16 as specified. Attacker could then provide a crafted JWE header with a shorter authentication tag to trigger a buffer overflow on the receiver -> crash -> DoS / info leak

[USN-6308-1] Libqb vulnerability (04:25)

  • 1 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04)
  • tooling for generating man pages from Doxygen XML files
  • heap buffer overflow via an overly long input line when outputting certain log messages

[USN-6309-1] Linux kernel vulnerabilities (04:48)

[USN-6311-1] Linux kernel vulnerabilities (06:07)

[USN-6312-1] Linux kernel vulnerabilities (06:22)

[USN-6314-1] Linux kernel vulnerabilities (06:33)

[USN-6315-1] Linux kernel vulnerabilities (06:58)

[USN-6316-1] Linux kernel (OEM) vulnerabilities (09:02)

[USN-6317-1] Linux kernel vulnerabilities (09:10)

[USN-6318-1] Linux kernel vulnerabilities (09:20)

[USN-6310-1] json-c vulnerability (09:41)

  • 1 CVEs addressed in Jammy (22.04 LTS)
  • stack buffer overread on crafted input - interestingly the CVE says that it can allow code execution but that is the first time I have heard an OOB read can allow code execution

[USN-6313-1] FAAD2 vulnerabilities (10:08)

[USN-6319-1] AMD Microcode vulnerability (10:33)

  • 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04)
  • “INCEPTION” / “RAS Poisoning” - similar to the original SpectreV2 vulns - another variant of a speculative execution attack using the branch prediction buffer to cause an incorrectly speculated return to be executed which can then be inferred from a cache timing attack to read kernel memory

[USN-6320-1] Firefox vulnerabilities (11:13)

[USN-6263-2] OpenJDK regression (11:24)

Goings on in Ubuntu Security Community

Reports of “Fake” CVEs being assigned by MITRE (12:07)

  • https://riskybiznews.substack.com/p/open-source-projects-plagued-by-fake-cves
  • Dan Lorenc from Chainguard posted about a heap of CVEs assigned just over 1 week ago (22nd August 2023) against a heap of open source projects - cURL, PostgreSQL, Python, nasm, ImageMagick and a heap more
  • Each refers to either a bug report or patch sent to the upstream project that mentions a fix for seemingly real vulnerability (“buffer overflow”, “use after free” etc)
  • But for most of these, the upstream project never agreed that these were valid vulnerabilities, and some have come out to expressly disavow them - PostgreSQL on CVE-2020-21469 and cURL on CVE-2020-19909
    • PostgreSQL issue is a DoS via sending a repeated SIGHUP to the server
      • BUT you need to have local access with priviliges to send SIGHUP - ie be root - and have access to the PostgreSQL superuser etc
      • which if you do, you can do a lot more damage - ie. this is not a vulnerability - there is no privilege boundary being crossed etc
    • cURL is an integer overflow in the --retry-delay command-line option - where if you specify a really large value of seconds, cURL will multiply this by 1000 to convert it to ms and hence overflow
      • BUT this is not used for memory calculations etc - is just used for a retry delay - ie. it will only wait for say a few seconds rather than the billion odd seconds originally specified - again, there is no security impact here
  • Dan posited that these were likely just scraped automatically and CVEs filed
  • But who filed the CVEs?
    • all show as assigned by MITRE - and anyone can request a CVE from MITRE as they are the CNA of last resort - https://cveform.mitre.org/
    • BUT like all CNAs, they should be checking validating the information before assigning a CVE
    • MITRE even rejected the request by Daniel Stenberg (@bagder) (cURL maintainer) to reject the CVE
    • clearly something is breaking down here
  • Not only does this create a heap of work for the upstream projects (as mentioned by Risky Biz) but for all the downstreams like Ubuntu and other distros
    • We have to triage these CVEs against the packages in Ubuntu and determine whether the require immediate fixing etc - this takes time for everyone involved
  • RiskyBiz calls these “Fake” CVEs - but they are not fake in the traditional sense - ie. they are not fradualent, they have been issued by the official custodians of CVEs - MITRE - but it is just that they are not actual vulnerabilities
  • Is this just taking the Linux kernel mantra of security problems are just bugs (and hence to get kernel security fixes you need to get all kernel bug fixes as you won’t know which are the real vulns) to the opposite extreme - all bugs are security bugs and hence should get CVEs?
  • Will have to wait and see how this plays out but if consumers can’t trust CVEs that will likely put the whole system in jeopardy since whilst CVEs have many shortcomings, they are the global defacto for vulnerability tracking

Get in contact