All autopkgtests for the newly accepted openssh (1:9.6p1-3ubuntu13.6) for noble have finished running. The following regressions have been reported in tests triggered by the package:
crmsh/unknown (i386) debvm/unknown (amd64) fence-agents/4.12.1-2~exp1ubuntu4 (amd64) freedombox/unknown (amd64) g10k/unknown (amd64) gvfs/unknown (amd64) libnet-scp-perl/unknown (amd64) libnet-sftp-foreign-perl/unknown (amd64) libnetapp-perl/unknown (amd64) nova/unknown (i386) pkg-perl-tools/0.78 (amd64, armhf) rancid/unknown (amd64) tinyssh/20240101-2 (amd64, armhf) ubuntu-boot-test/2 (amd64) vorta/unknown (amd64) wcc/unknown (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/noble/update_excuses.html#openssh [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2071815 Title: Investigate ASLR re-randomization being disabled for children Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Noble: Fix Committed Bug description: [Impact] The systemd-socket-activation.patch patch has an Ubuntu delta to fix bug 2011458, but this results in ASLR not being re-randomized for children because the patch delta does "rexec_flag = 0;". This was discovered as part of the CVE-2024-6387 discovery by Qualys, and is mentioned in the disclosure itself: Side note: we discovered that Ubuntu 24.04 does not re-randomize the ASLR of its sshd children (it is randomized only once, at boot time); we tracked this down to the patch below, which turns off sshd's rexec_flag. This is generally a bad idea, but in the particular case of this signal handler race condition, it prevents sshd from being exploitable: the syslog() inside the SIGALRM handler does not call any of the malloc functions, because it is never the very first call to syslog(). This is also mentioned in the release notes of OpenSSH 9.8: Exploitation on non-glibc systems is conceivable but has not been examined. Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation (yes - this is a thing, no - we don't understand why) may potentially have an easier path to exploitation. We should investigate why that was needed, and if an alternative way of fixing the original bug can be done. [Test Plan] We just want to test that when a connection is accepted by sshd, the child process re-execs. There is a log message at the debug level from sshd when this happens. 1. Enable debug-level logging in sshd: $ echo "LogLevel DEBUG" >> /etc/ssh/sshd_config.d/log-level.conf 2. Watch the logs: $ journalctl -t sshd -b -f 3. From another host, connect to the test machine: $ ssh <user>@<test host> 4. On the test machine, among other messages, there should be a message noting the start of the re-exec, e.g.: sshd[2212]: debug1: rexec start in 6 out 6 newsock 6 pipe 8 sock 9 [Where problems could occur] Through the iterations of d/p/systemd-socket-activation.patch, there have been issues related to the re-exec behavior, and how the listen fds passed by systemd are handled. See [1][2] for examples. This patch hopes to finally resolve these issues. However, as was the case with previous bugs in this area, problems would most likely be related to incorrectly closing, or not closing, socket fds in sshd. [1] https://bugs.launchpad.net/bugs/2020474 [2] https://bugs.launchpad.net/bugs/2011458 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2071815/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
