Skip to content
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

Help protect against billion laughs attack (for when XML entities need to be supported) #34

Closed
hartwork opened this issue May 31, 2017 · 9 comments · Fixed by #466
Closed

Comments

@hartwork
Copy link
Member

hartwork commented May 31, 2017

(The latest version of) https://github.com/tiran/expat_cvs/commits/xmlbomb should be assessed for integratability.

Branch defusedexpat-2.1.0 in here has his patch (with path fixes to match our file layout) for more convenient inspection.

@andy9a9
Copy link

andy9a9 commented Jul 30, 2018

Hello everyone,
I would like to ask, what is the current status of this issue? Is it possible to create new release with your proposal patches?

Thanks

@hartwork
Copy link
Member Author

For a quick reply: it's not something we could just apply and merge without risk of breaking things and without additional resources.

@hartwork
Copy link
Member Author

I should mention that this new feature should have dedicated tests and there are none, yet.

@kwaclaw
Copy link
Contributor

kwaclaw commented Jul 31, 2018 via email

@hartwork
Copy link
Member Author

Isn't the usual mitigation to disable DTD processing?

Could it be that you're referring to disabling support for external entities here?
I don't think we want to disable support for XML entities by default. To me this ticket is about getting all users safe from DoS by default while keeping support for XML entities intact. I'll adjust the ticket title to make that more clear in a second.

@hartwork hartwork changed the title Help protect against billion laughs attack Help protect against billion laughs attack (for when XML entities need to be supported) Jul 31, 2018
@kwaclaw
Copy link
Contributor

kwaclaw commented Aug 3, 2018

Dont you need DTD processing turned on to expand entities? I remember from way back that for Expat the simple remedy for the million XXX attack was to disable DTD processing. See https://blog.didierstevens.com/2008/09/23/dismantling-an-xml-bomb/.

@hartwork
Copy link
Member Author

hartwork commented Aug 3, 2018

I believe you do, yes. Turning DTD off is simple but not nice.

@kwaclaw
Copy link
Contributor

kwaclaw commented Aug 3, 2018

I also remember that at one time we had discussed to rework the memory allocation functions so that we could track the memory allocated for the parser instance. That would have allowed us to simply stop when a specific threshold was exceeded.

@hartwork
Copy link
Member Author

hartwork commented Aug 3, 2018

I think we have discussed that before and I remember just tracking memory usage was too simple in some regard. Would need to look it up.

tiran added a commit to tiran/libexpat that referenced this issue Sep 19, 2018
libexpat is vulnerable to billion laughs and quadratic blowup DoS attacks.
processInternalEntity() function now limits entity expansion and
nesting in three ways:

* Entity nesting is limited to three levels of recursion.
* Total length of an entity is limited to 1023 bytes.
* The ratio of entity expansion to processed bytes cannot exceed 1:10.

The mitigation is enabled by default and can be disabled with
XML_SetOptions(parser, XML_OPTION_HUGE_ENTITES).

The xmlwf command has a new option -H to enable huge entities.

The new entity expansion limits cause one test to fail. The XML test
file tests/xmlconf/xmltest/valid/ext-sa/012.xml has five levels of
entity expansion.

Fixes: libexpat#34
Fixes: libexpat#46
Signed-off-by: Christian Heimes <christian@python.org>
tiran added a commit to tiran/libexpat that referenced this issue Sep 19, 2018
libexpat is vulnerable to billion laughs and quadratic blowup DoS attacks.
processInternalEntity() function now limits entity expansion and
nesting in three ways:

* Entity nesting is limited to three levels of recursion.
* Total length of an entity is limited to 1023 bytes.
* The ratio of entity expansion to processed bytes cannot exceed 1:10.

The mitigation is enabled by default and can be disabled with
XML_SetOptions(parser, XML_OPTION_HUGE_ENTITES).

The xmlwf command has a new option -H to enable huge entities.

The new entity expansion limits cause one test to fail. The XML test
file tests/xmlconf/xmltest/valid/ext-sa/012.xml has five levels of
entity expansion.

Fixes: libexpat#34
Fixes: libexpat#46
Signed-off-by: Christian Heimes <christian@python.org>
tiran added a commit to tiran/libexpat that referenced this issue Sep 19, 2018
libexpat is vulnerable to billion laughs and quadratic blowup DoS attacks.
processInternalEntity() function now limits entity expansion and
nesting in three ways:

* Entity nesting is limited to three levels of recursion.
* Total length of an entity is limited to 1023 bytes.
* The ratio of entity expansion to processed bytes cannot exceed 1:10.

The mitigation is enabled by default and can be disabled with
XML_SetOptions(parser, XML_OPTION_HUGE_ENTITES).

The xmlwf command has a new option -H to enable huge entities.

The new entity expansion limits cause one test to fail. The XML test
file tests/xmlconf/xmltest/valid/ext-sa/012.xml has five levels of
entity expansion.

