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
[USN-5156-1] ICU vulnerability [00:40]
1 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)CVE-2021-30535 Double free - originally reported in chromium but is actually in embeddedcopy 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)CVE-2021-20313 CVE-2021-20312 CVE-2021-20309 CVE-2021-20246 CVE-2021-20244 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)CVE-2021-42252 CVE-2021-3764 CVE-2021-3744 CVE-2021-3655 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)CVE-2021-43057 CVE-2021-42252 CVE-2021-3764 CVE-2021-3744 CVE-2021-3655 5.13 (impish, focal OEM)same as above plus SELinux specific issue around handling of taskcredentials -> 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)CVE-2021-3764 CVE-2021-3744 CVE-2021-37159 CVE-2021-3655 5.4 (focal, bionic HWE)AMD cryptographic coprocessor driver memory leaks -> DoS (Episode 138)SCTP OOB read - incoming packetsUSB Option High Speed Mobile driver -> UAF if unplug device before fullyregistered - 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)CVE-2021-3764 CVE-2021-3744 CVE-2021-37159 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)CVE-2021-43389 CVE-2021-43267 CVE-2021-43056 CVE-2021-42739 CVE-2021-42327 CVE-2021-3772 CVE-2021-3760 Mix of vulns in various driversUAF in NFC, DoS due to SCTP logic error, OOB in AMD GPU debugfs (needroot), 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)CVE-2021-43527 New NSS vulnerability (CVE-2021-43527) discussion [06:17]
Discovered by Tavis Ormandy at GPZNSS is a very old project, code in question has existed since 2003 andbeen exploitable since at least 2012 when it was refactored
Does a direct memcpy of an attacker controlled amount of data into afixed 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 calledso 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 doown fuzzing as well, extensive testsuite and uses ASAN for internal
builds
Uses Coverity but this didn’t detect it eitherExisting fuzzing and unit tests had test cases which could reach thiscode but failed to find it for a number of reasons:
Fuzz input is limited to 10k - but to overflow need at least 16,384bytes so fuzzing couldn’t have caught this
Individual code paths fuzzed but not so much end-to-end systematictesting - 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 tellhow 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 looksystematically 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.htmlGet in contact
#ubuntu-security on the Libera.Chat IRC networkubuntu-hardened mailing listSecurity section on discourse.ubuntu.com@ubuntu_sec on twitter