The XML documentation starts with a red warning:

"Warning: The XML modules are not secure against erroneous or maliciously constructed data. If you need to parse untrusted or unauthenticated data see the XML vulnerabilities and The defusedxml Package sections. "
https://docs.python.org/dev/library/xml.html

I suggest to add the same warning to the plistlib library which uses the XML parser internally to handle XML files.

Is there something we could do in plistlib to avoid those problems?

Plist XML files are not arbitrary XML. In particular disabling entity definitions would avoid the problems mentioned as plist files should not contain those. That said, a quick glance at the xml.etree module doesn't seem to have a documented way to disable entities.

Seems that we can not control entity definitions and expansions. We only can limit the number of expanded entities per element (the size of self.data).

What is the reasonable default limit (taking into account that every < and &bpo-12345; is a separate entity)? How to name the limit parameter if we make it configurable? What type of exceptions should be raised?

One option is to copy what defusedxml does to forbid a number of unsafe operations, see https://github.com/tiran/defusedxml/blob/eb38a2d710b67df48614cb5098ddb8472289ce6d/defusedxml/ElementTree.py#L68

Defusedxml uses an XMLParser subclass that optionally disables some features (such as entity definitions), for plistlib those features can be disabled unconditionally.

I haven't thought much about the exceptions to use, probably a similar exception as is used for invalid plist files.

Another thing I haven't really thought about: would such a change be 3.10 only or is this something we could backport?

The following plist file currently works with plistlib, but does not work with plutil(1) on macOS 10.15 (parse error in the DTD definition). That indicates that entity definitions aren't supposed to be used in plist files and it would be safe to disable this feature in plistlib.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd" [
<!ENTITY entity "replacement text">
]>
<plist version="1.0">
<dict>
<key>A</key>
<string>&entity;</string>
</dict>
</plist>

Oh, I missed that there is a handler for EntityDecl. Well, then we can fix this issue in few lines of code.

I think it should be backported. We can add private flag (global or class variable) to enable entity declarations, but do not support them in 3.10.

I'm working on a PR.

The PR is fairly simple: Just reject files with entity declarations as invalid files. Adding an option to accept entity declarations should not be necessary as Apple tools won't accept these declarations.

New changeset 05ee790 by Ronald Oussoren in branch 'master':
bpo-42051: Reject XML entity declarations in plist files (bpo-22760)
05ee790

New changeset 479553c by Miss Skeleton (bot) in branch '3.9':
bpo-42051: Reject XML entity declarations in plist files (GH-22760)
479553c

New changeset 65894ca by Miss Skeleton (bot) in branch '3.8':
bpo-42051: Reject XML entity declarations in plist files (GH-22760)
65894ca

New changeset e512bc7 by Ned Deily in branch '3.7':
bpo-42051: Reject XML entity declarations in plist files (bpo-22760) (GH-22801)
e512bc7

New changeset a158fb9 by Miss Skeleton (bot) in branch '3.6':
bpo-42051: Reject XML entity declarations in plist files (GH-22760) (GH-22801) (GH-22804)
a158fb9

Thanks Ronald Oussoren for the fix. It's better to fix a vulnerability (denial of service in this case) rather than documenting it :-)

CVE-2022-48565 was assigned to this.

I didn't have any involvement in the assignment, posting here for reference only.

@samueloph Thanks for highlighting these to us, if you have a list you want to send we've been ensuring all CVE IDs registered against Python are making their way into the PSF Advisory Database. You could open an issue with all missing CVE IDs there to make it easier to track. Thanks again!

CVE-2022-48565 was assigned to this.

I didn't have any involvement in the assignment, posting here for reference only.

It looks like NVD just copy pasted the unverified details and score from GHSA-crhm-wc96-7579. The score of the vulnerability is 9.8 which, in my opinion, is not really reflecting reality.

NVD scores in many cases have been problematic as they lack analysis while at the same time have a cascading effect to upstreams as well as downstream vendors.

Also: https://daniel.haxx.se/blog/2023/08/26/cve-2020-19909-is-everything-that-is-wrong-with-cves/

It looks like NVD just copy pasted the unverified details and score from GHSA-crhm-wc96-7579. The score of the vulnerability is 9.8 which, in my opinion, is not really reflecting reality.

@sethmlarson: Would you mind to have a look at the score of this CVE?

@vstinner @stratakis The best we can do is submit a request to NVD on it's score, MITRE/CVE don't create these scores and have no control over them. NVD also does it's scoring based on the worst-case scenario, not based on a common usage scenario, which can sometimes result in higher scores.

My own perspective, I would probably score this vulnerability fairly similarly to NVD.

Future CVEs issued by the PSF CNA we'll be able to provide a CVSS score ourselves, but that doesn't stop NVD from scoring the CVE on their own (and their score will be listed alongside ours, just like it is today).