-
-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade packaged libxml2 to 2.9.12 #2233
Comments
Because a CVE is patched, I've tagged this as |
Description updated with what I think is a canonical list of CVEs fixed in 2.9.11/2.9.12. Deeper analysis following shortly. |
All information below is sourced from security.archlinux.org, which appears to have the most up-to-date information as of this analysis. Please do not ask me why the libxml2 maintainers don't provide this information for downstream consumers, because I am a little cranky about it at the moment. CVE-2019-20388
Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2020-7595
This has been patched in Nokogiri since v1.10.8 (see #1992). CVE-2020-24977
Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3516
Verified that the fix commit first appears in v2.9.11. This vector does not exist within Nokogiri, which does not ship CVE-2021-3517
Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3518
Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3537
Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4. CVE-2021-3541
Verified that the fix commit first appears in v2.9.11. It seems possible that this issue would be present in programs using Nokogiri < v1.11.4, however Nokogiri's default parse options prevent the attack from succeeding (it is necessary to opt into Attack reproduction and validation of this assertion.#! /usr/bin/env ruby
require 'nokogiri'
xml = <<EOF
<?xml version = "1.0" encoding = "UTF-8"?>
<!DOCTYPE address SYSTEM "foo.dtd" [
<!ENTITY % pe_1 "foo">
<!ENTITY % pe_a "%pe_1;">
<!ENTITY % pe_2 "%pe_1;,%pe_1;,%pe_1;,%pe_1;,%pe_1;,%pe_1;,%pe_1;,%pe_1;,%pe_1;,%pe_1;,%pe_1;">
<!ENTITY % pe_3 "%pe_2;,%pe_2;,%pe_2;,%pe_2;,%pe_2;,%pe_2;,%pe_2;,%pe_2;,%pe_2;,%pe_2;,%pe_2;">
<!ENTITY % pe_4 "%pe_3;,%pe_3;,%pe_3;,%pe_3;,%pe_3;,%pe_3;,%pe_3;,%pe_3;,%pe_3;,%pe_3;,%pe_3;">
<!ENTITY % pe_5 "%pe_4;,%pe_4;,%pe_4;,%pe_4;,%pe_4;,%pe_4;,%pe_4;,%pe_4;,%pe_4;,%pe_4;,%pe_4;">
<!ENTITY % pe_6 "%pe_5;,%pe_5;,%pe_5;,%pe_5;,%pe_5;,%pe_5;,%pe_5;,%pe_5;,%pe_5;,%pe_5;,%pe_5;">
<!ENTITY % pe_7 "%pe_6;,%pe_6;,%pe_6;,%pe_6;,%pe_6;,%pe_6;,%pe_6;,%pe_6;,%pe_6;,%pe_6;,%pe_6;">
<!ENTITY % pe_8 "%pe_7;,%pe_7;,%pe_7;,%pe_7;,%pe_7;,%pe_7;,%pe_7;,%pe_7;,%pe_7;,%pe_7;,%pe_7;">
<!ENTITY % pe_9 "%pe_8;,%pe_8;,%pe_8;,%pe_8;,%pe_8;,%pe_8;,%pe_8;,%pe_8;,%pe_8;,%pe_8;,%pe_8;">
<!ENTITY % pe_10 "%pe_9;,%pe_9;,%pe_9;,%pe_9;,%pe_9;,%pe_9;,%pe_9;,%pe_9;,%pe_9;,%pe_9;,%pe_9;">
]>
<address>
<residence><foo></foo></residence>
</address>
EOF
Nokogiri::XML::Document.parse(xml) # default parse options DO NOT allow the attack to succeed
Nokogiri::XML::Document.parse(xml) { |c| c.dtdload } # this enables the attack <!-- foo.dtd -->
<!ELEMENT address (residence)>
<!ELEMENT residence (%pe_10;)>
<!ELEMENT foo (#PCDATA)> |
Summary of security analysis: The following CVEs are patched in Nokogiri by the upgrade to libxml 2.9.12: Note that two additional CVEs were addressed upstream but are not relevant to this release. CVE-2021-3516 via |
v1.11.4 has been released with libxml2 2.9.12. See GHSA-7rrm-v45f-jp64 for more details on the security advisory created for it. |
The advisory field used by bundler-audit is coming across as blank and is preventing temporary ignores. |
@Esaron I'm not sure what you're referring to; since rubysec/ruby-advisory-db@febf9e8 I am able to run If you're having problems, please take it to the |
Hi @flavorjones, |
I had forgotten I commented here, but the recent comment reminded me. In case it helps anyone, our problem was that we had a typo in our Gemfile and were referencing https://rubygems.org/gems/bundle-audit, which when I tried to update, seemed to not use any version of the real dependency greater than 0.6.X, which only had support for CVE ids. As for why that was happening, I have no clue. It was probably my fault. 0.8.0 has support for GHSA ids, and works fine. |
@kashyapSheladiya There is no single identifier for this because there are several being addressed by libxml2; and I am not going to generate a CVE for Nokogiri to wrap other CVEs. The proper thing to do in this case is to publish an advisory with a unique identifier, which I have done. |
@flavorjones Thanks for comment. |
libxml 2.9.12
libxml 2.9.12 was released today (2021-05-13). Let's plan on upgrading to it for the next release.
dependencies.yml
(note that 2.9.11 was also released on 2021-05-13, but was superseded by 2.9.12 shortly thereafter)
What's in it?
From the release announcement:
Yeah, but what else is in it?
See the full security analysis in the comments, below. Here's the summary ...
The following CVEs are patched in Nokogiri by the upgrade to libxml 2.9.12:
CVE-2019-20388
CVE-2020-24977
CVE-2021-3517
CVE-2021-3518
CVE-2021-3537
CVE-2021-3541
Note that Nokogiri's default parse options prevent this attack from succeeding; but applications using
DTDLOAD
to load external DTDs may be vulnerable.Other notes
Note that two additional CVEs were addressed upstream but are not relevant to this release. CVE-2021-3516 via
xmllint
is not present in Nokogiri, and CVE-2020-7595 has been patched in Nokogiri since v1.10.8 (see #1992).The text was updated successfully, but these errors were encountered: