Episode 133

Posted on Friday, Oct 1, 2021
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!

Show Notes

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

[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 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]

[USN-5092-1, USN-5092-2] Linux kernel vulnerabilities [09:56]

[USN-5094-1] Linux kernel vulnerabilities [10:39]

[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