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)
- 6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
- 4.4 GA in 16.04, HWE in 14.04
- Mentioned some of these last week in [USN-6285-1] Linux kernel (OEM) vulnerabilities
- deadlocks in device mapper and DVB Core drivers; UAFs in HFS+ file-system
impl, virtual terminal drivers and netfilter network packet classifier; OOB
write in QFS network scheduler
- DoS via CPU deadlock or crash; possible code execution for the UAFs / OOB
write
[USN-6311-1] Linux kernel vulnerabilities (06:07)
- 24 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
- 5.15 kernel variants for GCP and GKE
[USN-6312-1] Linux kernel vulnerabilities (06:22)
- 16 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS)
- 5.4 for GKE on 20.04 and IBM on 18.04
[USN-6314-1] Linux kernel vulnerabilities (06:33)
- 16 CVEs addressed in Focal (20.04 LTS)
- 5.4 for IBM and BlueField (NVIDIA DPU family using ARM CPU cores from Mellanox
(now owned by NVIDIA))
[USN-6315-1] Linux kernel vulnerabilities (06:58)
- 11 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
- 5.15 GA (GKE, NVIDIA, IBM, GCP, KVM, Oracle, AWS, LowLatency) for 22.04 and
HWE for 20.04 + some OEM specific kernels too
- Zenbleed ([USN-6244-1] AMD Microcode vulnerability from Episode 204) and
Gather Data Sampling ([USN-6286-1] Intel Microcode vulnerabilities from
Episode 205)
- Previously released microcode updates, now also shipping associated kernel
fixes - for Zenbleed this enables a workaround if the microcode is not
available (since for some CPUs this is only available as a BIOS update, not
via microcode in Ubuntu), whilst for GDS this simply provides kernel support
to help identify if the mitigation is in place or not - if no microcode is
available, can disable AVX entirely by setting
clearcpuid=avx
on the kernel
command-line (but this will have a decent performance impact)
[USN-6316-1] Linux kernel (OEM) vulnerabilities (09:02)
- 6 CVEs addressed in Jammy (22.04 LTS)
- 6.1 OEM on 22.04
[USN-6317-1] Linux kernel vulnerabilities (09:10)
- 5 CVEs addressed in Bionic ESM (18.04 ESM), Focal (20.04 LTS)
- 5.4 GA for 20.04 / HWE for 18.04
[USN-6318-1] Linux kernel vulnerabilities (09:20)
- 10 CVEs addressed in Jammy (22.04 LTS), Lunar (23.04)
- 6.2 23.04 GA, HWE for 22.04
[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)
- 8 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS)
- audio decoding library
- various heap and stack buffer overflows plus a NULL ptr deref for good measure
[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)
- 11 CVEs addressed in Focal (20.04 LTS)
- 117.0
[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