=== chris14_ is now known as chris14 [02:31] i think CVE-2023-39361 needs some revision, reflecting info gleaned by Debian from upstream data - see https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2023-November/019622.html and https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2023-November/019623.html which is my follow up with amurray and the details I gleaned during a dive attempting to find a patch for this (as well as information about what versions are actually [02:31] affected) [02:31] -ubottu:#ubuntu-security- Cacti is an open source operational monitoring and fault management framework. Affected versions are subject to a SQL injection discovered in graph_view.php. Since guest users can access graph_view.php without authentication by default, if guest users are being utilized in an enabled state, there could be the potential for significant damage. Attackers may exploit ... [02:31] also see https://github.com/Cacti/cacti/issues/5523 [02:31] -ubottu:#ubuntu-security- Issue 5523 in Cacti/cacti "Please clarify status of CVE-2023–37543" [Closed] [02:33] teward: I already triaged it and pushed it to the main repo just before hitting send (https://git.launchpad.net/ubuntu-cve-tracker/commit/?id=4396df8baa2542dcf9d28805b6f4ffc396e5e02c) - but the website takes 10ish minutes to update [02:33] -ubottu:#ubuntu-security- Commit 4396df8 in ubuntu-cve-tracker "active/CVE-2023-39361: triage prompted by request on ubuntu-devel-discuss HEAD master" [02:33] try refreshing and see if it looks better [02:33] amurray: ack. i was more just following up on my reply is all ;) [02:34] amurray: ye the site is slow to the point of [REDACTED] [CENSORED] [CENSORED] [REDACTED] on updates, i just wanted to make a note of what my research found and additional relevant links for adding :) [02:34] yay for community developer involvements ;P [02:35] (I was checking 'cause $DAYJOB uses a Cacti server and i was supposed to see if we were impacted anyways) [02:35] (we're not, but yay for coincidental research) [02:35] also cacti has a heap of CVEs open and as you say, it is definitely not clear which commits fix which issues - but given how many are unpatched in Ubuntu I would avoid using our package for now if you have it deployed on the internet [02:36] yeah we're not that stupid :p [02:36] apologies, I didn't mean to imply you were - was more a general comment ;) [02:36] IT Security Rule #1 for teward: I'm a paranoid SOB. I NEVER open internal syslog, etc. reporting tooling to the Internet. VPN only :) [02:36] amurray: yup [02:37] in fact I've patched so many holes in the network that pentesters have even said "Holy... this is super secure, like even a nationstate would have problems breaching this..." [02:37] xD [02:37] amurray: to be fair, Cacti and other systems also have other CVEs by dependencies too, so they're not just Cacti CVEs. [16:53] teward: don't trust those pentesters, they're nation state agents! :P [20:55] UnivrslSuprBox: lol, I've worked with the workplace's chosen pentesters for > 10 years even outside $DAYJOB so i know them well, and can trust them [20:58] Hey, Security Team! I have a general question. This came up as part of an SRU ticket that i'm on because of -sponsors subscription, but jtreg7 has a component referenced in this thread (https://bugs.launchpad.net/ubuntu/+source/openjdk-21/+bug/2036873) where it validates CA certificates in the environment against its own list of "expected certificates". Couldn't that introduce its own security concerns as part of a build test? [20:58] -ubottu:#ubuntu-security- Launchpad bug 2036873 in openjdk-21 (Ubuntu Lunar) "[SRU] Please provide openjdk-21 for focal, jammy and lunar" [Undecided, Confirmed] [20:58] because it would theoretically mean that if ca-certificates drops a certificate from trusted (read: TrustCor like situations again), the package is too fragile. [20:58] so wondering if there's a security impact of that test existing as part of build-testing [21:11] why would Java care about what CAs are trusted... [21:58] JanC: I think the underlying program that's failing - jtreg7 - is depending on it, and is why the SRU exists because the 'fix' needed to be in openjdk [21:59] but i agree it shouldn't care it should be agnostic and trust whatever the system CA store says is trusted by blind default [21:59] like *most* programs do [22:03] if an application/package explicitly needs a specific CA it could provide it as a "private" resource [22:19] it's not uncommon for test suites to assume that the list of CA certificates come from the package, and not the system like we have on Ubuntu...jtreg is the openjdk test suite, it's just not expecting to use system certs [22:19] I assume the whole point of jtreg checking certs is to make sure openjdk actually shipped the right ones [22:20] the tests simply need to be fixed or disabled [22:24] so they need to update that test every time a CA issues a new CA cert and asks for it to be included? I'm not sure I understand the purpose... [22:25] (or asks to retire a CA cert) [22:28] oh, apparently they also have tests for each certificate [22:28] to make sure it works & is not corrupted or so? [22:29] I dunno, but that's what test suites are for :) [22:29] I'd have to look at what exactly it's testing for [22:32] https://github.com/openjdk/jdk/blob/12fce4b715f2c8b0091f5c229fcc3e3707290489/test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#L445 [22:33] not for all, it seems [22:34] weird https://github.com/openjdk/jdk/commit/e6f46a43268808d0cbbb3bb93c73aa8e4cbfad83 [22:34] -ubottu:#ubuntu-security- Commit e6f46a4 in openjdk/jdk "8317374: Add Let's Encrypt ISRG Root X2" [22:36] why weird? [23:52] every time they modify a ca cert, they update the file checksum in the tests and add the cert to the tests [23:53] *shrug*