Expose Expat XML attack protection APIs

@gpshead

BPO	46793
Nosy	@gpshead, @hartwork, @corona10

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2022-02-18.21:27:31.809>
labels = ['type-feature', '3.11']
title = 'expose expat XML billion laughs attack mitigation APIs'
updated_at = <Date 2022-02-25.02:16:52.654>
user = 'https://github.com/gpshead'

bugs.python.org fields:

activity = <Date 2022-02-25.02:16:52.654>
actor = 'sping'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2022-02-18.21:27:31.809>
creator = 'gregory.p.smith'
dependencies = []
files = []
hgrepos = []
issue_num = 46793
keywords = []
message_count = 2.0
messages = ['413513', '413955']
nosy_count = 3.0
nosy_names = ['gregory.p.smith', 'sping', 'corona10']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue46793'
versions = ['Python 3.11']

Linked PRs

@hartwork

Quoting from #31397 (comment)

"""
XML_SetBillionLaughsAttackProtectionActivationThreshold

XML_SetBillionLaughsAttackProtectionMaximumAmplification

I still hope that someone can make those two^^ accessible (with additional glue code) to the user on pyexpat level in CPython.
""" - Sebastian Pipping @hartwork

First mention at https://bugs.python.org/issue44394#msg395642

FYI starting with Expat 2.7.2, there are two new API functions more related to both security and amplification:

@hartwork

@hartwork I have a question on the API usage. It appears that we can only call those functions on parsers without parents. Do you suggest that we:

provide a module-wide function which, for any parser object created by the user, the function will be called automatically for orphan parsers, or
keep it a per-parser configuration?

Having it enabled everywhere seems fine to me, considering that otherwise users would need to know whether a parser has a parent or not, however, there is no way to detect this on our side to warn them properly (the structure is opaque).

I think the only way to get a parser with a parent is through XML_ExternalEntityParserCreate nbut I don't really know if I'm entirely right here.

@picnixz

Hello @picnixz, thanks for your interest! 👍

@hartwork I have a question on the API usage. It appears that we can only call those functions on parsers without parents.

Yes. It's a deliberate choice to disallow that, the alternative would have been to instead find the root parser and apply the change to the root parser. The latter could be considered misleading or convenient, depending on view.

Do you suggest that we:

provide a module-wide function which, for any parser object created by the user, the function will be called automatically for orphan parsers, or

keep it a per-parser configuration?

Definitely not module wide — two unrelated parsers can have different limit and threshold values at runtime —, the rest I may not fully understand. Can you help me understand the rest better, e.g. the orphan part of it?

Having it enabled everywhere seems fine to me, considering that otherwise users would need to know whether a parser has a parent or not, however, there is no way to detect this on our side to warn them properly (the structure is opaque).

I think you're right that a parser cannot be asked "do you have a parent?" currently. "Not easily" for sure, "not at all" probably.

I think the only way to get a parser with a parent is through XML_ExternalEntityParserCreate nbut I don't really know if I'm entirely right here.

That is correct, it's the only way.

I'm happy to discuss this more.

By orphan I meant without a parent parser. What I wanted to know was whether we should, upon parser creation, call these new functions internally with thresholds and factors being set globally but you already answered by "no" so it's good on my side.

Considering the failure can only happen when either the parser has a parent or the factor is invalid as a number, I'm going to simply remake those checks on Python's side so that I can raise appropriate exceptions (ideally I would have loved having a return code being returned by expat so that I know what exactly happened but it's also fine).

gh-90949: Recommend `hasattr` with Expat security methods (#139800)

[3.14] gh-90949: add Expat API to prevent XML deadly allocations (CVE…

[3.13] gh-90949: add Expat API to prevent XML deadly allocations (CVE…

[3.10] gh-90949: add Expat API to prevent XML deadly allocations (CVE…

[3.11] gh-90949: add Expat API to prevent XML deadly allocations (CVE…

[3.12] gh-90949: add Expat API to prevent XML deadly allocations (CVE…

[3.14] pythongh-90949: expose Expat API to tune exponential expansion…

[3.14] gh-90949: expose Expat API to tune exponential expansion prote…

[3.13] gh-90949: expose Expat API to tune exponential expansion prote…

gh-90949: Fix copy-paste typo in pyexpat capsule API initialization (#…

[3.15] gh-90949: Fix copy-paste typo in pyexpat capsule API initializ…

[3.12] gh-90949: expose Expat API to tune exponential expansion prote…

[3.11] gh-90949: expose Expat API to tune exponential expansion prote…

[3.10] gh-90949: expose Expat API to tune exponential expansion prote…

Navigation Menu

Repository navigation

Expose Expat XML attack protection APIs #90949

Linked PRs

31 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Expose Expat XML attack protection APIs #90949

Description

Linked PRs

Activity

gpshead commented on Feb 18, 2022

hartwork commented on Feb 25, 2022

hartwork commented on Sep 16, 2025

picnixz commented on Sep 17, 2025

hartwork commented on Sep 17, 2025

picnixz commented on Sep 17, 2025

31 remaining items

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions