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

Vulnerable Regular Expression in svnwc.py #256

Closed
yetingli opened this issue Sep 3, 2020 · 13 comments · Fixed by #257
Closed

Vulnerable Regular Expression in svnwc.py #256

yetingli opened this issue Sep 3, 2020 · 13 comments · Fixed by #257

Comments

@yetingli
Copy link

yetingli commented Sep 3, 2020

Type of Issue
Potential Regex Denial of Service (ReDoS)

Description
The vulnerable regular expression is located in

rex_blame = re.compile(r'\s*(\d+)\s*(\S+) (.*)')

The ReDOS vulnerabilitiy of the regex is mainly due to the sub-pattern (\d+)\s*(\S+) and can be exploited with the following string
"1"*5000

I think you can limit the input length or modify this regex.

@bluetech
Copy link
Member

bluetech commented Sep 3, 2020

Ohh nice catch.

I think the ambiguity in this regex is \d+\s*\S+ with zero spaces, that is \d+\S+.

From the examples listed here, the line number and the user name are always separated by at least one space (which makes sense). So we can change the middle \s* to \s+, i.e.

rex_blame = re.compile(r'\s*(\d+)\s+(\S+) (.*)') 

and that should fix it, at least I don't think there is any catastrophic backtracing left here. Does that sound right to you?

@yetingli
Copy link
Author

yetingli commented Sep 3, 2020

yeah, I think the fixed regex is safe.

@yetingli yetingli closed this as completed Sep 3, 2020
@bluetech
Copy link
Member

bluetech commented Sep 3, 2020

Thanks for confirming. I'll reopen for now and submit a PR to fix this.

@bluetech bluetech reopened this Sep 3, 2020
bluetech added a commit to bluetech/py that referenced this issue Sep 4, 2020
The subpattern `\d+\s*\S+` is ambiguous which makes the pattern subject
to catastrophic backtracing given a string like `"1" * 5000`.

SVN blame output seems to always have at least one space between the
revision number and the user name, so the ambiguity can be fixed by
changing the `*` to `+`.

Fixes pytest-dev#256.
@msmeissn
Copy link

msmeissn commented Dec 7, 2020

Is this code reachable by attackers in any form?

e.g. should this be tracked by a CVE?

@yetingli
Copy link
Author

yetingli commented Dec 8, 2020

Hi @msmeissn,
Thank you for your attention!

Is this code reachable by attackers in any form?

I think attackers may obtain this code by calling py.path.svnwc

should this be tracked by a CVE?

It would be great to assign a CVE for the issue🙂

Best regards,​​
Yeting

@msmeissn
Copy link

msmeissn commented Dec 9, 2020

Mitre assigned CVE-2020-29651 to this issue.

@earthgecko
Copy link

HI @bluetech maybe this is a question you may be able to answer.

Although the project is in maintenance mode, does #257 not warrant a new release/tag? Although py may be in maintenance mode it is still a dependency in pytest which is a fairly widely used package. Seeing as the fix was merged on 20 Sept I was just wondering if another release is ever going to be made? Are there plans to remove the py>=1.8.2 dependency in pytest?

@bluetech
Copy link
Member

The reason I don't treat it with any priority is that I'm not sure there is any code left in existence which still uses py.path.svn. But I guess you never know. pytest, tox and other well-known py dependents don't use it.

I was just wondering if another release is ever going to be made?

I've never made a py release myself, but since the deploy is automated I may be able to do it, if the token is still valid. Maybe @nicoddemus would know?

Are there plans to remove the py>=1.8.2 dependency in pytest?

We are migrating away from it but it's gonna take a while.

@nicoddemus
Copy link
Member

I've never made a py release myself, but since the deploy is automated I may be able to do it, if the token is still valid. Maybe @nicoddemus would know?

It should, although it is not using a token but my actual password. In my experience though Travis is taking forever due to their recent policy changes, so we might need to first port to GitHub actions before doing a new release.

@earthgecko
Copy link

I am sure snyk will automate this all at some point in the future. But why do they need to when they have automated people to do it for them? :)

@nicoddemus
Copy link
Member

@bluetech I've opened #266 to use GitHub actions to at least make the next release easier/possible.

@bluetech
Copy link
Member

Using the new CI that @nicoddemus set up everything went well - 1.10.0 is released now and includes this fix.

@earthgecko
Copy link

@bluetech and @nicoddemus thanks for the efforts!

earthgecko added a commit to earthgecko/skyline that referenced this issue Dec 12, 2020
IssueID #3694: #3874: SNYK-PYTHON-PY-1049546
Dependency vulnerability - py - CVE-2020-29651 #378

- Update py to 1.10.0 which resolves CVE-2020-29651 by implementing
  pytest-dev/py#257 which fixes
  pytest-dev/py#256

Modified:
dev-requirements.txt
requirements.txt
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants