Python : Flask Path Traversal Vulnerability #669
Comments
|
👋 Just a detail. There's a typo in |
A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. ## Root Cause Analysis Passing untrusted input to `flask.send_file`can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/piaoyunsoft/bt_lnmp/blob/fa49519b04586a00e76c105e7ce1da36eadf6922/www/server/panel/BTPanel/__init__.py#L858 Here, the `filename` parameter is attacker controlled and is used as the filename passed to the `send_file` call. This leads to a path traversal attack. ## Remediation This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. ## References * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 ### This bug was found using *[CodeQL by Github](codeql.github.com/)*
A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. ## Root Cause Analysis Passing untrusted input to `flask.send_file`can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/piaoyunsoft/bt_lnmp/blob/fa49519b04586a00e76c105e7ce1da36eadf6922/www/server/panel/BTPanel/__init__.py#L858 Here, the `filename` parameter is attacker controlled and is used as the filename passed to the `send_file` call. This leads to a path traversal attack. ## Remediation This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. ## References * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 ### This bug was found using *[CodeQL by Github](codeql.github.com/)*
A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. ## Root Cause Analysis Passing untrusted input to `flask.send_file`can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/piaoyunsoft/bt_lnmp/blob/fa49519b04586a00e76c105e7ce1da36eadf6922/www/server/panel/BTPanel/__init__.py#L858 Here, the `filename` parameter is attacker controlled and is used as the filename passed to the `send_file` call. This leads to a path traversal attack. ## Remediation This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. ## References * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 ### This bug was found using *(CodeQL by Github)[https://codeql.github.com/]*
A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. ## Root Cause Analysis Passing untrusted input to `flask.send_file`can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/piaoyunsoft/bt_lnmp/blob/fa49519b04586a00e76c105e7ce1da36eadf6922/www/server/panel/BTPanel/__init__.py#L858 Here, the `filename` parameter is attacker controlled and is used as the filename passed to the `send_file` call. This leads to a path traversal attack. ## Remediation This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. ## References * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 ### This bug was found using *[CodeQL by Github](https://codeql.github.com/)*
A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. ## Root Cause Analysis The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/nrlakin/homepage/blob/82ffb967f370bfe84b6e954a59022f37f4f105c1/home/frontend/views.py#L78 Here, the `filename` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. ## Proof of Concept The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/download//../../../../etc/passwd"' ``` ## Remediation This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. ## References * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 ### This bug was found using *[CodeQL by Github](https://codeql.github.com/)*
A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. ## Root Cause Analysis The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/AFDudley/equanimity/blob/16862abb282f174ceb7ca297c956565fcfb188ad/server/views/frontend.py#L25 Here, the `path` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. ## Proof of Concept The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/js//../../../../etc/passwd"' ``` ## Remediation This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. ## References * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 ### This bug was found using *[CodeQL by Github](https://codeql.github.com/)*
👍
👍
👍
👍
👎 Projects that have no license, no vendor, no version, no release, no package, or no build do not deserve to have CVEs IMO. I feel responsible security researchers should understand the - well, responsibility - they have.
👎 I disagree, it's just keeping systems and people busy needlessly. In some cases the amount of waste is significant.
Yes and no. By reporting CVEs that shouldn't exist in the first place you triggered it. Of course you are not responsible for potential bugs in the ODC project (jeremylong/DependencyCheck!4671). I feel that most people engaged in this discussion here do understand that perfectly well. |
OWASP dependency-check project is a best effort tool and only as good as the data it utilizes. It breaks up keywords from the vendor, project, and all the fields in the CPE to find matches. The more accurate the data is for the CVE, the more accurate the tool is (other tools too). We all deal with when these tools fail b/c it flags things it shouldn't, but usually the false-positives are against valid CVEs. I'm going to have NIST review all your CVEs. You filed junk data to the in NIST database - PEROID! It would be nice if you realized the mistake and help clean it up, but I guess not 🤷 |
|
Hi all, Thank you all for bringing this information to our attention. It seems like there was an error assigning the CPEs for some of the CVEs associated with this Bug Slayer submission. We have already conveyed the issue to NIST. As for the applicability of these CVEs, we do not encourage participants to ask maintainers to request CVEs for small, academic, or personal projects as stated in our bug bounty rules:
And therefore, we will not take into account the CVEs assigned to projects matching those conditions. We are and will be listening to your concerns and suggestions to improve the program and avoid future similar situations. Thank you. |
|
Not wanting to argue with anyone or cause any problems, but I think it is worth adding a couple of points to what has already been said here, a little further up the thread. I appreciate both sides have valid arguments here, but there are a couple of things I disagree with.
The main problem with this mindset is that if you want to document every single security vulnerability there is, you are going to end up with hundreds of thousands of vaguely labelled CVEs from projects made by students who have use-after-free vulnerabilities in their coursework for University. You are going to have vulnerabilities in random proofs of concept for tests. You are going to have CVEs for dummy hello world applications where people hardcode a fake password or dont sanitise a SQL input, or don't encode a URL path safely. All things that in a deployed system would be critical, but in a proof of concept or test, do not actually have any significance. From this, a situation will arise where we are going to have so much noise and so many CVEs with vague CPEs that it will make the database completely unusable in enterprise and open source scenarios. This limits the use of any of these reports where this database is used for continuous integration and vulnerability detection to prevent human error. This will just discourage the use of the NVE database entirely. The end result will be a far less secure cyberspace. The purpose of a CVE is to evaluate the impact of a vulnerability (hence the 10 point rating system). A vulnerability that impacts, say, React Native, is going to naturally have a wider imapct than a hello world application that exists for purely symbolic purposes. With additional noise and misclassifications, it becomes increasingly difficult to accurately determine that impact. In the same way that it is far harder to hear someone talk if everyone in the room is shouting.
I think you have misunderstood the issue here a little. The issue is that it is somewhat difficult to determine what the library is when the CPE marks the name as I appreciate it is not your fault this was misconfigured, but it is worth taking into appreciation when considering how the thread has blown up. Also worth noting some of the listed projects have had zero activity since 2015, so raising a CVE is going to have little effect on amending that code base. At least one of those I clicked on does not even exist. Scope is the main issue here. I think that is where the issues have arisen from. |
|
I will be asking NIST to re-evaluate the following CVEs based on the justification below. There were some CVEs that were legit and should have been requested, but most weren't. These CVEs should absolutely not have been requested (or even approved) as there are no impacted products. We trip up on enough false-positives on valid CVEs. PRs are fine, but not CVEs.
|
|
Here's what MITRE has to say about all of this |
|
I can see CVE-2022-31569 has been removed. MITRE says I can seek a new CVE with the correct sub-project name but they don't encourage this. So I am not going to apply for a CVE that particular project again. As for the disputes to all other CVE's are considered. I think they are effectively addressed by the message above. Everyone visiting this thread for addressing their failed builds can take up the issue of the false positive with their respective tool maintainers. With that said, @jorgectf, the bounty application still remains in place. So far I have 13 projects and 2 independent forks which have addressed the vulnerability. Of these, The impact metrics for of these vulnerabilities remains the exactly as we discussed here |
|
I'll appeal to NIST directly on the CVEs in question, but to address the points made
A lack of licensing would mean a library or project is less likely to be used elsewhere. A lack of a release is even less likely, A build even more. And on top of all, if it hasn't even been published or versioned - I think it's safe to question if anything is really impacted. Do any of these CVEs have any sort of product or service behind them that is vulnerable?
Dependency check (and other tools) have to do this on purpose. They break up the keywords in the CPE to identify possible vulnerable dependencies. If the NIST data could be used to perfectly identify a vulnerable dependency then there wouldn't be the need to do this and all would be well. This "bug" sometimes accounts for the very problem caused by the negligent submission CVEs. Bad data in = Bad data out. You can't build good tools around bad data. Not saying the NIST data is bad, it's very good! We find legit vulnerabilities all the time, but we need to keep it that way. Submitting CVEs for random github projects does not serve that purpose. The world does not need to know about a vulnerability in Uncle Yiba's photo_tag project - CVE-2022-31560. It takes manpower and computing power to ensure things are identified properly. It's not cheap! |
|
Hi @porcupineyhairs, Thanks for the submission! We have reviewed your report and validated your findings. After internally assessing the findings we have determined this submission is not eligible for a reward under the Bug Bounty program, because the security vulnerabilities have been disclosed publicly, in public Issues and Pull Requests. The Bug Slayer program requires that you disclose the vulnerabilities following a coordinated disclosure process. Here are the extracts of our rules that mention this:
We know that private collaboration between security researchers and maintainers is sometimes difficult, but that is precisely the point of this program. As stated in our rules:
Even though this submission was assessed as being ineligible for the bounty program, we appreciate your efforts finding and fixing security vulnerabilities at scale in open source projects, and would like to offer you a thank you reward. Best regards and happy hacking! |
|
Your submission is now in status Closed. For information, the evaluation workflow is the following: |
|
Okay, so GHSL wants to promote responsible behaviour and hence requests that a researcher only make a Coordinated Vulnerability Disclosure(CVD). In this case, GHSL deems that by making a public issue and a public PR with a fix, I have violated CVD norms. Instead of filing public issues and public PR's, I should have contacted each maintainer individually and requested them to either fix the vulnerability, provide them a private patch or at least seek prior permission before submitting the PR. In my defense, I have referenced the CERT's Guide to Coordinated Vulnerability Disclosure which defnes Coordinated Vulnerability Disclosure (CVD) as a process for reducing adversary advantage while an information security vulnerability is being mitigated. It says there are six phases of a disclosure, Discovery, Reporting, Validation and Triage, Remediation, Public Awareness and Deployment. It explicitly says that a stakeholder may be responsible for more than one phase. In this case, since everthing till the Remediation phase was handled by me. I discovered the underlying issue, validated the vulnerability, drafted a report and even created a patch; I claim that there is no real adversary advantage resulting from my acts. None of the projects were, even for a few minutes, left without a patch. I claim, since the vendor for open source projects is typically the owner of the repo and the repository's contributors, by the virtue of me submitting a tested patch, I, for the purposes of CVD, can act as a vendor. I would also like to point out that my CodeQL patch was merged directly into an already existing stable query. So the vulnerabilities were already publicly visible on LGTM. In fact, walking through the LGTM alerts for the particular rule is what led me to those projects in the first place. While I claim above that I carried out the reporting phase, it was infact LGTM which did it. The vulnerability was publicly shown on LGTM well before I attempted to patch them. My public Github issues/PRs don't make any new additions on that front. My PRs on the contrary aid in fixing them. I might have made the public disclosure which prompted the maintainers to act but I am not the first one to discuss the vulnerability publicly. LGTM did that before me by making alerts publicly visible. By this decision, I believe GHSL is implying that no new alert on LGTM, resulting from a CodeQL stable query, or any additional patch on it, would ever be eligible for Bug Slayer. Is this intended? |
Indeed I do not agree with you. The reporter cannot be a vendor. If you look at page 17 of the CERT guide that you mention, the vendor is clearly defined, and when they talk about open source they say
The LGTM alerts are indeed visible to the public, but they are not yet verified and triaged. If you use one of these alerts, verify it, create a PoC for it, propose a patch or not, disclose it privately following the CVD, and get the consent of the maintainer to create a public PR, then that would be eligible to our program. |
|
I'll just chime in here too.. b/c you are doing things so wrong.
I don't see how you could have done this. Most of those "projects" don't have a viable application that you could have gotten up and running. Have you done a reproduction or exploited any of these "applications" that you have alerted the public about? Just b/c something shows in a SAST scan doesn't mean it's vulnerable. It's got to be explotible in the context of a running application.
Yeah.. that's BS! You couldn't have "tested" the patch on a running "application" there are no applications to run on those CVEs you've opened. Maybe you've tested the remediation by itself, but you have not in the context of those projects. It's just scraps of code in various repositories. IMO - Mitre has handled this wrong too. Lots of wrong everywhere. |
CVD says verification and triage is done by the vendor. Provided that the vendor can reproduce the issue by reading the report, PoC, patch etc are not required by CVD. In this case, qhelp would typically suffice.
The disclosure is already done. A report's a report regardless of who does it. A report even from a less trusted source is still processed the same way. Yes, during verification/triage the vendor may still decline it but I don't see any special exclusions for anyone there. I am trying to understand how a report from LGTM differs from a report by me on this front. |
|
Just want to add my last 2¢ on this issue...
Isn't this the whole definition of responsible disclosure? You don't make dangerous information known to the world until actions have been taken to prevent it being exploited by falling into the wrong hands. By making an issue the center of attention by raising public paperwork for it, you are just holding up a big flashing sign saying "hey, I found an exploit for your application that is dangerous, come see". If the exploit isn't dangerous or has very limited or no scope, it then questions the appropriateness of a CVE.
LGTM just shows the potential for a vulnerability to be present. It does not understand every edge case that exists to prove something is exploitable. LGTM is an advisory assistive tool, not a single source of truth. LGTM is also an automated tool, it lacks the ability to exercise situational discretion in the same way you do as a human. This is important to distinguish. I have seen applications that LGTM would raise as being vulnerable to CVEs that are just totally incorrect (one being Log4Shell), purely because a dependency has an optional binding to that library. The noise by false positives is always a deterrent for people looking for quick ways to exploit deployed software. LGTM can also be left misconfigured for some projects, which can add additional noise that an attacker would have to spend time and resources working around. By raising issues and PRs before a fix has been evaluated and ideally implemented, you are effectively reducing the legwork needed by people scraping for exploits. Unlike LGTM, you are saying "I have proven that this is vulnerable", not just "this has the potential to be vulnerable based on other cases I know of". For most Flask apps that are just hobby/pet projects, the impact is somewhat limited, but imagine if you did this for heartbleed, or spectre-like attacks. It would throw everyone into an immediate panic. |
LGTM rule results are already public. I sent in a public patch to fix bugs which were valid after manual testing. If you are someone looking at Github issues for vulnerabilities, you are definitely looking at LGTM and the likes for reports too.
In the coordinated vulnerability disclosure process, each report is to be assesed independently. The sources may be less trusted but that does not mean you disregard the report.
Agreed.
The fix are comparitively minor and all assessed manually by me. A report for "has the potential to be vulnerable" is still a report worth taking a look at according to CERT's CVD guidelines. Yes, one could have looked at my profile and found a very useful set of results but I don't know if there would be a meaningful impact in this case. Basically, I am seeking a few clarifications on GHSL's bounty program. GHSL is rejecting my report saying I am making a public disclosure instead of a CVD. But the thing is if you strictly go by the CVD guidelines, then even LGTM alerts are treated as valid reports. If GHSL is disqualifying my report due to non-conformance with CVD guidelines, I would like to know if GHSL plans on disqualifing all cases where a public LGTM alert was shown as ineligible on similar grounds. |
This is kind of missing my point. My point is not that it follows some defined process. My point is that it is a difference between speculation and confirmation.
That's the point, you explicitly declared and confirmed the vulnerability. Without doing that, it is not clear that the issue was actually a problem in the first place. Also, by you doing this on your account, you are effectively providing a directory of confirmed exploits to anyone who wishes to misuse that information. As I said, LGTM does not confirm issues. It only flags the potential that they might exist. Any software could be potentially vulnerable but that can be implied by just seeing the dependency list most of the time. LGTM is just linking that and the patterns for it. Neither are disclosing a confirmed issue. It is a case of providing additional information that was not there before, either via clarity, reproductions, confirmation, or additional attack vectors. Not speaking on behalf of the project, but that is my assumption as to why this is the case. |
I don't agree. LGTM alerts are not
I already answered this question above. If you transform one of these alerts into an actionable report, by adding your added value as a security researcher (examples from what @ascopes said: |
|
I use CodeQL on my projects, BTW! Love it! |
…anga-devs#2025) A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. ## Common Weakness Enumeration category CWE - 36 ## Root Cause Analysis The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/ganga-devs/ganga/blob/0c0f9e33b36ee7ead0855f1464f8d4efad26bdbc/ganga/GangaGUI/gui/routes.py#L671 Here, the `path` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. ## Proof of Concept The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/job/<int:job_id>/browse///../../../../etc/passwd"' ``` ## Remediation This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `werkzeug.utils.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. ## Common Vulnerability Scoring System Vector The attack can be carried over the network. A complex non-standard configuration or a specialized condition is not required for the attack to be successfully conducted. There is no user interaction required for successful execution. The attack can affect components outside the scope of the target module. The attack can be used to gain access to confidential files like passwords, login credentials and other secrets. It cannot be directly used to affect a change on a system resource. Hence has limited to no impact on integrity. Using this attack vector a attacker may make multiple requests for accessing huge files such as a database. This can lead to a partial system denial service. However, the impact on availability is quite low in this case. Taking this account an appropriate CVSS v3.1 vector would be (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L)[https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:L&version=3.1] This gives it a base score of 9.3/10 and a severity rating of critical. ## References * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 ### This bug was found using *[CodeQL by Github](https://codeql.github.com/)* Co-authored-by: Porcupiney Hairs <[email protected]>
…ccess files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/HolgerGraef/MSM/blob/6dd2c9557e0285e1270c84375ebd6f8d10e422a4/app/main/views.py#L544 Here, the `path` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/plugins//../../../../etc/passwd"' ``` This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669
…ccess files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/hgrf/racine/blob/6dd2c9557e0285e1270c84375ebd6f8d10e422a4/app/main/views.py#L544 Here, the `path` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/plugins//../../../../etc/passwd"' ``` This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669
…ccess files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/hgrf/racine/blob/6dd2c9557e0285e1270c84375ebd6f8d10e422a4/app/main/views.py#L544 Here, the `path` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/plugins//../../../../etc/passwd"' ``` This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669
…ccess files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/HolgerGraef/MSM/blob/6dd2c9557e0285e1270c84375ebd6f8d10e422a4/app/main/views.py#L544 Here, the `path` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/plugins//../../../../etc/passwd"' ``` This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669
* add test for issue #129 * A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files. This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”. The `os.path.join` call is unsafe for use with untrusted input. When the `os.path.join` call encounters an absolute path, it ignores all the parameters it has encountered till that point and starts working with the new absolute path. Please see the example below. ``` >>> import os.path >>> static = "path/to/mySafeStaticDir" >>> malicious = "/../../../../../etc/passwd" >>> os.path.join(t,malicious) '/../../../../../etc/passwd' ``` Since the "malicious" parameter represents an absolute path, the result of `os.path.join` ignores the static directory completely. Hence, untrusted input is passed via the `os.path.join` call to `flask.send_file` can lead to path traversal attacks. In this case, the problems occurs due to the following code : https://github.com/HolgerGraef/MSM/blob/6dd2c9557e0285e1270c84375ebd6f8d10e422a4/app/main/views.py#L544 Here, the `path` parameter is attacker controlled. This parameter passes through the unsafe `os.path.join` call making the effective directory and filename passed to the `send_file` call attacker controlled. This leads to a path traversal attack. The bug can be verified using a proof of concept similar to the one shown below. ``` curl --path-as-is 'http://<domain>/plugins//../../../../etc/passwd"' ``` This can be fixed by preventing flow of untrusted data to the vulnerable `send_file` function. In case the application logic necessiates this behaviour, one can either use the `flask.safe_join` to join untrusted paths or replace `flask.send_file` calls with `flask.send_from_directory` calls. * [OWASP Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) * github/securitylab#669 * coding style: black * backport to old werkzeug version * cleanup --------- Co-authored-by: Porcupiney Hairs <[email protected]>
CVE(s) ID list
This is a placeholder issue. I plan on sending bulk PR's to approx 100 projects. I will add the CVE once the fixes are merged and identifiers are assigned.
All For One submission
#407
Details
TBA
Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc).
Blog post link
No response
The text was updated successfully, but these errors were encountered: