Overview
This week we look at a Wifi lookalike attack dubbed “SSID stripping” plus
updates for ca-certificates, EDK II, Apache, the Linux kernel and even vim!
This week in Ubuntu Security Updates
[USN-5086-1] Linux kernel vulnerability [00:50]
Affecting Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)s390x BPF JIT verifier bypass - no CVE assigned[USN-5085-1] SQL parse vulnerability [01:33]
1 CVEs addressed in Hirsute (21.04)CVE-2021-32839 ReDoS via exponential backtracking with a large amount ofcarriage-return, newline combinations
[USN-5087-1] WebKitGTK vulnerabilities [02:18]
1 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)CVE-2021-30858 UAF in underlying webkit - originally reported by Apple against theirvarious operating systems - not actually against webkit directly…
[USN-5088-1] EDK II vulnerabilities [02:46]
4 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)CVE-2021-38575 CVE-2021-3712 CVE-2021-23840 CVE-2019-11098 mix of issues in the embedded openssl in EDK-II plus 2 issues specific toEDK-II itself - one in the handling of Intel Boot Guard which is designed
to detect attacks against the static root of trust, in particualr
modifification of the initial boot block - an attacker with physical
access to the SPI flash chip, could get code execution after the IBB has
been validated by then injecting SPI transactions to modify the contents
of the IBB in memory
[USN-5089-1, USN-5089-2] ca-certificates update [04:34]
Affecting Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)To also support older devices which don;t have that root cert and whenLetsEncrypt started they got their issuing / intermediate cert (R3)
signed by IdenTrust’s “DST Root CA X3” root certificate -
“cross-signature”
DST Root CA X3 cert expired yesterday (30th Sept 2021)So if you only had that then any HTTPS connections to a site using aLetsEncrypt cert would fail
Also to support various older Android devices which aren’t getting anyupdates anymore, IdenTrust issued an updated cross-signature expiring in
Sept 2024 so that those Android devices would continue to trust the
issuing cert
Nowadays LetsEncrypt has their own root cert “ISRG Root X1” - which istrusted by ca-certificates - this is present on all Ubuntu back to 12.04
But older versions of openssl (1.0.x - xenial, trusty, precise!?!) andgnutls etc would see the cross-signature with an expiry in the future and
so return this as a valid chain to validate against - but then when
validating the full chain, it would fail as the DST Root CA X3 cert at
the root is now expired
Would cause connections to fail stillSolution is to blacklist the DST Root CA X3 as this then ensures thecross-signature is seen as invalid and instead the shorter chain back to
LetsEncrypt’s own root cert is used to do the validation
[USN-5090-1, USN-5090-2, USN-5090-3, USN-5090-4] Apache HTTP Server vulnerabilities + regression [07:41]
5 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)CVE-2021-40438 CVE-2021-39275 CVE-2021-34798 CVE-2021-36160 CVE-2021-33193 HTTP/2 specific issue - crafted method would bypass validation and beforwarded by mod_proxy - so could lead to request splitting / cache
poising
NULL pointer dereference triggerable via crafted requestOOB read in mod_proxy_uwsgi - crash / info leakOOB write in ap_escape_quotes() if given malicious input - modules inapache itself don’t pass untrusted input to this but other 3rd party
modules might
crafted request to mod_proxy - forward the request to an origin server asspecified in the request - SSRF
fix for this resulted in more stricter interpretation of SetHandlerconfig option for mod_proxy that broke various configurations using
unix sockets - these got interpreted more like URIs and so would be
seen as invalid - broke Plesk and others - upstream then issued further
fixes which we released in a follow-up
[USN-5091-1] Linux kernel vulnerabilities [09:44]
6 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)CVE-2021-38204 CVE-2021-38199 CVE-2021-38160 CVE-2021-37576 CVE-2021-3679 CVE-2021-33624 5.4 (focal / bionic hwe)[USN-5092-1, USN-5092-2] Linux kernel vulnerabilities [09:56]
12 CVEs addressed in Focal (20.04 LTS), Hirsute (21.04)CVE-2021-38205 CVE-2021-38204 CVE-2021-38201 CVE-2021-38199 CVE-2021-38160 CVE-2021-37576 CVE-2021-37159 CVE-2021-3679 CVE-2021-35477 CVE-2021-34556 CVE-2021-33624 CVE-2021-41073 5.11 (hirsute, focal hwe)io_uring (5.1) - unprivileged user - trigger free of other kernelmemory - code execution
3 issues in BPF verifier - spectre-like side-channel attacks to leakkernel memory
KVM guest could corrupt host memory on PowerPC - crash / code exec[USN-5094-1] Linux kernel vulnerabilities [10:39]
6 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS)CVE-2021-38205 CVE-2021-38204 CVE-2021-37576 CVE-2021-3732 CVE-2021-3679 CVE-2021-22543 4.15 (bionic, xenial hwe, trusty azure)[USN-5093-1] Vim vulnerabilities [10:57]
3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Hirsute (21.04)CVE-2021-3796 CVE-2021-3778 CVE-2021-3770 Possible code-execution through 2 different heap buffer overflows and 1UAF
Goings on in Ubuntu Security Community
SSID stripping attack against various OSes including Ubuntu [11:37]
https://aireye.tech/2021/09/13/the-ssid-stripping-vulnerability-when-you-dont-see-what-you-get/Combination of lookalike AP name attacks and possible format-string vulnsagainst Windows, MacOS, iOS, Android and Ubuntu
Lookalike SSIDs uses non-printable chars so that user only sees a chosenpart of the SSID name rather than the entire thing so gets confused
Similar to domain-name lookalike attacks often used in phishing etc - notreally a new problem
No real details on what in Ubuntu is affected (wpa_supplicant,NetworkManager, gnome-shell etc)
Best remediation would be to try and display all chars in somerepresentable format to users but then could still get lookalike names
that use these placeholder chars
Hard problem to solve well but given that this doesn’t allow to capturecredentials anyway (assuming are using WPA2-PSK since 4-way handshake
makes both the client and AP prove they know the PSK without revealing it
to each other) then is not really much of a risk
Only relevant then to unsecured networks but if you are connecting toan unsecured network then there is no security anyway
Hiring [15:54]
Linux Cryptography and Security Engineer
https://canonical.com/careers/2612092/linux-cryptography-and-security-engineer-remoteSecurity Engineer - Ubuntu
https://canonical.com/careers/2925180/security-engineer-ubuntu-remoteSecurity Product Manager
https://canonical.com/careers/2278145/security-product-manager-remote1 week break for the Ubuntu Security Podcast
Back in your feed in 2 weeks in the middle of OctoberFarewell Ubuntu Podcast
https://ubuntupodcast.orgGet in contact
#ubuntu-security on the Libera.Chat IRC networkubuntu-hardened mailing listSecurity section on discourse.ubuntu.com@ubuntu_sec on twitter