Overview
This week we dive into the BlackLotus UEFI bootkit teardown and find out how
this malware has some roots in the FOSS ecosystem, plus we look at security
updates for the Linux kernel, DCMTK, ZoneMinder, Python, tar and more.
This week in Ubuntu Security Updates
111 unique CVEs addressed
[USN-5739-2] MariaDB regression [00:48]
- Affecting Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- Latest point release had various memory and performance regressions
[USN-5883-1] Linux kernel (HWE) vulnerabilities [01:05]
- 19 CVEs addressed in Xenial ESM (16.04 ESM)
- 4.15 kernel backported from 18.04LTS to 16.04ESM
- sysctl stack buffer overflow discussed last week plus a range of other kernel
vulns
[USN-5884-1] Linux kernel (AWS) vulnerabilities [01:26]
- 6 CVEs addressed in Xenial ESM (16.04 ESM)
- 4.4 GA kernel from 16.04
[USN-5882-1] DCMTK vulnerabilities [01:36]
- 10 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- libraries and utils for handling DICOM (Digital Imaging and Communications in
Medicine) image files (used for radiology etc)
- various memory corruption issues -> DoS / code execution
[USN-5885-1] APR vulnerability [02:29]
- 1 CVEs addressed in Jammy (22.04 LTS), Kinetic (22.10)
- Integer overflow -> memory corruption -> DoS / code exec
[USN-5886-1] Intel Microcode vulnerabilities [02:44]
- 4 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- latest upstream release from Intel
- Various issues in SGX and out-of-band management - particularly on Intel Xeon
processors - allow require privileged access in the first place (ie admin) but
could allow to then say bypass SGX protections and the like
[USN-5887-1] ClamAV vulnerabilities [03:27]
- 2 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- latest upstream point release - 0.103.8
- one in HFS+ and the other in the DMG parsers - both different filesystem
formats for Apple
[USN-5889-1] ZoneMinder vulnerabilities [03:49]
- 13 CVEs addressed in Xenial ESM (16.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS)
- Video surveillance software system - includes a web interface so has usual
types of issues and then some
- Various XSS issues plus a stack buffer overflow in handling of username /
passwords as would use a fixed size buffer for these (what year is this?) and
a upload file handling issue resulting in possible remote code execution
[USN-5890-1] Open vSwitch vulnerabilities [04:27]
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- 3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- 3 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
[USN-5892-1] NSS vulnerabilities
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5893-1] WebKitGTK vulnerabilities [04:34]
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- type confusion in webkit - Apple says that they had seen reports that this had
been actively exploited in the wild
[USN-5896-1] Rack vulnerabilities
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS)
[USN-5895-1] MPlayer vulnerabilities
- 10 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5897-1] OpenJDK vulnerabilities [04:55]
- 2 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- openjdk 11 (aka lts), 17, 18
- latest upstream point releases
[USN-5898-1] OpenJDK vulnerabilities [05:05]
- 2 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- openjdk 8 - also latest upstream point release
[USN-5888-1] Python vulnerabilities [05:09]
- 6 CVEs addressed in Focal (20.04 LTS)
- python3.9 - esm-apps
- high priority - vuln in multiprocessing module - if used with forkserver on
Linux would allow pickles to be deserialized from any user on the same machine
in the same network namespace - therefore as one local user can easily get
code execution as another user on the same machine
[USN-5899-1] AWStats vulnerability
- 1 CVEs addressed in Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5901-1] GnuTLS vulnerability
- 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5902-1] PHP vulnerabilities
- 3 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5903-1] lighttpd vulnerabilities
- 2 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
[USN-5638-4] Expat vulnerabilities
- 2 CVEs addressed in Trusty ESM (14.04 ESM)
[USN-5900-1] tar vulnerability [06:15]
- 1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic (18.04 LTS), Focal (20.04 LTS), Jammy (22.04 LTS), Kinetic (22.10)
- 1-byte OOB read - although as yet no evidence this can be used to gain control
flow hence really only a possible DoS
[USN-5880-2] Firefox regressions [06:42]
- 15 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
- 110.0.1 - biggest regression was that if chose to clear recent cookies it
would clear all cookies - plus a webgl crash when running under vmware on
Linux
Goings on in Ubuntu Security Community
BlackLotus UEFI bootkit teardown [07:23]
- https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
- https://github.com/Wack0/CVE-2022-21894
- Teardown of the first in-the-wild UEFI bootkit that bypasses UEFI Secure Boot
by eset
- Appears to be BlackLotus which has been sold on hacking and criminal forums
since atleast October 2022
- At that time no sample was available so security researchers could not verify
the claims of the malware author, namely:
- very small - only 80kb, has anti-debug / obfuscation to help avoid RE
- bypasses Windows UAC + Secure Boot and can load unsigned drivers
- disables HVCI (hypervisor protected code integrity - a feature designed to
protect the Windows kernel from modification at runtime), BitLocker and
Windows Defender
- persists in UEFI and is able to protect itself from being unloaded
- uses a signed boot loader so can work on machines with Secure Boot enabled
- Of these, the most interesting part for Linux users is the UEFI Secure Boot
bypass - this is something which we theorised was possible via all the
previously disclosed shim and grub vulnerabilities
- And in particular, they way they go about this is by using a copy of
shim
and grub
- but not because they are exploiting any vulnerabilities in them,
but since they are very useful components if you want to boot your own
bootkit
- they also exploit a vulnerability in the Windows Boot Manager UEFI binary
which allows them to subvert the Secure Boot process and load their own code
to bypass Secure Boot and gain persistence on future boots
- they way they do this is to install their own UEFI binaries into the EFI
partition (including
shim
and grub
) - but also a copy of a vulnerable
version of the Windows Boot Manager UEFI binary plus their own custom boot
configuration data - and since they have disabled BitLocker already these
will happily be loaded at next boot without the usual integrity checks etc
- when the machine reboots, their vulnerable Windows Boot Manager binary is
loaded, along with their custom boot configuration data which allows them to
exploit the vulnerability and to then load additional binaries into the boot
process
- those binaries then go on to modify the secure boot configuration by
enrolling a new key in the machine owners keyring (aka MOK) db
- normally enrolling a new key like this would require a system admin to be
physically present to confirm the operation - but since they bypasses the
normal Secure Boot protections this can be done without any knowledge of
the sysadmin
- their
grub
is signed using this key whilst the shim
is Red Hat’s shim
-
unmodified and signed by Microsoft and hence trusted - this will then trust
their malicious grub
as it is signed by the key they just enrolled in the
MOK
- whilst their
shim
is an unmodified copy, their grub
is not - and is actually
malicious
shim
then goes on to boot this malicious grub
which starts Windows but also
installs a bunch of UEFI memory hooks to be able to subvert further stages
of the boot process and eventually Windows itself
- There are lots more details in the teardown article, particularly about how
the various components are installed into Windows and how they are able to
then load additional drivers etc into Windows, plus the further components of
the malware that are able to download additional binaries, how the C2 and
anti-analysis etc works - but this is the USP so we won’t cover those here
- But what is interesting for Linux is that this is reusing components that were
ostensibly designed to boot Linux on machines that were originally designed to
boot Windows
- one member of our team wondered if Microsoft might become more hesitant
about signing
shim
in the future - perhaps, but it is not really shim
that
is at fault here - the issue is the original vulnerability in the Windows
Boot Manager - shim
just helps to make loading additional parts of their
bootkit easier (along with grub
) - so hopefully Microsoft don’t go down that
path
- and the reason this can be exploited in the first place is that Microsoft
have not revoked their vulnerable Windows Boot Manager binary
- back in the original BootHole vulns, various
shim
’s did get revoked - but
revoking this Microsoft binary would mean many older systems may fail to
boot, including their recovery images and install media etc
- ideally Microsoft would revoke this to stop further exploitation
- Another interesting wrinkle is that their UEFI exploit apparently appears to
come directly from a PoC that was uploaded to Github in August 2022 - will
likely restart the usual discussions around public PoCs being a “bad thing” as
they can be used for actual malicious purposes
- interesting to note the PoC has had additional code added to it in the last
24 hours which allow it to operate on older versions of Windows 10
- even more reason for Microsoft to perhaps revoke this old binary
Get in contact