Overview
A gnarly old bug in NSS is unearthed, plus we cover security updates for
ICU, the Linux kernel and ImageMagick as well.
This week in Ubuntu Security Updates
20 unique CVEs addressed
[USN-5156-1] ICU vulnerability [00:40]
- 1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)
- Double free - originally reported in chromium but is actually in embedded
copy of icu - able to be triggered on crafted content to icu, in the case
of chromium this could be via a crafted webpage or similar so not too
dissimilar to usual web handling issues - memory corruption -> code
execution (but within chromium sandbox in that case)
[USN-5158-1] ImageMagick vulnerabilities [01:25]
- 5 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
- DoS vulns from untrusted inputs -> most all result in a divide by zero ->
exception -> application crash
[USN-5161-1] Linux kernel vulnerabilities [01:55]
- 4 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)
- 5.11 kernel (generic hirsute + clouds, raspi, focal hwe etc)
- armhf specific issue (Aspeed LPC bus controller) - local user OOB write
-> crash / code-exec
- AMD cryptographic coprocessor driver memory leaks -> DoS (Episode 138)
- SCTP OOB read - incoming packets
[USN-5162-1] Linux kernel vulnerabilities [03:13]
- 5 CVEs addressed in Focal (20.04 LTS), Impish (21.10)
- 5.13 (impish, focal OEM)
- same as above plus SELinux specific issue around handling of task
credentials -> UAF -> memory corruption -> crash / code execution (Jann
Horn @ GPZ)
[USN-5163-1] Linux kernel vulnerabilities [03:59]
- 4 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
- 5.4 (focal, bionic HWE)
- AMD cryptographic coprocessor driver memory leaks -> DoS (Episode 138)
- SCTP OOB read - incoming packets
- USB Option High Speed Mobile driver -> UAF if unplug device before fully
registered - local attacker could trigger - crash / code-exec
[USN-5164-1] Linux kernel vulnerabilities [04:50]
- 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)
- 4.15 (bionic, xenial ESM, trusty ESM - azure)
- AMD cryptographic coprocessor driver memory leaks -> DoS (Episode 138)
- SCTP OOB read - incoming packets
[USN-5165-1] Linux kernel (OEM) vulnerabilities [05:13]
- 7 CVEs addressed in Focal (20.04 LTS)
- Mix of vulns in various drivers
- UAF in NFC, DoS due to SCTP logic error, OOB in AMD GPU debugfs (need
root), FireDTV Firewire OOB write, POWER8 specific KVM issue (guest ->
host crash), Transparent Inter-Process Communication (TIPC) OOB write,
ISDN CAPI subsystem OOB write
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04), Impish (21.10)
New NSS vulnerability (CVE-2021-43527) discussion [06:17]
- Discovered by Tavis Ormandy at GPZ
- NSS is a very old project, code in question has existed since 2003 and
been exploitable since at least 2012 when it was refactored
- Does a direct memcpy of an attacker controlled amount of data into a
fixed size buffer without specifically checking whether the data is too
large - classic heap-based buffer overflow
- Object on the heap also contains function pointer which then get called
so relatively easy to get control flow and code execution as a result
- NSS was one of the first projects added to oss-fuzz (Google), Mozilla do
own fuzzing as well, extensive testsuite and uses ASAN for internal
builds
- Uses Coverity but this didn’t detect it either
- Existing fuzzing and unit tests had test cases which could reach this
code but failed to find it for a number of reasons:
- Fuzz input is limited to 10k - but to overflow need at least 16,384
bytes so fuzzing couldn’t have caught this
- Individual code paths fuzzed but not so much end-to-end systematic
testing - so nothing which would try generating say large inputs in
this case - does occur for other code-paths though
- Existing metrics almalgate results from all fuzzers - so hard to tell
how well a piece of code has been fuzzed as it may have been using a
fuzzed which may never trigger relevant input to find bugs like this
- Seemingly well tested, well fuzzed code is not enough - need to look
systematically and quantify how complete the coverage is not just in
terms of LOC or inputs used, but also boundary conditions etc
- https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html
Get in contact