Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Config] Disable XML external entity loading for all versions of libxml#38564

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
fabianbadoi wants to merge1 commit intosymfony:3.4fromfabianbadoi:xxe-still-alive
Closed

[Config] Disable XML external entity loading for all versions of libxml#38564

fabianbadoi wants to merge1 commit intosymfony:3.4fromfabianbadoi:xxe-still-alive

Conversation

@fabianbadoi
Copy link

@fabianbadoifabianbadoi commentedOct 14, 2020
edited
Loading

QA
Branch?3.4
Bug fix?yes
New feature?no
Deprecations?no
Ticketsn/a
LicenseMIT
Doc PRn/a

The libxml_disable_entity_loader() function was deprecated in PHP 8.0 and will trigger a deprecation notice going forward. However,external entity loading is still enabled.

The PR where the function was deprecated,php/php-src#5867, claims that XXE loading is diabled by default since libxml 2.9.0.

However, this was not the case in at least the following systems:

  • the php:7.4-fpm-alpine docker image
  • the php:8.0-rc-cli-alpine
  • the default php-7.4 package from the Ubuntu 20.04 package repositories

All of these installations report LIBXML_VERSION > 20900 and are still vulnerable to XXE attacks unless libxml_disable_entity_loader() is used.

Calling libxml_disable_entity_loader() before Kernel::hande() fails now with a XmlParsingException due to XmlFileLoader not temporarily enabling XXE loading. The external entity in question was src/Symfony/[...]/services-1.0.xsd which was being used to validate src/Symfony/[...]/config/web.xml.

Calling libxml_disable_entity_loader() is recommended by OWASP, and is a very good security practice to globally prevent XXE attacks:
https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#php

You can modify the xxe_schema.xsd file introduced in this commit to point to ahttps://webhook.site/ URL instead of file:///dev/null. This will demonstrate that these XXE calls will even try to make network requests.

I don't like where I placed the test I added. I chose XmlFileLoaderTest because that XmlFileLoader was causing Symfony to crash in my case. I think it's a good test to have, though, as it will prevent regressions on this. Perhasp you can suggest a better place.

@stof
Copy link
Member

The PR where the function was deprecated,php/php-src#5867, claims that XXE loading is diabled by default since libxml 2.9.0.

However, this was not the case in at least the following systems:

* the php:7.4-fpm-alpine docker image* the php:8.0-rc-cli-alpine* the default php-7.4 package from the Ubuntu 20.04 package repositories

All of these installations report LIBXML_VERSION > 20900 and are still vulnerable to XXE attacks unless libxml_disable_entity_loader() is used.

this should be reported as a bug in the PHP issue tracker IMO, as that might invalidate the decision to deprecate the function.

dunglas reacted with thumbs up emoji

@fabianbadoi
Copy link
Author

I tried reporting it this morning, the bug tracker was down :(

@fabianbadoi
Copy link
Author

We have a bug report:https://bugs.php.net/bug.php?id=80235

The libxml_disable_entity_loader() function was deprecated in PHP 8.0and will trigger a deprecation notice going forward. However, externalentity loading is still *enabled*.The PR where the function was deprecated,php/php-src#5867,claims that XXE loading is diabled by default since libxml 2.9.0.However, this was not the case in at least the following systems:- the php:7.4-fpm-alpine docker image- the php:8.0-rc-cli-alpine- the default php-7.4 package from the Ubuntu 20.04 package repositoriesAll of these installations report LIBXML_VERSION > 20900 and are stillvulnerable to XXE attacks unless libxml_disable_entity_loader() is used.Calling libxml_disable_entity_loader() before Kernel::hande() fails nowwith a XmlParsingException due to XmlFileLoader not temporarily enablingXXE loading. The external entity in question was src/Symfony/[...]/services-1.0.xsdwhich was being used to validate src/Symfony/[...]/config/web.xml.Calling libxml_disable_entity_loader() is recommended by OWASP, and isa very good security practice to globally prevent XXE attacks:https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#phpYou can modify the xxe_schema.xsd file introduced in this commit topoint to ahttps://webhook.site/ URL instead of file:///dev/null. Thiswill demonstrate that these XXE calls will even try to make networkrequests.
@fabianbadoi
Copy link
Author

fabianbadoi commentedOct 14, 2020
edited
Loading

I'd like some guidance on this PR:

  1. Travis fails on PHP 5.5 because phpunit is too old there, I can't figure out how to test this myself
  2. Appveyor fails for the same reason
  3. Travis also fails on PHP nigly because of legacy deprecation related to exactly this issue. I'm not sure what to do about this.
  4. fabbot's suggestion changes an error meesage:
+++ src/Symfony/Component/Serializer/Encoder/XmlEncoder.php     2020-10-14 11:56:38.534401092 +0000@@ -431,7 +431,7 @@             return $this->appendNode($parentNode, $data, 'data');         } -        throw new NotEncodableValueException('An unexpected value could not be serialized: '.(!\is_resource($data) ? var_export($data, true) : sprintf('%s resource', get_resource_type($data))));+        throw new NotEncodableValueException('An unexpected value could not be serialized: '.(!\is_resource($data) ? var_export($data, true) : sprintf('"%s" resource', get_resource_type($data))));     }      /**

I have nothing against chaning it here, idk if you would accept unrelated changes.

@stof
Copy link
Member

3\. Travis also fails on PHP nigly because of legacy deprecation related to exactly this issue. I'm not sure what to do about this.

well, that's precisely why I asked to report an issue to PHP. Symfony has a policy of not using deprecated APIs. So if using the deprecated API of PHP cannot be avoided, there is an issue with the fact of deprecating.

@stof
Copy link
Member

We have a bug report:https://bugs.php.net/bug.php?id=80235

this link is private

@fabianbadoi
Copy link
Author

I also think we should wait to see what the PHP devs do with this, since they might not consider it serious enough to address. Installations are still safe from the traditional XXE attacks that reads local files.

@fabianbadoi
Copy link
Author

We have a bug report:https://bugs.php.net/bug.php?id=80235

this link is private

I think they set all tickets related to security to private by default

@nicolas-grekasnicolas-grekas added this to the3.4 milestoneOct 14, 2020
@nicolas-grekas
Copy link
Member

I rebased the PR for branch 3.4 but there are some failure to fix, could you please have a look?

@nicolas-grekasnicolas-grekas changed the titleDisable XML external entity loading for all versions of libxml[Config] Disable XML external entity loading for all versions of libxmlOct 14, 2020
@nicolas-grekas
Copy link
Member

(nvm the rebase for 3.4, that's on another PR)

@jderusse
Copy link
Member

The PHP bug has been closed. Callinglibxml_disable_entity_loader is not required and trigger deprecation on PHP 8. Shall we close this PR?

derrabus reacted with thumbs up emoji

@fabianbadoi
Copy link
Author

The PHP bug has been closed. Callinglibxml_disable_entity_loader is not required and trigger deprecation on PHP 8. Shall we close this PR?

Yes, closing.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@dunglasdunglasAwaiting requested review from dunglasdunglas is a code owner

Assignees

No one assigned

Projects

None yet

Milestone

3.4

Development

Successfully merging this pull request may close these issues.

6 participants

@fabianbadoi@stof@nicolas-grekas@jderusse@xabbuh@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp