ReDoS vulnerability in svnurl.py

[SCH227]

Good night!

I found that this regex is vulnerable to Regular Expression Denial of Service.

PoC:

>>> from py._path.svnurl import InfoSvnCommand
>>> payl = "   2256      hpk        165 Nov 24 17:55 __init__.py" + " " * 5000
>>> InfoSvnCommand(payl)

Attack vector:

An user accessing a (possibly remote) subversion repository that provides malicious "info" data.
Or an attacker injecting 'svn ls http://...' output (less realistic).

Fix:

Use a pattern with non-overlapping groups. I can help in finding a better regex and testing if needed.

[The-Compiler]

Related: #256

[bluetech]

I doubt there's anyone using this code, so I don't think it would warrant any sort of security notification that users should bother with, but if you prepare a PR for this I'll merge & release it.

[skialpine]

GHSA-w596-4wvx-j9j6
https://nvd.nist.gov/vuln/detail/CVE-2022-42969

[jenstroeger]

As @skialpine mentions, the advisory now triggers pip-audit and thus can fail CI runs (like this one).

Is there a fix on the horizon?

[RonnyPfannschmidt]

The issue is not considered critical, im not aware of anyone working towards a fix

[The-Compiler]

Well, congratulations to whoever it is that decided that the right path of action here is getting a CVE for...

• Something that seems very questionable to be titled a "vulnerability" in the first place (if I can control an SVN repo/server, I might as well just Slowloris the initial info request, I suppose... though admittedly I didn't try that.)
• For some ~18 year old code...
• ...which is only there for historical reasons and discouraged to use
• ...which, to the best of our knowledge, is not used anywhere in the wild outside of some old PyPy development scripts nobody probably uses anymore (and certainly not against random SVN servers). Note the search results seem to be copies of those PyPy scripts, as far as I can tell.
• ...which, given the above, nobody is terribly interested in maintaining
• ...yet you ended up generating nothing but noise for hundreds of thousands of pytest users, which for historical reasons depends on pylib (since it came from the PyPy project, like pylib does). Yes, not everyone of the half quarter a million projects there will monitor CVEs against dependencies, but at the same time, lots of people that do (in companies and such) are probably not in that list on GitHub.

Given that it will still take some time for pytest to get fully rid of it's py internals, and people seem to like getting CVEs for this project (which just happens to be very popular via pytest, but pretty much unused outside of pytest), but without really making an attempt to understanding the context... can we please consider:

• Either vendoring the remaining code (py.path I assume) in pytest, and archiving pylib...
• ...or releasing a pylib 2.0.0 which simply drops all the code that isn't used in pytest?

Sorry if I sound frustrated. But requesting a CVE without understanding the context of the project/issue you're reporting, and then generating false reports for hundreds of thousands of pytest users is doing a major disservice to both pytest/pylib maintainers and all those users.

[RonnyPfannschmidt]

I'd go as far as to label this cve report a supply chain attack

Pytest should keep dropping pylib as it does

The cve should be added as common false positive

[The-Compiler]

I'd go as far as to label this cve report a supply chain attack

I would not, but I'd certainly add it to my "examples of behavior causing open source maintainer burnout" list, given that we're now getting the first pytest issue about this, and it almost certainly won't be the last one.

[bluetech]

I should have known better that this was going to happen when I replied as I did... If someone can get the notification retracted that'd be best. But I guess since they've already put out a security notification to the entire world and their grandmother through GitHub, the path of least resistence would be to issue a release to fix this "security issue". I'll try to do it today.

[RonnyPfannschmidt]

@bluetech @The-Compiler i woudnt mind to cut a release that drops the svn wc stuff alltogether

[The-Compiler]

@RonnyPfannschmidt agreed, and perhaps a bit more even - I opened #288 with some overview on that.

[The-Compiler]

FWIW, I've also proposed adding a note to the GitHub advisory (github/advisory-database#761) and tweeted a PSA.