[Bug 2026235] Re: Merge a5e6c8498ca, corrupted resolfconf results in inability to talk to link local DNS servers

[gutschke]

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2026235

Title:
  Merge a5e6c8498ca, corrupted resolfconf results in inability to talk
  to link local DNS servers

Status in systemd package in Ubuntu:
  New

Bug description:
  Package:     systemd 249.11-0ubuntu3.9 https://packages.ubuntu.com/jammy/systemd
  Description: Ubuntu 22.04.2 LTS
  Release:     22.04

  Please merge https://github.com/systemd/systemd/commit/a5e6c8498ca for
  the Ubuntu LTS release. It's a one-line fix that sets an uninitialized
  variable to zero.

  Until this fix is implemented, resolveconf generates incorrect DNS
  configuration for link-local IPv6 addresses discovered from Router
  Advertisements (RA). It retrieves the correct address, but then
  appends a random interface index. So, instead of fe80:xxxx::xxxx, the
  DNS server reads fe80:xxxx::xxxx%NNN This results in the client no
  longer being able to reach the locally configured DNS server.

  This bug can be reproduced by installing a DNS server and radvd
  (Router Advertisement demon) in an LXC container that shares a network
  bridge with another container running Ubuntu Jammy. If Jammy is
  configured to accept RDNSS information from RA, it will set the wrong
  server address.

  I believe this only works if radvd advertises a link-local addresses
  as part of the RDNSS information. If instead, it advertises a globally
  routable address (e.g. 2001:XXXX::XXXX) there is no issue.

  While uninitialized memory is always scary, I don't believe this is
  worse than maybe a denial-of-service attack? So, not quite sure
  whether this is an exploitable security issue. But that probably
  depends on exactly how the network topology looks like and whether an
  attacker can gain (limited) control over manipulating RA packets. It
  is possible that some clusters and/or containers would suffer security
  issues because of this problem.

  Also, this is technically a way to leak memory from within a systemd-
  related process. But I don't see an obvious way how to exploit this
  very limited data leak.

  Out of an abundance of precaution, I am marking this as a security
  issue. Please feel free to unflag, if you think that assessment isn't
  warranted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2026235/+subscriptions