[02:17] good morning [12:20] https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt [12:20] -ubottu:#ubuntu-discuss- A signal handler race condition was found in OpenSSH's server (sshd), where a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog(). [12:23] lotuspsychj3: there's package updates for every supported release that is vulnerable [12:24] https://ubuntu.com/security/CVE-2024-6387 [12:24] -ubottu:#ubuntu-discuss- A signal handler race condition was found in OpenSSH's server (sshd), where a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd's SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog(). [12:24] long fixed 😛 [12:24] yeah tnx, im 1 day behind my security news :p [13:12] would have been really really bad if Ubuntu wouldn't have had fixes in time when there is a "coordinated release date" involving upstreams/downstreams/researchers :) [13:13] OTOH, the more people know how urgent this update is the better, I guess [13:32] been scratching my head why I didn't get an update... running an old enough LTS version it doesn't apply to me. win, for being a late adopter! [13:51] hehe [13:52] I had some old system without update too, always good to check the OpenSSH version to be sure indeed [13:53] annoyed that Rocky isn't putting the patch in their main repo... instead opting for some security repo. but that machine isn't connectable from the Internet at this time. So not going to worry about it for now [13:59] it's not in the "main repo" in Ubuntu either... only in -updates & -security ;) [14:00] but I assume you mean something else for Rocky [14:00] (I don't really know how Rocky works nowadays) [14:11] It's similar, I meant to main repos, not just the primary. But their remediation article says to install another repo SIG/security to get the patch for openssh. The article is at https://rockylinux.org/news/2024-07-01-rocky-linux-9-cve-2024-6378-regression if you're curious [14:11] -ubottu:#ubuntu-discuss- ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. [14:12] okay... that's an annoying feature ubottu [14:13] Can someone fix that? The pattern should make sure that the CVE designation has white space on either side, to avoid triggering that when it is embedded in a link [14:18] I don't mind if it finds CVEs inside URLs [14:19] that's not the problem here, the problem is they apparently made a typo in their original article title, and the slug wasn't updated after they fixed the title :) [14:20] It might not always be a CVE in the URL... could just be someone's poor choice in naming convention/generation of their URLs [14:20] that applies to non-URL mentions including "CVE" too, of course [14:21] Yes, but I feel that's less likely for someone to prattle off something like CVE-2024-0000 in casual conversation [14:22] I haven't seen any URLs triggering it incorrectly [14:25] pretty handy CVE & bugs link titles [14:26] seems like this whole thing is (at least in part) the result of RH policies? [14:27] the special repo [14:28] not sure, When RH pulled the plug on their source repos being public, left a lot of the EL distros scrambling. [14:30] In this case it appears to be a repo to hold security patches that cannot be sourced from any upstream EL repository. Meaning, the patch is probably not in the CentOS Stream repos === PowaBanga_ is now known as PowaBanga [14:50] sources only have to be published when the binary packages are released, but Rocky had to make fixes before that [15:30] sources dont have to be published at all ... *if* someone asks for them you need to make them available ... but there is no obligation on the format ... i.e. you could send a box with punchcards to the asking person and would fulfill the GPL [15:31] true, but they probably don't want to handle individual requests--that could become time-consuming & expensive quickly :) [15:32] also, OpenSSH isn't GPL, of course [15:33] indeed, nobody wants that which is why everyone publishes sources ... but this is not a *must* [15:33] yeah, and there is that ... [15:34] (FWIW, i have always wondered how many trucks the current kernel source would fill if you printed it out on punchcards) [15:34] my point was more about the timing: Rocky wanted packages ready & available before the "coordinated release date", but even if RH publish source packages they won't do so before that date [15:35] You would need very wide punchcards... or a lot of shift registers in the read in [15:35] well, the question is also if rocky is even on the embargo list so they can get access to the fixes before release [15:36] pretty sure they are [15:36] I would hope they are [15:36] arent they a RH downstream ? [15:36] it seems like that repo is also used by several other EL clones [15:36] hence why I believe the patch was issued through a designated security repo [15:37] so is Oracle, but sure Oracle is on that list too? [15:38] well, i'm pretty sure i.e. linuxmint isnt [15:38] probably a matter of size too [15:38] the upstream patch itself was, I'm sure, but stuff like the changelog message would not be :) [15:39] and other distro-related stuff, like marking it important/urgent or whatever [15:41] doesn't linuxmint depend on Ubuntu/Debian repos? [15:43] except for the packages they hack [15:43] for that they have their own overlay repo i think [15:43] I sure hope they don't mess with OpenSSH :) [15:43] who knows .... they used to mess with Xorg, GTK and the kernel in the past [15:43] and they would know about reported security bugs where they are upstream [15:44] oh [15:44] luckily they stopped doing the Xorg and kernel bits long ago and simply use ours [15:45] but i think their GTK still carries patches for cinnamon .... [15:48] let's hope they are kept into the loop for serious Gtk security bugs then [15:48] yeah [15:50] (as hopefully they also inform other distros about serious cinnamon issues--it's mutually beneficial) [15:55] far as I can tell, embargo just means the details are unreleased and waiting on the original source to be patched by its maintainer. So no one is really on any embargo list, only that the controllers of information will not release until the software vendor says they've issued their patches. So the maintainer of OpenSSH would have to maintain a channel for informing downstream subscribers of their issuance of a security patch and [15:55] ask them to kindly refrain from publicly disclosing it until the maintainer is ready [19:10] JanC: There are plenty of moderators and ops in channel. if there's a problem, they will take care of it when they want to. [19:14] I know [20:34] ogra_: rocky should be on the distros list, which was used for coordinating the openssh issue https://www.openwall.com/lists/oss-security/2023/10/17/4 [20:35] ogra_: if they didn't have packages ready on release day, maybe they were just on holiday? it landed during canada day and a few days before the 4th of july, lots of north americans take time off around these days [20:37] It's almost like it was it was intentionally dropped just before major north american holidays on purpose [20:37] as far as I can remember Rocky is now represented in oss-security [20:38] (they applied a few months back [21:06] sarnold: they were on release day AFAICT, but they were released in a separate repo that (apparently) not everybody knows about yet [21:07] I assume their main repo is supposed to be a clone of RHEL, and they couldn't do that for these security updates if they wanted to release on release day... [21:38] JanC: ahhhhhhhhhhhh