2024-05-05 20:02:45 <ikke> Container escape in flatpak due to missing "--" to stop getopt processing https://www.openwall.com/lists/oss-security/2024/04/18/5
2024-05-05 20:32:54 <kpcyrd> haha nice
2024-05-09 08:26:23 <omni> https://xenbits.xen.org/xsa/advisory-457.html
2024-05-09 08:26:33 <omni> fix https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=037965402a010898d34f4e35327d22c0a95cd51f
2024-05-11 21:10:01 <ikke> Due to lack of analysis from the NVD / large backlog, secfixes.a.o only shows what we mark as fixed
2024-05-12 14:03:12 <ikke> Alternative vulnerability enrichment source: https://github.com/cisagov/vulnrichment. It's a file per CVE though, so no easy way to get a list of recently updated / modified CVEs from there
2024-05-16 16:23:53 <dne> https://www.openssl.org/news/secadv/20240516.txt (severity: low - no new releases at this time)
2024-05-16 16:24:58 <ikke> "Checking excessively long DSA keys or parameters may be very
2024-05-16 16:25:00 <ikke> slow.
2024-05-16 16:25:02 <ikke> "
2024-05-16 16:26:08 <jvoisin> people are running nodejs stuff, they're used to computers being slow, it's ok
2024-05-16 16:27:40 <ikke> Things running suddenly slow is how the xy exploit was found
2024-05-16 16:37:31 <dne> https://github.com/openssl/openssl/commit/53ea06486d296b890d565fb971b2764fcd826e7e.patch
2024-05-16 19:55:40 <ikke> It's not pretty, but I'm trying to integrate vulnrichment into security.a.o, so that we get indication of vulnerable packages again
2024-05-16 20:37:20 <Ariadne> i am meeting up with some of the CISA team next week, happy to relay any feedback you might have :)
2024-05-16 20:43:51 <ikke> At least having a feed of recent changes would be nice. Regarding the format I cannot say too much yet
2024-05-16 20:44:14 <ikke> But I know you're a fan of json-ld 
2024-05-17 20:27:48 <ikke> Ariadne: An actual schema would also be nice (maybe there is one, but couldn't find it)
2024-05-18 10:24:20 <omni> https://gitlab.gnome.org/GNOME/libxml2/-/commit/8ddc7f13337c9fe7c6b6e616f404b0fffb8a5145
2024-05-18 10:25:38 <omni> may need to be backported to libxml2 2.10.x in 3.17 and, possibly with additional patches, to libxml2 2.9.x in 3.16
2024-05-19 10:50:24 <ikke> Fun, The github CNA does their own thing with the version specification, instead of using the standard version, lessThan/LessThanOrEqual they require you to parse the version field with comma seperated values and comparisson operators.
2024-05-19 13:09:33 <ikke> Ariadne: One specific request: include the language eco system in the CPE, it seems to be generally missing
2024-05-19 13:21:04 <ikke> https://github.com/cisagov/vulnrichment/blob/develop/2024/27xxx/CVE-2024-27351.json lists django-rest-framework as affected, but the specified versions do no match django rest framework, and the description mentions django itself.
2024-05-20 15:56:49 <ncopa> nmeum: I have just sent a fix for CVE-2023-42363 to busybox mailing list
2024-05-20 15:57:49 <ncopa> It is quite possible that CVE-2023-42364 and CVE-2023-42365 are the same problem. I was not able to reproduce the POC from git master, so I think the issue is fixed
2024-05-20 15:57:57 <ncopa> however, I have no idea which commit fixes it
2024-05-20 16:00:32 <nmeum> are these CVEs even security critical? the stuff I looked at recently could only be triggered when executing attacker-controlled awk
2024-05-20 16:01:05 <nmeum> also the CVE assignment does not seem to be coordinated with busybox upstream at all
2024-05-20 16:04:04 <nmeum> in general, busybox upstream is sadly not really active right now. there is a lot of stuff on the mailinglist that just doesn't get review rn
2024-05-20 16:08:35 <ncopa> I dont know if they can be exploited but they seem to be valid use-after-free
2024-05-20 16:12:02 <nmeum> right, I am all for fixing the underlying bug
2024-05-20 16:13:09 <nmeum> I am just not sure if I would consider this a security issue (because the attack vector would be that someone can pass custom awk code to the parser)
2024-05-20 17:32:01 <ncopa> i found the commit. I think its easier to just fix it than start arguing with the "security" scanner people
2024-05-20 17:49:51 <ncopa> nmeum: ok that I just merge this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66280
2024-05-20 17:50:01 <ncopa> then I think I have all I need for tagging 3.19.2
2024-05-20 17:57:51 <ncopa> i merged it. sorry for not waiting.
2024-05-20 18:49:43 <omni> I haven't looked too much at any of these https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?label_name%5B%5D=tag%3Asecurity
2024-05-20 18:49:50 <omni> (besides podman)
2024-05-20 19:00:32 <ncopa> i want 3.20 release out tomorrow
2024-05-20 19:00:47 <ncopa> and im prepared to delete anything that comes in the way
2024-05-20 19:00:57 <ncopa> git rm -r -r -r -r -r -r
2024-05-20 19:01:02 <ncopa> -r -r -rrrrrrrr
2024-05-20 19:01:57 <ikke> juhoh
2024-05-20 19:02:00 <ncopa> wrong chan
2024-05-20 19:31:39 <nmeum> ncopa: sorry, was afk. it's fine that you merge it :)
2024-05-20 19:33:12 <nmeum> would you mind backporting it to the -stable branches as well? otherwise the security scanner people will probably show up again
2024-05-20 19:39:13 <ncopa> done. thanks! 45431cb95049bc3f58861526e96dc5be198041ef
2024-05-20 20:14:54 <nmeum> thank you for taking care of this!
2024-05-20 20:15:38 <ncopa> no worries
2024-05-28 15:42:54 <dne> https://www.openssl.org/news/secadv/20240528.txt - "Use After Free with SSL_free_buffers (CVE-2024-4741)", low severity
2024-05-28 19:33:31 <ikke> nmeum: is it correct some bb vulnerabilities are still unfixed, or is there something with those CVEs? https://security.alpinelinux.org/srcpkg/busybox
2024-05-28 19:40:51 <nmeum> some of them are currently unfixed, see 4d9b7d8e9f37907d4ecf8e01e21854e95937e4a8
2024-05-28 19:41:42 <nmeum> I would also consider these bogus CVEs
2024-05-28 19:42:13 <nmeum> if you can pass abitrary input to the awk parser than you already have remote code execution
2024-05-28 19:44:44 <nmeum> I also think that there are still no upstream fixes for these
2024-05-28 19:44:48 <nmeum> we could just NAK them on our end
2024-05-28 19:49:01 <ikke> yeah, was thinking about that
2024-05-28 19:49:47 <ikke> https://gitlab.alpinelinux.org/alpine/security/security-rejections/-/blob/master/main.yaml
2024-05-28 20:00:58 <fossdd> CVE-2023-48052 is also disputed by upstream: https://github.com/httpie/cli/issues/1549#issuecomment-1876683189
2024-05-28 20:01:02 <fossdd> should i also add it to the repo?
2024-05-28 20:26:53 <ikke> Yeah, I suppose so
2024-05-28 20:34:03 <fossdd> ack
2024-05-28 20:44:38 <ikke> omni: do we still need to address https://security.alpinelinux.org/vuln/CVE-2023-34319 for xen? (XSA-432)
2024-05-28 20:50:33 <omni> I don't think so
2024-05-28 20:50:47 <omni> XSA-432 is (or was) in linux, not xen
2024-05-30 17:55:33 <nmeum> so…how do we proceed with these busybox CVEs
2024-05-30 17:56:05 <ikke> Do we officially reject them?
2024-05-30 17:56:18 <ikke> That will probably not prevent any scanners from complaining though
2024-05-30 17:56:22 <nmeum> yea, I think that would be one thing we could do
2024-05-30 17:56:27 <nmeum> I think it should prevent the scanners from complaining
2024-05-30 17:56:30 <ikke> :D
2024-05-30 17:56:47 <nmeum> I received yet another email from some devops asking me about the unfixed cves on security.alpinelinux.org
2024-05-30 17:56:58 <ikke> yeah, it would fix that
2024-05-30 17:57:01 <nmeum> I assume the scanners also just collect the CVE data
2024-05-30 17:57:22 <nmeum> how would they otherwise recognize busybox as vulnerable to a specific CVE? i don't think that they actually analyze the binary or do they?
2024-05-30 17:57:43 <nmeum> ncopa: given that you worked on the CVE fixes already: what do you think how we should proceed with these unfixed CVEs?
2024-05-30 17:58:08 <ikke> ncopa is on holiday
2024-05-30 17:58:38 <nmeum> ah, sorry wasn't aware
2024-05-30 17:58:44 <nmeum> I was just returning from my mini holidy :)
2024-05-30 18:03:34 <ikke> docker even flags CVE-2023-42363, which we indicated was fixed
2024-05-30 18:03:49 <ikke> so either they have not updated again, or they are only looking at the version
2024-05-30 18:05:03 <nmeum> how do other distros / docker images handle this?
2024-05-30 18:05:25 <nmeum> there is no upstream patch, so they can't really "fix" those CVEs either
2024-05-30 18:06:02 <ikke> nope
2024-05-30 18:06:28 <nmeum> so are they also flagged as vulnerable by the security scanners and docker hub?
2024-05-30 18:06:45 <nmeum> https://security-tracker.debian.org/tracker/CVE-2023-42364
2024-05-30 18:06:49 <nmeum> debian has definitly not fixed them yet
2024-05-30 18:07:29 <ikke> https://hub.docker.com/_/busybox/tags apparently not
2024-05-30 18:07:57 <ikke> https://hub.docker.com/layers/library/busybox/1.36.1/images/sha256-50aa4698fa6262977cff89181b2664b99d8a56dbca847bf62f2ef04854597cf8?context=explore
2024-05-30 18:18:25 <nmeum> so why is that?
2024-05-30 18:18:41 <nmeum> my understanding of this entire docker ecosystem is really limited
2024-05-30 18:19:45 <ikke> https://docs.docker.com/docker-hub/vulnerability-scanning/
2024-05-30 18:22:22 <ikke> I'm not sure if there is more information about it
2024-05-30 18:23:18 <ikke> https://github.com/docker/cli/issues/4097 implies that they are looking at secdb
2024-05-30 18:23:44 <nmeum> so that would mean that we could NAK them at our end
2024-05-30 18:27:06 <ikke> THe only way would be to add to to version 0, but that kind of implies that the bug is not present
2024-05-30 18:30:46 <nmeum> well…
2024-05-31 02:35:09 <Ariadne> 10:56 AM <nmeum> I received yet another email from some devops asking me about the unfixed cves on security.alpinelinux.org
2024-05-31 02:35:33 <Ariadne> should we add a notice on security.alpinelinux.org advising general public to not contact maintainers
2024-05-31 02:36:34 <Ariadne> ikke: debian has a "we don't plan to fix this" state that they put in their secdb
2024-05-31 02:36:44 <Ariadne> which causes scanners to silence
2024-05-31 04:13:18 <ikke> Ariadne: what does that state look like?
2024-05-31 19:10:54 <Ariadne> ikke: they have two states, "postponed" and "ignored"
2024-05-31 20:24:47 <ikke> Ariadne: but we do not really have a place to put the status of a CVE, we can only marked per version what CVEs are fixed. So we need to come up with a new format and convince these scanners to use it
2024-05-31 20:25:40 <Ariadne> my suggestion would be to embrace OpenVEX for that
2024-05-31 20:26:45 <ikke> right, using something existing is better
2024-05-31 20:50:59 <ikke> "author identity SHOULD be cryptographically associated with the signature of the VEX document or other exchange mechanism."
2024-05-31 20:51:09 <ikke> hmm
2024-05-31 20:52:06 <ikke> But that's also the only place that's mentioned