Fixes: libexpat#34
Fixes: libexpat#46
Signed-off-by: Christian Heimes <christian@python.org>
tiran added a commit to tiran/libexpat that referenced this issue Sep 19, 2018
libexpat is vulnerable to billion laughs and quadratic blowup DoS attacks.
processInternalEntity() function now limits entity expansion and
nesting in three ways:

* Entity nesting is limited to three levels of recursion.
* Total length of an entity is limited to 1023 bytes.
* The ratio of entity expansion to processed bytes cannot exceed 1:10.

The mitigation is enabled by default and can be disabled with
XML_SetOptions(parser, XML_OPTION_HUGE_ENTITES).

The xmlwf command has a new option -H to enable huge entities.

The new entity expansion limits cause one test to fail. The XML test
file tests/xmlconf/xmltest/valid/ext-sa/012.xml has five levels of
entity expansion.

Fixes: libexpat#34
Fixes: libexpat#46
Signed-off-by: Christian Heimes <christian@python.org>
tiran added a commit to tiran/libexpat that referenced this issue Sep 20, 2018
libexpat is vulnerable to billion laughs and quadratic blowup DoS attacks.
processInternalEntity() function now limits entity expansion and
nesting in three ways:

* Entity nesting is limited to three levels of recursion.
* Total length of an entity is limited to 1023 bytes.
* The ratio of entity expansion to processed bytes cannot exceed 1:10.

The mitigation is enabled by default and can be disabled with
XML_SetOptions(parser, XML_OPTION_HUGE_ENTITES).

The xmlwf command has a new option -H to enable huge entities.

The new entity expansion limits cause one test to fail. The XML test
file tests/xmlconf/xmltest/valid/ext-sa/012.xml has five levels of
entity expansion.

Fixes: libexpat#34
Fixes: libexpat#46
Signed-off-by: Christian Heimes <christian@python.org>
tiran added a commit to tiran/libexpat that referenced this issue Sep 21, 2018
libexpat is vulnerable to billion laughs and quadratic blowup DoS attacks.
processInternalEntity() function now limits entity expansion and
nesting in three ways:

* Entity nesting is limited to three levels of recursion.
* Total length of an entity is limited to 1023 bytes.
* The ratio of entity expansion to processed bytes cannot exceed 1:10.

The mitigation is enabled by default and can be disabled with
XML_SetOptions(parser, XML_OPTION_HUGE_ENTITES).

The xmlwf command has a new option -H to enable huge entities.

The new entity expansion limits cause one test to fail. The XML test
file tests/xmlconf/xmltest/valid/ext-sa/012.xml has five levels of
entity expansion.

Fixes: libexpat#34
Fixes: libexpat#46
Signed-off-by: Christian Heimes <christian@python.org>
@hartwork hartwork removed this from the 2.4.0 milestone May 11, 2021
hartwork added a commit that referenced this issue May 11, 2021
…attacks

[CVE-2013-0340, CWE-776] Protect against billion laughs attacks (fixes #34)
halstead pushed a commit to openembedded/openembedded-core that referenced this issue Jul 2, 2021
expat < 4.0 is vulnerable to billion laughs attacks (see
[libexpat/libexpat#34]). This patch backports
the commits b1d039607d3d8a042bf0466bfcc1c0f104e353c8
and 60959f2b491876199879d97c8ed956eabb0c2e73 from upstream.

Additionally, the SRC_URI had to be adjusted due to renaming of the
source archive

Signed-off-by: Jasper Orschulko <jasper@fancydomain.eu>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
splitice pushed a commit to HalleyAssist/poky that referenced this issue Jul 2, 2021
expat < 4.0 is vulnerable to billion laughs attacks (see
[libexpat/libexpat#34]). This patch backports
the commits b1d039607d3d8a042bf0466bfcc1c0f104e353c8
and 60959f2b491876199879d97c8ed956eabb0c2e73 from upstream.

Additionally, the SRC_URI had to be adjusted due to renaming of the
source archive

(From OE-Core rev: b0b843797321360693172c57f2400b9c56ca51cf)

Signed-off-by: Jasper Orschulko <jasper@fancydomain.eu>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/poky that referenced this issue Jul 8, 2021
Source: poky
MR: 110389
Type: Integration
Disposition: Merged from poky
ChangeID: 8a496e9eb9f0540cb5c319451413812b7c51caf9
Description:

expat < 4.0 is vulnerable to billion laughs attacks (see
[libexpat/libexpat#34]). This patch backports
the commits b1d039607d3d8a042bf0466bfcc1c0f104e353c8
and 60959f2b491876199879d97c8ed956eabb0c2e73 from upstream.

Additionally, the SRC_URI had to be adjusted due to renaming of the
source archive

(From OE-Core rev: b0b843797321360693172c57f2400b9c56ca51cf)

Signed-off-by: Jasper Orschulko <jasper@fancydomain.eu>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants