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
ReDoS vulnerability in svnurl.py #287
Comments
|
Related: #256 |
|
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. |
|
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? |
|
The issue is not considered critical, im not aware of anyone working towards a fix |
|
Well, congratulations to whoever it is that decided that the right path of action here is getting a CVE for...
Given that it will still take some time for pytest to get fully rid of it's
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. |
|
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 |
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. |
|
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.
|
|
@bluetech @The-Compiler i woudnt mind to cut a release that drops the svn wc stuff alltogether |
|
@RonnyPfannschmidt agreed, and perhaps a bit more even - I opened #288 with some overview on that. |
|
FWIW, I've also proposed adding a note to the GitHub advisory (github/advisory-database#761) and tweeted a PSA. |
|
GitHub have now reacted and amended the advisory:
and apparently also added that information for Dependabot alerts:
|
|
I've filed a CVE rejection request with MITRE, since they're the CVE CNA in this case. If they successfully reject it, getting it removed from GHSA should also be easy. |
|
Actually, looks like I'll be able to propose a GHSA withdrawal even if the CVE itself hasn't been retracted. I'll open a PR for that in a moment. |
|
I've filed github/advisory-database#762 to mark the GHSA report as withdrawn. |
|
@The-Compiler agreeable and funny #287 (comment) @woodruffw thanks for following up on the advisory! That means that |
Once that's merged and the OSV entry is marked as withdrawn, yeah. |
|
@The-Compiler @bluetech @woodruffw & other maintainers: don't sweat it! Even though 18 years ago, someone wrote a regex, not thinking of 2022-levels of security paranoia, your efforts are still very much appreciated and your contributions are incredibly productive. The CVE did trigger some alarms in builds of valuable systems used by financial institutions. But that's good. It doesn't necessarily mean that pytest is suddenly unusable. It just forces downstream developers in highly secured places to stop and think. Alerts can be ignored, assessed, categorized, accepted,... Please look at CVEs as mostly just a catalyst. Having the CVE removed is a harsh reaction, but the right one if we're absolutely sure that that particular regex is not exploitable. But try to think of it from the point of view of a security officer, with full paranoia goggles on (and no intimate knowledge of the module). The regex is present in the code. It could be executed. A hacker could penetrate, set up a SVN repo, craft some commands, take advantage of other existing vulnerabilities on the system,... You have to think worst case and then some. In the end, I think a correctly worded CVE with a low severity score which clearly includes all the IFs, would have been the best option here. Thanks! |
|
Taking the freedom to quote what I wrote over at github/advisory-database#762 (comment):
|
|
Just to make sure there's no confusion: I'm not a maintainer of this project or of With that being said: I disagree that it's good that a CVE was filed for this behavior. The fact that one was filed and published seemingly without any review represents a series of communication and authority breakdowns; the fact that the project's own maintainers have done more investigation into exploitability potential than the original reporter seems to have is an indicator of this. As for why that matters: not everybody is a bank, with roles dedicated to reviewing a constant deluge of security reports. In the context of more limited resources, managing security fatigue is far more important than reporting weakness classes like ReDoS, which don't manifest as exploitable vulnerabilities in the overwhelming majority of cases. When users get tired of useless reports, they disable their security tools entirely. |
|
First of all, I did fill for a CVE, but I didn't publish it. Someone else did it. I find illogical it was you, but the GH advisory says "Credits - @The-Compiler". |
…te or the CVE is removed we should ignore this pytest-dev/py#287
…te or the CVE is removed we should ignore this pytest-dev/py#287
There was a vulnerability in py <= 1.11.0, which does not really matter for cpython-lldb, but dependabot was unhappy. See pytest-dev/py#287 (comment) for details.
There was a vulnerability in py <= 1.11.0, which does not really matter for cpython-lldb, but dependabot was unhappy. See pytest-dev/py#287 (comment) for details.
There was a vulnerability in py <= 1.11.0, which does not really matter for cpython-lldb, but dependabot was unhappy. See pytest-dev/py#287 (comment) for details.
There was a vulnerability in py <= 1.11.0, which does not really matter for cpython-lldb, but dependabot was unhappy. See pytest-dev/py#287 (comment) for details.
There was a vulnerability in py <= 1.11.0, which does not really matter for cpython-lldb, but dependabot was unhappy. See pytest-dev/py#287 (comment) for details.
Fix security issue: pytest-dev/py#287 Signed-off-by: Wayne Sun <gsun@redhat.com>
…ng and pytest to 7.2 to address ReDoS vulnerability See https://github.com/pyupio/safety/blob/main/CHANGELOG.md#234---2022-12-07 See pytest-dev/py#287 (comment)
remove 3.6 support
…onduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data, because the InfoSvnCommand argument is mishandled. The particular codepath in question is the regular expression at py._path.svnurl.InfoSvnCommand.lspattern and is only relevant when dealing with subversion (svn) projects. Notably the codepath is not used in the popular pytest project. The developers of the pytest package have released version 7.2.0 which removes their dependency on py. Users of pytest seeing alerts relating to this advisory may update to version 7.2.0 of pytest to resolve this issue. See pytest-dev/py#287 (comment) for additional context.
|
Is the POC in the description actually working for anyone?
For me it executes everything in a fraction of a second. |
|
It's thinkable that recent python versions have complexity enhancements |
See pytest-dev/py#287 (comment) for more info.

Good night!
I found that this regex is vulnerable to Regular Expression Denial of Service.
PoC:
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 text was updated successfully, but these errors were encountered: