Sveriges mest populära poddar
Start / Ubuntu Security Podcast / Episode 171

Ubuntu Security Podcast

Episode 171

23 min • 5 augusti 2022

Overview

This week we dig into what community sponsored security updates are all about, plus Ubuntu 22.04.1 LTS gets delayed by a week and we cover security updates for MySQL, the Linux kernel, Samba, Net-SNMP and more.

This week in Ubuntu Security Updates

75 unique CVEs addressed

[USN-5535-1] Intel Microcode vulnerabilities [00:43]

[USN-5537-1, USN-5537-2] MySQL vulnerabilities [01:22]

[USN-5538-1] libtirpc vulnerability [01:59]

  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  • Transport independent RPC library - Used by autofs, libvirt, nfs-utils, python, samba, yp-tools and lots more
  • Failed to properly handle timeouts from idle clients - would still keep a file descriptor open and eventually would exhaust available fds so could then not accept new connections (since it would also not handle the case of no available fds either and would spin in a busy loop trying to accept new connections) - CPU-based DoS

[USN-5536-1] Firefox vulnerabilities [02:47]

[USN-5544-1] Linux kernel vulnerabilities [03:06]

  • 4 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  • 5.15 22.04 LTS GA / 20.04 LTS HWE
  • UAF in Atheros ath9k driver when handling certain error conditions, Sun RPC and floppy driver
  • Also a type confusion bug in netfilter - local user who has CAP_NET_ADMIN (which can be done via mapping to root in an unprivileged user namespace) -> privesc

[USN-5545-1] Linux kernel (OEM) vulnerability [03:49]

  • 1 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  • netfilter privesc above for 5.14 and 5.17 OEM kernels in 20.04 and 22.04 LTS respectively

[USN-5539-1] Linux kernel vulnerabilities [04:11]

  • 7 CVEs addressed in Bionic (18.04 LTS), Focal (20.04 LTS)
  • 5.4 - NVIDIA BlueField on 20.04 LTS and GCP/GKE 18.04 LTS
  • 6 out of 7 are various UAF bugs - 3 in the AX.25 amateur radio protocol driver, 1 in 6pack and mkiss protocol drivers, 1 in 8 Devices USB2CAN and 1 in floppy driver
  • KVM hypervisor failed to handle guest TLB invalidations - guest could then corrupt host memory
  • Result of all these is memory corruption -> crash / code-execution

[USN-5541-1] Linux kernel (Azure) vulnerabilities [05:04]

[USN-5540-1] Linux kernel vulnerabilities [05:26]

  • 4 CVEs addressed in Trusty ESM (14.04 ESM), Xenial ESM (16.04 ESM)
  • 4.4 - 16.04 ESM GA (lowlatency, AWS, KVM etc) + 14.04 ESM
  • race-condition -> UAF in IGMP protocol impl - local user -> DoS / code-exec
  • Memory corruption in USB gadget driver
  • OOB read in RNDIS driver -> info leak / crash
  • netfilter privesc

[USN-5542-1] Samba vulnerabilities [06:06]

  • 6 CVEs addressed in Focal (20.04 LTS), Jammy (22.04 LTS)
  • Didn’t handle MaxQueryDuration as expected
  • Possible privesc since restrictions were not enforced properly when changing passwords
  • Separate password-based privesc since could forge a password request with your own key that was destined for another user and therefore change their password (including domain admin)
  • Memory corruption via crafted LDAP request -> DoS / info leak
  • Unfortunately due to the large amount of code-churn in samba from the version used in 18.04 LTS (4.7.6) compared to the current upstream release (4.16.x) it is not possible to backport these patches without a reasonable risk of introducing a regression - as such users of samba in 18.04 LTS who are concerned about these vulnerabilities are advised to upgrade to Ubuntu 20.04 LTS or newer to continue receiving security support for samba

[USN-5543-1] Net-SNMP vulnerabilities [07:25]

[USN-5463-2] NTFS-3G vulnerabilities [07:45]

Goings on in Ubuntu Security Community

