For the final episode of 2023 we discuss creating PoCs for vulns in tar and the looming EOL for Ubuntu 23.04, plus we look into security updates for curl, BlueZ, Netatalk, GNOME Settings and a heap more.
57 unique CVEs addressed
.com
/ .org
but also .co.uk
etc - since there is no good algorithmic way of determining the highest level
at which a domain may be registered for a particular TLD as each registrar is
different
domain=co.UK
with a URL of say curl.co.uk
and
this would then get sent to every other .co.uk
domain contrary to the
expectations of the PSL which lists .co.uk
as a PSL domainvmware-user-suid
wrapper - a
local user with non-root privileges that is able to hijack the /dev/uinput
file descriptor may be able to simulate user inputsClassicBondedOnly=true
- this may
break some legacy input devices like PS3 controller - in which case, should
edit /etc/bluetooth/input.conf
and set this back to false
but then beware that
you may be vulnerable to attack from anyone within bluetooth range when your
machines is discoverable - ie. bluetooth settings panel is opengetaddrinfo()
-
possible to still trigger1 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Lunar (23.04), Mantic (23.10)
Stack buffer overflow on parsing a tar archive with an extremely large
extended attribute name/value - PAX
archive format allows to store extended
attributes - on the kernel’s VFS layer these are limited to 255 bytes for the
name and 64kB for the value - but in a tar these can be basically arbitrary
When processing the archive, tar would allocate space for these on the stack - BUT the stack is limited to a maximum size of 8MB normally - so if can specify an xattr name of more than 8MB can overflow the entire stack memory region - then into guard pages or even beyond, triggering a segfault or at worst a heap corruption and hence possible RCE -> but in Ubuntu we have enabled stack clash protection since 19.10 - which turns this into a DoS only
$ hardening-check $(which tar)
/usr/bin/tar:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yes
Stack clash protection: yes
Control flow integrity: yes
Speaking from experience, it is not easy to create such an archive - either through a real xattr on disk or through specifying one on the command-line (since you can specify arbitrary attributes be stored for files when adding them to an archive but then you hit the maximum limit of command-line arguments) BUT it is possible - in my case I did this though using sed to replace the contents of a xattr name in an existing archive with a crafted one and then doing a bunch of other hacks to fixup all the metadata of the tar archive to match - helpfully, all these attributes in the archive are stored as NUL-terminated strings, so can simply used sed to fix them all up assuming you can calculate the correct values
Fixed by instead allocating these on the heap which does not have the same arbitrary limitation as the stack
objdump
etcos.path.normpath()
it would get truncated at the NUL byte -
fixed to remove this behaviour