From jmm at inutil.org Fri Jun 28 13:23:46 2024 From: jmm at inutil.org (Moritz =?UTF-8?Q?M=C3=BChlenhoff?=) Date: Fri, 28 Jun 2024 14:23:46 +0200 Subject: Bug#1074429: xml-security-c: CVE-2024-34580 Message-ID: Source: xml-security-c X-Debbugs-CC: team at security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for xml-security-c. CVE-2024-34580[0]: | Apache XML Security for C++ through 2.0.4 implements the XML | Signature Syntax and Processing (XMLDsig) specification without | protection against an SSRF payload in a KeyInfo element. NOTE: the | supplier disputes this CVE Record on the grounds that they are | implementing the specification "correctly" and are not "at fault." https://cloud.google.com/blog/topics/threat-intelligence/apache-library-allows-server-side-request-forgery https://www.sonatype.com/blog/the-exploited-ivanti-connect-ssrf-vulnerability-stems-from-xmltooling-oss-library https://github.com/zmanion/Vulnerabilities/blob/main/CVE-2024-21893.md Not sure what to make out of this? It seems the use of xml-security-sec within Shibboleth continues to be supported, but otherwise the library is deemed deprecated, so maybe this should at least be made explicit in the package description? ` If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2024-34580 https://www.cve.org/CVERecord?id=CVE-2024-34580 Please adjust the affected versions in the BTS as needed. From owner at bugs.debian.org Fri Jun 28 21:00:10 2024 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 28 Jun 2024 20:00:10 +0000 Subject: Processed: tagging 1074431, tagging 1074430, tagging 1074429, tagging 1074426 ..., tagging 1074425 ... References: <1719604604-97-bts-carnil@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 1074431 + upstream Bug #1074431 [src:arm-trusted-firmware] arm-trusted-firmware: CVE-2024-6287 CVE-2024-6285 Added tag(s) upstream. > tags 1074430 + upstream Bug #1074430 [src:adminer] adminer: CVE-2023-45196 CVE-2023-45195 Added tag(s) upstream. > tags 1074429 + upstream Bug #1074429 [src:xml-security-c] xml-security-c: CVE-2024-34580 Added tag(s) upstream. > tags 1074426 + upstream Bug #1074426 [src:golang-golang-x-image] golang-golang-x-image: CVE-2024-24792 Ignoring request to alter tags of bug #1074426 to the same tags previously set > forwarded 1074426 https://github.com/golang/go/issues/67624 Bug #1074426 [src:golang-golang-x-image] golang-golang-x-image: CVE-2024-24792 Ignoring request to change the forwarded-to-address of bug#1074426 to the same value > tags 1074425 + upstream Bug #1074425 [src:openvpn-auth-ldap] openvpn-auth-ldap: CVE-2024-28820 Ignoring request to alter tags of bug #1074425 to the same tags previously set > forwarded 1074425 https://github.com/threerings/openvpn-auth-ldap/pull/92 Bug #1074425 [src:openvpn-auth-ldap] openvpn-auth-ldap: CVE-2024-28820 Ignoring request to change the forwarded-to-address of bug#1074425 to the same value > tags 1074414 + upstream Bug #1074414 [src:gpac] gpac: CVE-2024-6061 CVE-2024-6062 CVE-2024-6063 CVE-2024-6064 Added tag(s) upstream. > tags 1074415 + upstream Bug #1074415 [src:slic3r-prusa] slic3r-prusa: CVE-2020-28594 CVE-2020-28595 CVE-2020-28596 CVE-2020-28598 Added tag(s) upstream. > tags 1074416 + upstream Bug #1074416 [src:libde265] libde265: CVE-2024-38949 CVE-2024-38950 Added tag(s) upstream. > forwarded 1074416 https://github.com/strukturag/libde265/issues/460 Bug #1074416 [src:libde265] libde265: CVE-2024-38949 CVE-2024-38950 Set Bug forwarded-to-address to 'https://github.com/strukturag/libde265/issues/460'. > tags 1074417 + upstream Bug #1074417 [src:zziplib] zziplib: CVE-2024-39133 Ignoring request to alter tags of bug #1074417 to the same tags previously set > forwarded 1074417 https://github.com/gdraheim/zziplib/issues/164 Bug #1074417 [src:zziplib] zziplib: CVE-2024-39133 Ignoring request to change the forwarded-to-address of bug#1074417 to the same value > tags 1074418 + upstream Bug #1074418 [src:libmodbus] libmodbus: CVE-2023-26793 Added tag(s) upstream. > forwarded 1074418 https://github.com/stephane/libmodbus/issues/683 Bug #1074418 [src:libmodbus] libmodbus: CVE-2023-26793 Set Bug forwarded-to-address to 'https://github.com/stephane/libmodbus/issues/683'. > tags 1074419 + upstream Bug #1074419 [src:bluez] bluez: CVE-2023-51596 Added tag(s) upstream. > tags 1074421 + upstream Bug #1074421 [src:grpc] grpc: CVE-2023-44487 Added tag(s) upstream. > tags 1074422 + upstream Bug #1074422 [src:libmodbus] libmodbus: CVE-2024-36843 CVE-2024-36844 CVE-2024-36845 Added tag(s) upstream. > tags 1074423 + upstream Bug #1074423 [src:nltk] nltk: CVE-2024-39705 Ignoring request to alter tags of bug #1074423 to the same tags previously set > tags 1074424 + upstream Bug #1074424 [src:zziplib] zziplib: CVE-2024-39134 Ignoring request to alter tags of bug #1074424 to the same tags previously set > forwarded 1074424 https://github.com/gdraheim/zziplib/issues/165 Bug #1074424 [src:zziplib] zziplib: CVE-2024-39134 Ignoring request to change the forwarded-to-address of bug#1074424 to the same value > thanks Stopping processing here. Please contact me if you need assistance. -- 1074414: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074414 1074415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074415 1074416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074416 1074417: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074417 1074418: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074418 1074419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074419 1074421: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074421 1074422: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074422 1074423: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074423 1074424: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074424 1074425: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074425 1074426: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074426 1074429: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074429 1074430: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074430 1074431: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074431 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From cantor.2 at osu.edu Fri Jun 28 21:27:34 2024 From: cantor.2 at osu.edu (Cantor, Scott) Date: Fri, 28 Jun 2024 20:27:34 +0000 Subject: Bug#1074429: xml-security-c: CVE-2024-34580 In-Reply-To: References: Message-ID: TL;DR, This is not a vulnerability, it's a default that people don't like that required a minor update to change, and that wasn't going to happen. The code has been formally retired at Apache and forked for the Shibboleth Project's use, and there will be some form of official indication of that at some point later this summer. > The following vulnerability was published for xml-security-c. It is not a vulnerability, and should never have been published as one. It's a default that people don't like. I don't like a lot of defaults in lots of software but that doesn't make them vulnerabilities. > NOTE: the supplier disputes this CVE Record on the grounds > that they are | implementing the specification "correctly" > and are not "at fault." Yes, because those are the facts. The scare quotes are unnecessary, as is the entire CVE. > Not sure what to make out of this? It seems the use of xml >-security-sec within Shibboleth continues to be supported, > but otherwise the library is deemed deprecated, so maybe > this should at least be made explicit in the package > description? The mess around this invalid CVE led to my finally putting my foot down and demanding that we either retire the code or somebody else show up to help maintain it. Nobody did, so the Apache project retired that version of the library. The Shbboleth Project has forked the codebase for its own use since we were the only maintainers. It is effectively in the same state in terms of support as the xmltooling and opensaml libraries: they're for the Shibboleth SP's use and any other uses are not relevant to the maintainers of the code and bugs or requests that do not impact the SP will not be prioritized. Our needs are far less general than the original library's, so taking it over allows us to potentially do new releases that strip out a lot of code and attack surface, and to make different decisions in regard to API compatibility than could be made when it was a general-purpose tool. The code was only recently converted to git and we are still in the process of getting it in place and deciding what to do with it. I have no idea how the retirement is going to be managed from the Apache side. Something needs to be done with the wiki, etc., but none of that has been determined. Once the code is fully in place, I was planning to drop a note to the Debian packaging list for Shibboleth to note the change, as if the packaging continues, it should likely pull from our copy rather than the old one. I don't have an opinion really about what to do with the package. I'm not about to rename it because that's more work for me, not less. I could understand the feeling on the Debian side being different about the need to delineate the transition and retire the original package since it's unmaintained. -- Scott From cantor.2 at osu.edu Fri Jun 28 21:27:34 2024 From: cantor.2 at osu.edu (Cantor, Scott) Date: Fri, 28 Jun 2024 20:27:34 +0000 Subject: Bug#1074429: xml-security-c: CVE-2024-34580 In-Reply-To: References: Message-ID: TL;DR, This is not a vulnerability, it's a default that people don't like that required a minor update to change, and that wasn't going to happen. The code has been formally retired at Apache and forked for the Shibboleth Project's use, and there will be some form of official indication of that at some point later this summer. > The following vulnerability was published for xml-security-c. It is not a vulnerability, and should never have been published as one. It's a default that people don't like. I don't like a lot of defaults in lots of software but that doesn't make them vulnerabilities. > NOTE: the supplier disputes this CVE Record on the grounds > that they are | implementing the specification "correctly" > and are not "at fault." Yes, because those are the facts. The scare quotes are unnecessary, as is the entire CVE. > Not sure what to make out of this? It seems the use of xml >-security-sec within Shibboleth continues to be supported, > but otherwise the library is deemed deprecated, so maybe > this should at least be made explicit in the package > description? The mess around this invalid CVE led to my finally putting my foot down and demanding that we either retire the code or somebody else show up to help maintain it. Nobody did, so the Apache project retired that version of the library. The Shbboleth Project has forked the codebase for its own use since we were the only maintainers. It is effectively in the same state in terms of support as the xmltooling and opensaml libraries: they're for the Shibboleth SP's use and any other uses are not relevant to the maintainers of the code and bugs or requests that do not impact the SP will not be prioritized. Our needs are far less general than the original library's, so taking it over allows us to potentially do new releases that strip out a lot of code and attack surface, and to make different decisions in regard to API compatibility than could be made when it was a general-purpose tool. The code was only recently converted to git and we are still in the process of getting it in place and deciding what to do with it. I have no idea how the retirement is going to be managed from the Apache side. Something needs to be done with the wiki, etc., but none of that has been determined. Once the code is fully in place, I was planning to drop a note to the Debian packaging list for Shibboleth to note the change, as if the packaging continues, it should likely pull from our copy rather than the old one. I don't have an opinion really about what to do with the package. I'm not about to rename it because that's more work for me, not less. I could understand the feeling on the Debian side being different about the need to delineate the transition and retire the original package since it's unmaintained. -- Scott