An overview of the community security updates sponsoring process [08:20]

  • Ubuntu Security team supports packages in main+restricted as per standard support
  • Universe (and multiverse) components are supported by the community
  • The ideal process here is a community member files a bug on LP, subscribes the Ubuntu Security Sponsors team and attaches a debdiff
  • What is a debdiff?
    • A debdiff is a diff of the source package between the current version in the Ubuntu archive and the new updated version being proposed
  • What should the debdiff contain?
    • The bare minimum of changes required to patch the vulnerability
      • ie. a patch file derived from the original upstream project’s patch which fixed the vulnerability, as well as a new changelog entry describing this update
      • In general even though an upstream project may release a new version of their software when patching security vulnerabilies, in Ubuntu we will not just upgrade to this new version (in the lifetime of a stable release) to fix the vulnerability - instead we will just cherry-pick the minimal change required to fix the issue and apply this ontop of the older version of the software which is maintained for the life a given Ubuntu release
      • This reduces the chance of introducing a regression due to new upstream features getting introduced etc
    • Regarding patches - most packages use Quilt to manage the set of patches that get applied ontop of the upstream source tarball within a debian package
    • Therefore the debdiff should likely be a new patch file within the debian/patches directory as well as a corresponding entry for it in the debian/patches/series file, and then a new debian/changelog entry
    • Sometimes to backport a fix other supporting commits from the upstream project may be needed - these can then be included as additional patch files too
  • What happens next?
    • Ubuntu Security team member reviews the debiff to make sure it conforms to the above - in particular to check that the original upstream patch was used and no other changes were introduced (again to make sure we keep the risk of regression low and so we have provenance of the code which has been introduced)
    • Will usually do a local build of the package and then upload it to the Ubuntu Security Proposed PPA - this is a publicly accessible PPA which allows the resulting candidate packages to be tested by the Security Team member as well as the community member
    • Once testing looks good, the package can be published to the Ubuntu archive along with an associated USN
  • A recent examples of this is in https://bugs.launchpad.net/ubuntu/+source/spip/+bug/1971185 which corresponded to USN-5482-1 - SPIP for bionic
  • The team maintains a lot of documentation on how we set up our local build and testing environments to make the process a lot easier - in particular the umt tool which can be used for managing most of these steps (ie. downloading source packages, adding a new changelog entry, building the package locally in a schroot, testing the package locally in a VM etc)

Ubuntu 22.04.1 release delayed [17:00]

  • https://discourse.ubuntu.com/t/jammy-jellyfish-22-04-1-lts-point-release-status-tracking/29102
  • Delayed until 11th August - can see test status on the ISO tracker - essentially was a bug in snapd when being installed in OEM mode
    • Used by OEMs to install Ubuntu on machines so that when first powered on by the end user they are offered to setup the machine (create a local user account, set timezone/language etc)
  • Bug is that firefox wouldn’t run
  • As earlier, Firefox is now a snap in 22.04 LTS - and the bug is that all snaps which are seeded (ie. shipped on the ISO and installed OOTB) would not run
    • only 2 applications fit this - firefox and snap-store - but both are crucial applications (ie web browser and app store)
  • snaps are squashfs images that get mounted on boot as systemd mount units
  • like many systemd units, they specify as WantedBy=multi-user.target - ie the multi-user target wants them which ensures they are mounted during normal boot (equivalent to runlevel 2 - ie. not a rescue shell or shutdown etc) - so basically any normal boot of the system and they should be mounted
  • During OEM mode though, on that first boot by the user, the OEM installer has set the boot target to it’s own oem-config.target so it can run first (to create a new user etc) - and then once it is done it sets the target to the usual graphical.target which includes multi-user.target
  • Everything then should work though as we do eventually hit the right target
  • Current thinking is that the new snapd-desktop-integration which is used to try and automatically install theme snaps and the like to match the system theme - gets started as part of the oem-config and it then pokes the snapd.socket which causes snapd.service to be started - yet the snap mount units are not in place, so snapd can’t see any of the expected snaps, as such it fails to correctly generate their state information
  • when they do go to be run, they have none of their expected interfaces defined or connected and so cannot access anything and fail - and even a reboot doesn’t help as the old invalid state is still kept even though the snaps are now mounted correctly
  • requires a fix in snapd so that the mount units specify not just multi-user.target but default.target so they get mounted no matter what target is being booted into

Get in contact

Kategorier
PoddarTeknologi
Förekommer på
Teknik
00:00 -00:00
Hur lyssnar jag på podcast?

En liten tjänst av I'm With Friends. Finns även på engelska.