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
Simplify path handling, use safe_join #12
Conversation
The current implementation of sanitized_join did not handle ".." properly. The problem is, that .absolute() does not do what .resolve() does, but .resolve() does not work on non existant paths. Anyway, flask has a function exactly for this: safe_join. So let's use that one. While at it, simplified the whole path handling a bit.
|
@ChristianTacke Thank you very much for your contribution! This looks as if the current code is vulnerable to a directory traversal attack, is that correct? What mitigates the impact is:
I am inclined to not go through the bureaucracy of allocating a CVE for this, but I’ll take other opinions on that matter. What do you think? Vote with |
|
After further discussion, some vectors came to mind in a shared hosting scenario (no idea if anyone uses it in that way) which are considerable. I’ll try to get a CVE for this, but I won’t block releasing the fix. |
Yes, that's fully correct. I was able to test this by doing: $ telnet localhost 5000
GET /../1.txt HTTP/1.0
Host: localhost
and putting appropriate files ( Additional thoughts about mitigations
About shared hosting:
Please excuse for not properly doing the disclosure. I had realized most of the mitigations and had assumed (as you did in your first comment), that they would make the problem small enough. I hadn't included shared hosting in the scenario. Yes, please do a patch release/etc early (possibly merge my PR soonish, so that people using the master branch get the fix quickly). |
Oh wow, that vector didn’t even cross my mind yet. This means that the XMPP server gains file write privileges outside of the data directory. The XMPP server may not be trusted to that extent. Regarding shared hosting: The attack vector which came to mind was more along the lines of accessing data from another xhu instance. E.g. if you have one at /var/lib/customers/domain1/ and one at /var/lib/customers/domain2/, you can access data from domain1 via domain2. This may have impact if there are egress traffic quotas or additional HTTP authentication in place for domain1, because both can be circumvented that way. |
|
Thanks for merging! To summarize: |
|
Thanks again for the report. No worries about the responsible disclosure; That would’ve been appreciated, but I agree that this is a low-impact vector. |
The current implementation of sanitized_join did not handle ".." properly. The problem is, that .absolute() does not do what .resolve() does, but .resolve() does not work on non existant paths.
Anyway, flask has a function exactly for this: safe_join.
So let's use that one.
While at it, simplified the whole path handling a bit.