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
28 unique CVEs addressed
[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)
- ReDoS via exponential backtracking with a large amount of
carriage-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)
- UAF in underlying webkit - originally reported by Apple against their
various 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)
- mix of issues in the embedded openssl in EDK-II plus 2 issues specific to
EDK-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
- 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 when
LetsEncrypt 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 a
LetsEncrypt cert would fail
- Also to support various older Android devices which aren’t getting any
updates 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 is
trusted by ca-certificates - this is present on all Ubuntu back to 12.04
- But older versions of openssl (1.0.x - xenial, trusty, precise!?!) and
gnutls 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 still
- Solution is to blacklist the DST Root CA X3 as this then ensures the
cross-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)
- HTTP/2 specific issue - crafted method would bypass validation and be
forwarded by
mod_proxy
- so could lead to request splitting / cache
poising
- NULL pointer dereference triggerable via crafted request
- OOB read in
mod_proxy_uwsgi
- crash / info leak
- OOB write in
ap_escape_quotes()
if given malicious input - modules in
apache 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 as
specified in the request - SSRF
- fix for this resulted in more stricter interpretation of
SetHandler
config 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)
- 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)
- 5.11 (hirsute, focal hwe)
io_uring
(5.1) - unprivileged user - trigger free of other kernel
memory - code execution
- 3 issues in BPF verifier - spectre-like side-channel attacks to leak
kernel 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)
- 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)
- Possible code-execution through 2 different heap buffer overflows and 1
UAF
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 vulns
against Windows, MacOS, iOS, Android and Ubuntu
- Lookalike SSIDs uses non-printable chars so that user only sees a chosen
part of the SSID name rather than the entire thing so gets confused
- Similar to domain-name lookalike attacks often used in phishing etc - not
really 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 some
representable 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 capture
credentials 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 to
an unsecured network then there is no security anyway
Hiring [15:54]
Linux Cryptography and Security Engineer
Security Engineer - Ubuntu
Security Product Manager
1 week break for the Ubuntu Security Podcast
- Back in your feed in 2 weeks in the middle of October
Farewell Ubuntu Podcast
Get in contact