2024-03-03 21:11:06 https://xenbits.xen.org/xsa/advisory-451.html 2024-03-03 21:11:30 I often take these but haven't managed to prioritize lately 2024-03-12 06:37:33 "In addition, I guess that OS level mechanisms similar to root certificate stores may be needed to centralize CRL updates; having each application pull down potentially large CRL updates once a week seems inefficient." 2024-03-12 06:38:32 https://www.openwall.com/lists/oss-security/2024/03/11/2 2024-03-19 00:03:25 !62451 !62454 !62455 !62456 2024-03-21 16:21:27 do we have anyone subscribed to https://oss-security.openwall.org/wiki/mailing-lists/distros ? 2024-03-21 16:31:28 I don't think so. There are requirements to be a member of that list 2024-03-21 16:55:25 would be good to be on I think 2024-03-21 16:57:30 It comes with obligations 2024-03-21 16:57:47 Each member also has to do some tasks 2024-03-21 16:58:06 so it's costs vs benefits 2024-03-21 16:58:55 What do we gain from knowing a bit earlier about some vulnerability? 2024-03-21 16:59:29 Can we make use of that in a way that we make sure we do not disclose anything 2024-03-21 16:59:44 And does that actually help us 2024-03-21 17:00:25 We most likely cannot let the maintainer of the package know, so someone who is a member needs to prepare an MR in secret 2024-03-21 17:00:34 and kind of bypass the maintainer 2024-03-21 17:05:20 ah I think I only read the policies for posting before 2024-03-21 17:08:49 ttps://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-members 2024-03-21 17:08:53 https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-members 2024-03-21 17:11:52 yeah I think this could be a long-term goal if we had a security team and such, unless there's an individual willing to handle this 2024-03-21 17:12:21 In most cases, we are able to quickly update packages as soon as the information is released 2024-03-21 17:12:40 IIUC the benefit is just to further decrease reaction time between issue disclosure and issues being fixed from + to immediately after disclosure 2024-03-21 17:12:55 yeah that's what I figure; don't think it really makes sense right now 2024-03-21 17:13:44 I should subscribe to oss-security 2024-03-21 17:13:52 I am subscribed to that list 2024-03-21 20:45:41 ikke: Mno, that isn't completely true. You are free to forward the information to a packager if it needs to be done 2024-03-21 20:46:07 but you should have some system in place to securely convey this information outside of the list. Gentoo has an entire packager policy document for it 2024-03-21 21:12:13 sounds like you need everyone to "you need to get these people to agree to these same terms" when becoming a packager then 2024-03-22 08:10:28 fluix: No, they keep it as an optional document 2024-03-22 08:12:12 https://wiki.gentoo.org/wiki/Project:Security/Pre-Release-Disclosure 2024-03-22 08:12:14 for reference 2024-03-22 08:31:18 yes, we just email people asking them to agree when it's required 2024-03-22 08:31:21 and if they say no, so be it 2024-03-22 08:31:29 depending on the bug and the importance of the package 2024-03-22 08:31:35 it might be we handle it ourselves or we just wait 2024-03-22 08:32:16 sam_: <3 2024-03-22 11:42:38 "when required" but doesn't doing that leak the existence of an issue? 2024-03-22 12:11:40 it's done privately to the package maintainer 2024-03-22 12:11:46 nobody's ever disagreed with us doing that 2024-03-22 12:12:34 besides, many projects announce they will make a sec release on X date, just not the contents 2024-03-22 12:12:36 (e.g. curl will do that, but only do the details on linux-distros) 2024-03-22 12:12:46 we also don't usually say which package it is 2024-03-22 12:12:48 just "one you maintain" 2024-03-22 12:21:28 sounds like something we could/should do 2024-03-22 12:21:42 would be nice if we had at least one representative there 2024-03-22 12:23:36 ncopa: but that also means committing to some technical or administrative task 2024-03-22 12:25:36 so preferable not me or you, but someone who would be interested in contributing with that 2024-03-22 12:25:49 i think you and I already have more than enough on our plate 2024-03-22 12:28:44 Remember that you need someone to have some presence in the community as it's vouche based 2024-03-22 13:07:14 Right 2024-03-22 14:18:03 I don't understand. The first sentence of handling embargoed information says: 2024-03-22 14:18:04 > the information you receive through the (linux-)distros lists must not be made public, shared, nor even hinted at anywhere beyond the need-to-know within your distro's team except with the reporter's explicit approval 2024-03-22 14:18:39 how is reaching out to a maintainer that hasn't agreed to the terms beforehand not *hinting* at the fact that there's information about a vulnerability in one of their packages? 2024-03-22 14:22:45 fluix: How is "beyond the need-to-know within your distro's team" unclear? 2024-03-22 14:23:10 well I figure "every packager" is a rather broad definition of "distro's team" 2024-03-22 14:23:12 If you need the package maintainer to actually deal with the patching and report back on the backported patches, how is that not on a "need-to-know basis"? 2024-03-22 14:24:06 yep, that makes sense, but that's why I figure you need them to agree to the terms beforehand 2024-03-22 14:24:33 otherwise you find out about a vuln, ask the maintainer to agree, they decline, and now they have knowledge of a vuln existing with no agreement to confidentiality 2024-03-22 14:24:52 Asking them to sign the document isn't a veryvery weak pre-disclosure 2024-03-22 14:24:55 "deal with the vulns at your discretion~" I guess :3 2024-03-22 14:24:59 s/isn't/is/ 2024-03-22 14:25:18 I agree, but the wording specifically say "nor even hinted at" 2024-03-22 14:25:22 information wants to be free and stuff leaks all the time anyway 2024-03-22 14:25:39 fluix: Asking someone to sign some document is not hinting. Saying "have you heard the containerd/docker/linux thing" is a hint 2024-03-22 14:25:43 kpcyrd: I know, and they do to, hence the 14 day *max* on timelines 2024-03-22 14:26:18 I mean, given this is Gentoo policy and has been a non-issue I'll agree that it seems fine 2024-03-22 14:26:33 but asking someone to sign a document only when a vuln has been found is very much hinting to me 2024-03-22 14:27:09 don't sign documents when doing volunteer labour 2024-03-22 14:27:33 "hey, person that maintains 1 package, would you all of a sudden agree to these terms?" would immediately tell me that "oh, sounds like that 1 package has a vuln" 2024-03-22 14:27:48 there's no actual signatures, just agreements based on trust 2024-03-22 14:27:58 you break said trust, you lose access 2024-03-22 14:27:59 apparently it's fine though 🤷 2024-03-22 14:28:40 fluix: which would only be a problem if you publicly hint at this. 2024-03-22 14:28:54 "keeping this within your organization" is the main practical goal here 2024-03-22 14:29:16 at the point of asking them you've already leaked this to 1 person who hasn't agreed to the terms. they have no obligation to keep it confidential. 2024-03-22 14:29:50 of course, you're right that this is very unlikely to have an issue 2024-03-22 14:30:28 "$software has a bug" is probably too broad to be of any use, if that's enough to make it leak so be it 2024-03-22 14:31:15 ACTION nods 2024-03-22 14:32:51 reading the policy again, "Before you share the information with others within your distro's team based on their need-to-know, you need to get these people to agree to these same terms" can definitely be interpreted as asking them when you need it, and Gentoo's policy is directly linked so you're right this is fine 2024-03-22 14:33:04 if "based on this info I can find the bug without even knowing what kind of bug I'm looking for" it probably doesn't deserve anything but full-disclosure 2024-03-22 14:34:11 (the info being "software has bug") 2024-03-22 14:34:20 I would not be surprised if there's projects/packages people rarely look at from a security perspective and knowing that there's a security vuln in them could definitely make it easy to find quickly 2024-03-22 14:35:03 anyways, Foxboron is right, I missed the Gentoo policy being linked 2024-03-24 13:54:42 what about gnutls in 3.17 and 3.16? 2024-03-24 14:01:07 What about it? 2024-03-24 14:09:11 sorry, that was a bit vague, they're at gnutls 3.7.7 and 3.7.8 2024-03-24 14:09:39 3.8.0, 3.8.3 and 3.8.4 were security releases 2024-03-24 14:10:25 also, tests are failing for whatever reason in !62724 2024-03-26 01:30:09 please review !62896 !62897 !62898 that I got it right 2024-03-26 01:30:44 4 2024-03-26 01:34:55 lgtm based on https://github.com/c-ares/c-ares/compare/cares-1_19_1...cares-1_27_0#diff-f9cdda70294c66a75ea180bec32e6536adb9b0ff078ce3e7e24453d084cca4b9 2024-03-27 21:29:35 https://www.openwall.com/lists/oss-security/2024/03/27/5 2024-03-27 21:39:09 wall on alpine is setgid, but the group is tty 2024-03-29 16:42:13 https://www.openwall.com/lists/oss-security/2024/03/29/4 2024-03-29 16:48:05 okay looks like we are using github tarball for xz, so we're fine 2024-03-29 18:40:19 ikke: we should probably post something on mastodon 2024-03-29 18:43:29 ncopa: ok, so i can say Alpine was not affected 2024-03-29 18:43:33 ? 2024-03-29 18:59:21 From what I understand because the backdoor explicitly checks for libc? 2024-03-29 21:08:05 glibc* 2024-03-29 22:02:56 yeah. alpine should not be affected. 1) we didnt use the backdored source tarballs, 2) the exploit does not work with musl (no ifunc support?) 3) stable branches uses xz 5.4 or older 2024-03-29 22:32:51 ncopa: and it tests specifically for debian / rhel 2024-03-30 00:10:54 the version is vulnerable, but Alpine isn't. there's checks for debian or RPM and it seems likely to require glibc (source: https://www.openwall.com/lists/oss-security/2024/03/29/4) 2024-03-30 00:11:00 wrong channel, sorry 2024-03-30 08:14:05 Ariadne: wasn't the github release tarbal the one that was affected (which you switched away from)? 2024-03-30 09:38:24 do we have the release tarball in distfiles? 2024-03-30 09:40:30 i have it. The generated Makefile in alpine does not have the `am__test = bad-3-corrupt_lzma2.xz` 2024-03-30 09:40:36 I verified that yesterday 2024-03-30 09:40:50 but we need to fix libarchive as well 2024-03-30 09:41:25 https://boehs.org/node/everything-i-know-about-the-xz-backdoor 2024-03-30 09:41:46 https://github.com/libarchive/libarchive/pull/1609#issuecomment-2027583636 2024-03-30 09:56:36 Ariadne: can you please confirm that we never had the affected tarballs? 982d2c6bcbbb579e85bb27c40be84072ca0b1fd9 2024-03-30 10:00:58 ok I can confirm that the generated Makefile did *not* inject the bad-3 payload 2024-03-30 10:01:13 even before 982d2c6bcbbb579e85bb27c40be84072ca0b1fd9 2024-03-30 10:06:08 https://distfiles.alpinelinux.org/distfiles/edge/xz-5.6.1.tar.xz should be the affected tarball 2024-03-30 10:06:28 .gz is the Github autogenerated one we're using now 2024-03-31 06:42:26 ncopa: yes we are fine 2024-03-31 06:48:51 Ariadne: But we _did_ use the affected source before you switched, right? 2024-03-31 06:49:07 yes 2024-03-31 06:49:08 ok 2024-03-31 06:49:14 only on edge though 2024-03-31 06:49:17 indeed 2024-03-31 06:49:41 seems like a sophisticated attack 2024-03-31 06:49:50 indeed 2024-03-31 06:49:52 i’m sure there will be papers written on it 2024-03-31 06:50:03 Even got oss-fuzz to disable a check for it 2024-03-31 06:50:07 thankfully alpine being not gnu/linux seems unaffected 2024-03-31 06:50:16 alpine not being debian helps as well 2024-03-31 06:50:19 since they targeted the backdoor code directly 2024-03-31 06:50:27 well it enabled on any glibc system 2024-03-31 06:50:40 or if debian was present or if rpm_arch was set 2024-03-31 06:50:45 ah ok 2024-03-31 06:50:52 debian/rules* 2024-03-31 08:42:13 Ariadne: thank you. I just want understand so the communication gets correct 2024-03-31 08:43:19 i have packported the fix for the questionable libarchive commit to all stable branches 2024-03-31 08:43:32 https://github.com/libarchive/libarchive/pull/1609#issuecomment-2027583636