Episode 140
A gnarly old bug in NSS is unearthed, plus we cover security updates for ICU, the Linux kernel and ImageMagick as well.
Ubuntu Security Podcast · Ubuntu Security Team
December 3, 202112m 39s
Audio is streamed directly from the publisher (people.canonical.com) as published in their RSS feed. Play Podcasts does not host this file. Rights-holders can request removal through the copyright & takedown page.
Show Notes
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
[USN-5168-1, USN-5168-2, USN-5168-3] NSS and Thunderbird vulnerability [06:08]
- 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