jorgectf
commented
2 years ago 👋 Just a detail. There's a typo in This bug was found using [CodeQL by Github](here) pointing to affected repo's /issues/codeql.github.com :)
Closed porcupineyhairs closed 2 years ago
jorgectf
commented
2 years ago 👋 Just a detail. There's a typo in This bug was found using [CodeQL by Github](here) pointing to affected repo's /issues/codeql.github.com :)
porcupineyhairs
commented
2 years ago Hi,
So, all in all, I have been able to send in close to 92 reports. These are independent from the four CVE's referenced in #480.
Here are the details :
porcupineyhairs
commented
2 years ago As you may have noticed, there are quite a few PR's still awaiting merge. This is because the fixes were sent less than 24 hours ago. I will update this ticket as and when they are merged. I have reported only cases where an absolute path traversal was possible. In most cases, the impact of the bug is critical. Here's my reasoning for the severity analysis.
The vulnerability can be exploited over the network. A complex non-standard configuration or a specialized condition is not required for an exploitation attempt to be successful. There is no user interaction required for a successful execution of the attack. The attack can affect components outside the scope of the target module. The vulnerability can be exploited 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 an 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
This gives it a base score of 9.3/10 and a severity rating of critical.
jorgectf
commented
2 years ago :wave: @porcupineyhairs
Impressive work, thank you for your submission!
I will update this ticket as and when they are merged.
Feel free to ping me once you finish :)
As per The Bug Slayer rules, please consider the following:
Please provide any information that proves that your query finds the CVE (for example a LGTM link, a CodeQL DB, a GitHub gist with the modified query)
Moreover, take into account that you might qualify for further bounties:
Additionally, CVEs published as a result of your research into open source projects may be eligible for a bounty from the Internet Bug Bounty (IBB).
As per the CVSS, I beg to differ with This can lead to a partial system denial service, since being able to DoS by leaking large files means the connection hangs, but that depends on how Flask manages threads (production-ready servers use uwsgi/gunicorn with a very strong threading system), the server specifications, and ultimately the network speed. In other words, the vulnerability itself does not cause reduced performance or interruptions in resource availability, and if it does, it is not a problem originated by Flask.
Please see:
CVSS relevant guidance:
If a specific configuration is required for an attack to succeed, the vulnerable component should be scored assuming it is in that configuration, providing it is a reasonable configuration.
And a reasonable/standard/realistic environment should be (regarding flask documentation):
When running publicly rather than in development, you should not use the built-in development server (flask run). The development server is provided by Werkzeug for convenience, but is not designed to be particularly efficient, stable, or secure.
Indeed, all of the CVEs you specified in this comment were given an Availability Impact of None.
https://nvd.nist.gov/vuln/detail/CVE-2021-43492 https://nvd.nist.gov/vuln/detail/CVE-2021-43493 https://nvd.nist.gov/vuln/detail/CVE-2021-43494 https://nvd.nist.gov/vuln/detail/CVE-2021-43495 https://nvd.nist.gov/vuln/detail/CVE-2021-43496
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
This leaves a base score of 8.6/10 and a severity rating of high. Do you agree?
porcupineyhairs
commented
2 years ago @jorgectf
Many of the apps in the list I submit with this report recommend a user to run the app via flask's builtin web-server. Some even supply production scripts which end up calling Flask's development web-server. Amongst the projects where the fix has been merged, here's a rough summary of how they recommend a user to deploy on production.
onlaj/Piano-LED-Visualizer
In this case, if the user follows the project docs thoroughly, they would run the app using flask's development web-server using the sudo python3 /home/Piano-LED-Visualizer/visualizer.py --port 5000 command.
Microsoft/OLive
This one again runs a script which ultimately uses python app.py even in the server mode.
operatorequals/wormnest
Here again, the authors explicitly ask the user to deploy it in production via python3 app.py. They even say it's alright if one were to use Apache mod_rewrite and expose the app to the internet.
iedadata/usap-dc-website Here again, the developers create a wsgi file to deploy on production but still end up calling the flask development server.
cmusatyalab/opendiamond, cheo0/MercadoEnLineaBack,ChangeWeDer/BaiduWenkuSpider_flaskWeb and sergeKashkin/Simple-RAT These don't come with a guideline on how to deploy to production. So we may assume that they are deployed on a prod grade webserver and have a lower impact as you suggest.
orchest/orchest,ChaoticOnyx/OnyxForum and clinical-genomics/scout These do use gunicorn so the severity would be high instead of critical as you say.
As for ThundeRatz/ThunderDocs and ganga-devs/ganga, fixes for these haven't been merged yet but hey should be soon. But yes, they correctly use a production grade web-server. So the impact is lowered as you say.
So, all in all, 4/13 cases, the apps recommend a user to expose the flask development server to the network. 4/13 don't come with a guideline and 5/13 correctly deploy to gunicorn. This makes the severity critical for 4/13 projects and high for 9/13 projects; assuming the ones which didn't come with a production deployment guideline are correctly deployed via gunicorn.
As for the CVSS vector in the earlier comment https://github.com/github/securitylab/issues/407#issuecomment-976564884, for some reason NIST has changed the impact metrics for my reports. I had incorrectly reported the impact as AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. I had marked high for all fields as can be seen from the original reports which I have listed in the table below. In the absense of any deployment guidelines, I agree the severity of these should be high as you say.
jorgectf
commented
2 years ago @porcupineyhairs
Thank you for your detailed answer! I see your point and agree that if the project documentation suggests weak deployments, the Availability Impact makes sense to be set to Low in those cases, leaving a Critical severity.
Looking forward to see how many merged fixes you end up with 🤞
porcupineyhairs
commented
2 years ago @jorgectf I have had two more fixes merge through the last week. However, some of the maintainers are not responding to my request to ask for a CVE. So, I will have to apply via MITRE. This may take time. I will update the list with the CVE ids once I have them. I will also post a lgtm run link soon.
porcupineyhairs
commented
2 years ago @jorgectf
I have updated the list to reflect the current state.
Here's a LGTM link with a run against 13 projects where the vulnerability has been fixed.
jorgectf
commented
2 years ago @porcupineyhairs
What is the current status of the submission?
porcupineyhairs
commented
2 years ago @jorgectf 15 Projects have merged their fixes. CVE ID's have been issued for all but two of them. The CVEs aren't publicly disclosed though. I mean they have been issued but the details aren't publicly visible. I contacted MITRE a couple of days back to fix that but they didn't respond.
zsh-lgtm
commented
2 years ago I've been noticing that a lot of these issues you're calling out Absolute Path Traversals, but the PoC you're supplying is showing that they are not absolute path traversals.
The PoC is showing that traversal sequences (f=../../../etc/passwd) are being used rather than absolute paths (f=/etc/passwd).
jpcmonster
commented
2 years ago Is the CVE this one? https://nvd.nist.gov/vuln/detail/CVE-2022-31569 The associated cpe seems to be matching other unrelated jars, I think:
jakarta.annotation-api-1.3.5.jar (pkg:maven/jakarta.annotation/jakarta.annotation-api@1.3.5, cpe:2.3:a:oracle:java_se:1.3.5:*:*:*:*:*:*:*, cpe:2.3:a:oracle:projects:1.3.5:*:*:*:*:*:*:*, cpe:2.3:a:projects_project:projects:1.3.5:*:*:*:*:*:*:*) : CVE-2022-31569
javax.jms-api-2.0.jar (pkg:maven/javax.jms/javax.jms-api@2.0, cpe:2.3:a:oracle:projects:2.0:*:*:*:*:*:*:*, cpe:2.3:a:projects_project:projects:2.0:*:*:*:*:*:*:*) : CVE-2022-31569@SheuShec I used an automation script to generate those PoC's. Hence, the PoC's could be incorrect. Can you please point me to the code-base you are interested in?
Those relative paths shown in the PoC may not be always necessary for the exploit to work. The exploit, depending on the situation, should work with absolute path's too.
But be assured, I have only reported those projects where the path traversal allowed access outside the webroot. Hence, the impact in none of these cases is affected.
@jpcmonster I can't see those CPE entries on the webpage you link above. There shouldn't be any java projects affected by any of the CVE's listed above.
zsh-lgtm
commented
2 years ago @SheuShec I used an automation script to generate those PoC's. Hence, the PoC's could be incorrect. Can you please point me to the code-base you are interested in?
Those relative paths shown in the PoC may not be always necessary for the exploit to work. The exploit, depending on the situation, should work with absolute path's too.
But be assured, I have only reported those projects where the path traversal allowed access outside the webroot. Hence, the impact in none of these cases is affected.
Thanks for the response!
I'm not really interested in a specific code-base per se. I'm more interested in understanding your research. Did you confirm the vulnerabilities in each of these or are they reported based the findings from CodeQL?
porcupineyhairs
commented
2 years ago @SheuShec Yes, indeed, the findings are from my CodeQL query.
jpcmonster
commented
2 years ago hi @porcupineyhairs - I can't be absolutely sure why the CPE is being matched in this case.
I am using the OWASP Dependency Check tool as a gradle plugin in my java project.
My best guess is that there is something about the CPE associated with the NIST NVD entry that is causing a false positive.
(I have filed an FP report with the Dependency Check project).
But I wanted to post here because there might be something not-quite-right with the cpe.
You should be able to see it on the NIST entry:
cpe:2.3:a:projects_project:projects:*:*:*:*:*:*:*:*
andreasevers
commented
2 years ago I don't know who submitted this CVE, but the CPE identifier matches a boatload of maven dependencies that absolutely should not be matched.
I can only imagine the number of maven builds that fail due to this false positive.
JoeNuttall
commented
2 years ago Well, I can tell you that 10 different java projects have failed builds in my department due to this false positive...
Thanks andreasevers and others for making it clear here that it's in error.
cbollmeyer
commented
2 years ago @jpcmonster I can't see those CPE entries on the webpage you link above. There shouldn't be any java projects affected by any of the CVE's listed above.
This, Sir, is a wrong assumption unfortunately. The OWASP Dependency scanner flags jakarta-annotation-api, JUnit 5 and several other libraries as vulnerable all over the place, all with CVE-2022-31514 (Caoyongqi912/Fan_Platform) and CVE-2022-31569 (RipudamanKaushikDal/projects) so far. It took us half a day to find out it's Python-related and maybe an issue in a number of such projects, but definitely not in the Java libs themselves. Hopefully there's a way to stop propagation to - as I get it - 90 more such false positives during the next days, each with their own CVE so that you have to write excludes for each and everyone. Maybe better check your script next time.
ascopes
commented
2 years ago Is there any time frame for this being reverted/mediated? Otherwise it will result in having to make dozens of suppressions across anything that validates against https://cve.mitre.org/ or https://nvd.nist.gov/ since it is matching a wildcard against pretty much everything.
A little surprised that a configuration can be specified to match everything though.
skavanagh
commented
2 years ago @porcupineyhairs - These projects that are vulnerable to this issue don't seem to have any consumable releases, in those cases there doesn't need to be a CVE open. Can we use the CPE to target libraries that have consumable releases? Instead of targeting everything under the sun? The need to wildcard everything should tip you off that these aren't actually published libraries and shouldn't have a CVE open. Also, next time it would be great if you published the CVE after the fixes have been merged, so the CPE has a fixed version. It's not great to report a CVE before a maintainer has had a chance to fix and publish it (not relevant in this case b/c there are no consumable releases, but FYI for next time).
vdotjansen
commented
2 years ago @jorgectf I have had two more fixes merge through the last week. However, some of the maintainers are not responding to my request to ask for a CVE. So, I will have to apply via MITRE. This may take time. I will update the list with the CVE ids once I have them. I will also post a lgtm run link soon.
@porcupineyhairs Did you request the CVE numbers? If you did could you ask them to change the CPE to include the target software python? A lot of non python projects are getting this as a (false positive) effected CVE: https://github.com/jeremylong/DependencyCheck/issues/4671
intrigus-lgtm
commented
2 years ago @skavanagh I don't really think @porcupineyhairs did anything wrong here.
One could argue that some of the CVEs might not be very helpful, because the targeted repositories have very few stars/forks, but there are also a lot of repositories with 100+ stars.
Instead, the problem seems to be in DependencyCheck itself:
https://github.com/jeremylong/DependencyCheck/issues/4675#issuecomment-1187359752
I'm not really familiar with CPEs, but these two CVEs (CVE-2021-42055, CVE-2021-42056) have CPEs that are just as broad as CVE-2022-31569, aren't they?
skavanagh
commented
2 years ago @intrigus-lgtm I don't know about the other CVEs, but for CVE-2022-31569 the repository it's supposed to be targeting doesn't have any consumable releases. https://github.com/jeremylong/DependencyCheck/issues/4675#issuecomment-1187359752 indicates the problem with requesting a CVE on "random person's personal projects" and it's why the dep-check PR on that thread suppresses CVE-2022-31569 completely.
vdotjansen
commented
2 years ago Instead, the problem seems to be in
DependencyCheckitself: jeremylong/DependencyCheck#4675 (comment)I'm not really familiar with CPEs, but these two CVEs (CVE-2021-42055, CVE-2021-42056) have CPEs that are just as broad as CVE-2022-31569, aren't they?
Yes and no, the dependency checker tries to match a library and if it is not confident it still decides to warn you. It prefers to show false positives over not warning you for false negatives. Part of the CPE is the text project, which means every project that has a project in for example in the URL will trigger as it might be this CVE. You are correct those are also not very specific, but this is also, because both CVE's are not for a specific programming language or something like that. Having said that I would still prefer if those are also more specific.
@skavanagh I don't really think
@porcupineyhairsdid anything wrong here. One could argue that some of the CVEs might not be very helpful, because the targeted repositories have very few stars/forks, but there are also a lot of repositories with 100+ stars.
I would not say he has done anything really wrong, but things can improve
skavanagh
commented
2 years ago Having said that I would still prefer if those are also more specific.
@vdotjansen There is really nothing that can be made more specific, since the CVE references some random piece of code in a personal repository with no vendor, no version, no release, no package, or no build. There isn't even a license attributed to vulnerable code, so how can anyone use it? NIST should reconsider CVE-2022-31569, as it's not a consumable library or product. And probably those others as well, they are just not causing as many issues b/c the CPEs are more narrow.
porcupineyhairs
commented
2 years ago Wow.
This blew up more than I imagined.
This, Sir, is a wrong assumption unfortunately. The OWASP Dependency scanner flags jakarta-annotation-api, JUnit 5 and several other libraries as vulnerable all over the place, all with CVE-2022-31514 (Caoyongqi912/Fan_Platform) and CVE-2022-31569 (RipudamanKaushikDal/projects) so far. It took us half a day to find out it's Python-related and maybe an issue in a number of such projects, but definitely not in the Java libs themselves. Hopefully there's a way to stop propagation to - as I get it - 90 more such false positives during the next days, each with their own CVE so that you have to write excludes for each and everyone. Maybe better check your script next time.
@cbollmeyer The CPE's aren't written by me. I just requested CVEs from MITRE for the projects in question. The CPE are added by NVD/MITRE without any input from my side.
@porcupineyhairs - These projects that are vulnerable to this issue don't seem to have any consumable releases, in those cases there doesn't need to be a CVE open. Can we use the CPE to target libraries that have consumable releases? Instead of targeting everything under the sun? The need to wildcard everything should tip you off that these aren't actually published libraries and shouldn't have a CVE open. Also, next time it would be great if you published the CVE after the fixes have been merged, so the CPE has a fixed version. It's not great to report a CVE before a maintainer has had a chance to fix and publish it (not relevant in this case b/c there are no consumable releases, but FYI for next time).
@skavanagh CVE identifiers are used to identify vulnerabilities. By default, if someone makes a project public, I think it is safe to assume that they believe that the project or parts of it could be reused by someone sometime. A vulnerability disclosure only makes the security flaw known to the world. The maintainers of the projects listed above were given enough time to fix those vulnerabilities before the disclosure was made. This issue was created on April 29 2022. All of the maintainers were informed about vulnerabilites in their respective projects some time before that. While some got the changes merged, others didn't. I can't do much about it. Vulnerabilites have a way of repeating themselves in codebases. The whole idea behind the CodeQL project is to find and detect those vulnerable patterns before they are exploited in the wild. I just found a valid vulnerability and reported it.
@porcupineyhairs Did you request the CVE numbers? If you did could you ask them to change the CPE to include the target software python? A lot of non python projects are getting this as a (false positive) effected CVE: jeremylong/DependencyCheck#4671
@vdotjansen Yes, I did request those CVE's. But I didn't provide those CPE identifiers. I think those were added by MITRE/NVD themselves. I am dropping a mail to cpe_dictionary@nist.gov to seek the change you ask but I don't know if they are the ones I am supposed to approach in this case.
In the meantime, can we please move this coversation someplace else? This entire discussion is about how OWASP dependency-check failed to deal with an edge case and has nothing to do with security-lab/CodeQL at all.
skavanagh
commented
2 years ago This blew up more than I imagined.
Well yeah.. it broke some stuff 😆
By default, if someone makes a project public, I think it is safe to assume that they believe that the project or parts of it could be reused by someone sometime.
No, it acutally can't be used by anyone if it isn't licenced. Without granting a licence, only the copyright holder can use the code. It's why you weren't able to provide a vendor or product name in the CPE. No Licence = No Vendor = No Product. And I doubt the maintainer would do anything with any of this. AFAICT CVE-2022-31569 was issued for someone's throwaway code. I don't think this is a edge case that dependency checker is failing to deal with. NIST should not have approved the CVE, since it isn't assocated with any sort of product.
porcupineyhairs
commented
2 years ago No, it acutally can't be used by anyone if it isn't licenced. Without granting a licence, only the copyright holder can use the code.
And I doubt the maintainer would do anything with any of this.
A CVE ID has nothing to do with copyrights. Here's a quote from the link you cite above, For example, if you publish your source code in a public repository on GitHub, you have accepted the [Terms of Service](https://help.github.com/articles/github-terms-of-service), by which you allow others to view and fork your repository. Even though you may not be able to use your code directly, you can still use it after forking. Plus, there's nothing stopping you from writing a code snippet similar to the offending code in a non-licensed library. All I mean to say is a CVE is used to flag a vulnerability I see no issues in this record being created. By making a responsible disclosure, all I do is inform others of the vulnerability. Even though the maintainer in question may not wish to fix the bug for whatever reason, there are other stakeholders who might still benefit from the disclosure.
It's why you weren't able to provide a vendor or product name in the CPE. No Licence = No Vendor = No Product.
For the hundredth time, I didn't provide the CPE identifier. The vendor/product names for these purposes is typically the Github org/repo name. Please see other CVE's issued in the same batch, for instance, CVE-2022-31568. They all follow the same convention. I don't know why but for CVE-2022-31569, they made it something else. I think it should be cpe:2.3:a:RipudamanKaushikDal:projects:*:*:*:*:*:*:*:* if the pattern is to continue.
I don't think this is a edge case that dependency checker is failing to deal with.
Well, even if the incorrect CPE is to be deemed true, dependency-checker should still match projects-project as the vendor. Now, if it starts alerting on everything which has the word project in it, I think that's pretty much a definition of buggy code. Reiterating what @intrigus-lgtm said, many other CVE records also follow the same pattern as the CPE in this case does, the problem you are facing has nothing to do with my vulnerability report. The bug is in the tool which you se to dependency management.
NIST should not have approved the CVE, since it isn't assocated with any sort of product.
NIST has a very loose definition of a vulnerability. They typically try to be as broad as possible. This guidance might help.
skavanagh
commented
2 years ago For example, if you publish your source code in a public repository on GitHub, you have accepted the Terms of Service, by which you allow others to view and fork your repository
I can assure you the github terms of service does not licence anyone's unlicensed code. It allows users to view and fork, and absolves themselves of any responsibility of infringement.
cpe:2.3:a:RipudamanKaushikDal:projects:*:*:*:*:*:*:*:* doesn't match anything, just like cpe:2.3:a:rexians:rex-web:*:*:*:*:*:*:*:*doesn't match anything. There is nothing to match, since these aren't released, licenced, or consumable by other parties.
Matching nothing is an improvement over matching everything (but still not much use). IMO - issuing CVEs for things that aren't consumable by anyone or anything else is not much use and just wasted noise. We will have to agree to disagree (or see what happens)
shrimpza
commented
2 years ago This has wasted a good couple of hours of my teams time as we have multiple projects with daily dependency checks going on, and dependency check failures require us to investigate and resolve such issues before we can merge code and produce releases. So we have multiple projects in need of suppressions now, which adds further maintenance burdens down the line.
I understand you may have little/no control over the CPE/mask that is assigned, and that there may be cases where tooling like DependencyCheck causes further issues, but I absolutely believe flagging a bunch of random people's side projects/test code with security vulnerabilities is at best an immense waste of time and resources of everyone involved, and at worst amounts to abuse of these reporting systems.
Where does it stop? Some random person's bash script which has a rm -rf / in it because he thought it would be fun to do some testing and happened to commit it to GitHub?
ascopes
commented
2 years ago Matching nothing is an improvement over matching everything (but still not much use). IMO - issuing CVEs for things that aren't consumable by anyone or anything else is not much use and just wasted noise. We will have to agree to disagree (or see what happens)
As much as I appreciate the fact that anyone can open a CVE, I totally agree with this. When creating a CVE, one of the things to consider is the impact of the vulnerability. If this is effectively a personal project that is not being used elsewhere, the impact is minimal. Letting the entire world know via a blanket CVE does not provide reasonable benefit to the development community.
I understand you may have little/no control over the CPE/mask that is assigned, and that there may be cases where tooling like DependencyCheck causes further issues, but I absolutely believe flagging a bunch of random people's side projects/test code with security vulnerabilities is at best an immense waste of time and resources of everyone involved, and at worst amounts to abuse of these reporting systems.
It appears the CVE has been marked as rejected (https://nvd.nist.gov/vuln/detail/CVE-2022-31569) which is a flag that this CVE was potentially inappropriate. The given reason was:
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that no specific affected product had been identified. Notes: none.It appears the CVE has been marked as rejected (https://nvd.nist.gov/vuln/detail/CVE-2022-31569) which is a flag that this CVE was potentially inappropriate
Outside of the one that caused the issue, most all of the CVEs here on https://github.com/github/securitylab/issues/669#issuecomment-1117265726 are inappropate for the same reason. I'll be submitting those for re-evalutation as well. What a mess!
marcelstoer
commented
2 years ago Instead of bulk-submitting CVEs IMO you should have bulk-submitted GitHub issue for the affected projects. Ok, I see you did.
@skavanagh I also reached out to NIST asking to reject CVE-2022-31514.
porcupineyhairs
commented
2 years ago This thread has been blowing up quite a bit. This is most probably going to be my last and final comment for the issue at hand.
The GHSL team along with independent security researchers like me use tools like CodeQL to find security vulnerabilities in open source code. We try and recognise commonly occuring vulnerable patterns in codebases to prevent them from reoccuring. In this case, by perforing variant analysis, I found path traversal vulnerabilities in multiple projects. These were reported to their respective maintainers. Those who chose to fix them fixed them, those who didn't didn't. The entire reporting process was semi-automated and maintainers were given enough time before a disclosure was made. With each report, a CVE request was made so as to uniquely identify the issue. Now, CVE identifiers are by a variety of stakeholders for a variety of purposes; be it developers, their users, or security researchers. Sometimes, CVE records are used by devs to inform their users of a vulnerability, sometimes the records are used by authors of tools such as dependency-check to scan dependencies for known vulnerabilities and other times, they are used by folks like me to further our research. The CVE record list is not a text book you read page by page or record by record. The CVE project aims to catalog every cybersecurity vulnerability there is. They try to be as broad as possible when acccepting a new record. Given that the bug at hand, is a security vulnerability a CVE can be issued for it. There is no scarcity of record numbers and there's no real harm in registering one. In this case, I found a valid vulnerability and responsibly disclosed it. That's it. Fullstop. There's nothing more to it. All I did was share a link to this comment and requested a CVE. They did the rest. All those CPE identifiers, that not so helpful, probably script generated description for each individual CVE is all their doing. I don't have any role to play in it.
Now, coming to the angry folks following this thread, in my opinion, there are two separate issues which people are mixing and adding here. First, the issue of failing builds, folks who are here blaming me for their failing builds should understand that I am not the reason for their failed builds. The reason behind their failing builds is a bug in the OWASP dependency-check project. Please file a bug report with that project. To repeat, The builds are not failing because I am requesting CVE ids, they fail because the tooling you use is buggy. If your tool can't figure out the difference between libs like jakarta-annotation-api, JUnit 5 and Fan_Platform, I can't do much about it. Please check the issue tracker for that tool, there are multiple CVEs causing dependency checks to fail, not all of them are mine. Now coming to the second issue, as to whether MITRE and other CNA's should or shouldn't try and catalog every vulnerability there exists, all I can say is this issue is not the place for having philosophical discussions and hence, this conversation be taken somewhere else.
marcelstoer
commented
2 years ago The GHSL team along with independent security researchers like me use tools like CodeQL to find security vulnerabilities in open source code.
👍
We try and recognise commonly occuring vulnerable patterns in codebases to prevent them from reoccuring.
👍
In this case, by perforing variant analysis, I found path traversal vulnerabilities in multiple projects. These were reported to their respective maintainers. Those who chose to fix them fixed them, those who didn't didn't.
👍
The entire reporting process was semi-automated and maintainers were given enough time before a disclosure was made.
👍
With each report, a CVE request was made so as to uniquely identify the issue.
👎 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.
There is no scarcity of record numbers and there's no real harm in registering one.
👎 I disagree, it's just keeping systems and people busy needlessly. In some cases the amount of waste is significant.
folks who are here blaming me for their failing builds should understand that I am not the reason for their failed builds.
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.
skavanagh
commented
2 years ago First, the issue of failing builds, folks who are here blaming me for their failing builds should understand that I am not the reason for their failed builds. The reason behind their failing builds is a bug in the OWASP dependency-check project. Please file a bug report with that project. To repeat, The builds are not failing because I am requesting CVE ids, they fail because the tooling you use is buggy.
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 🤷
jorgectf
commented
2 years ago 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:
Please note that projects which purposely include a vulnerability pattern for testing purposes, projects that are inactive in the last year, and student or academic projects, are considered out of scope.
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.
ascopes
commented
2 years ago 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 CVE record list is not a text book you read page by page or record by record. The CVE project aims to catalog every cybersecurity vulnerability there is.
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.
If your tool can't figure out the difference between libs like jakarta-annotation-api, JUnit 5 and Fan_Platform
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 *. Even for myself, it is not clear what that CVE is actually for. I still don't fully understand what library it is targeting. Even with the word project in it, it does not provide any meaningful information. Those CPEs are meant to be machine readable, which is why many sites print them as monospace.
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.
skavanagh
commented
2 years ago 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.
| CVE | JUSTIFICATION |
|---|---|
| CVE-2022-31504 | https://github.com/ChangeWeDer/BaiduWenkuSpider_flaskWeb has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31505 | https://github.com/cheo0/MercadoEnLineaBack This was a personal repository, but no longer exists. Regardless it has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31509 | https://github.com/iedadata/usap-dc-website This is the website for USAP-DC and specific to that use case. It has no license or package that is consumable by another party. |
| CVE-2022-31510 | https://github.com/sergeKashkin/Simple-RAT has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31511 | https://github.com/AFDudley/equanimity has no usable license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31512 | https://github.com/Atom02/flask-mvc has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31513 | https://github.com/BolunHan/Krypton has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31514 | https://github.com/Caoyongqi912/Fan_Platform has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31515 | https://github.com/Delor4/CarceresBE has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31516 | https://github.com/Harveyzyh/Python This was a personal repository, but no longer exists. Regardless it has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31518 | https://github.com/JustAnotherSoftwareDeveloper/Python-Recipe-Database has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31520 | https://github.com/Luxas98/logstash-management-api has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31521 | https://github.com/Niyaz-Mohamed/Mosaic has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31526 | https://github.com/ThundeRatz/ThunderDocs has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31527 | https://github.com/Wildog/flask-file-server has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31528 | https://github.com/bonn-activity-maps/bam_annotation_tool has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31532 | https://github.com/dankolbman/travel_blahg has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31533 | https://github.com/decentraminds/umbral has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31534 | https://github.com/echoleegroup/PythonWeb has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31535 | https://github.com/freefood89/Fishtank has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31536 | https://github.com/jaygarza1982/ytdl-sync has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31537 | https://github.com/jmcginty15/Solar-system-simulator has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31538 | https://github.com/joaopedro-fg/mp-m08-interface has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31540 | https://github.com/kumardeepak/hin-eng-preprocessing has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31544 | https://github.com/meerstein/rbtm has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31545 | https://github.com/ml-inory/ModelConverter has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31546 | https://github.com/nlpweb/glance has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31547 | https://github.com/noamezekiel/sphere has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31548 | https://github.com/nrlakin/homepage has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31551 | https://github.com/pleomax00/flask-mongo-skel has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31552 | https://github.com/project-anuvaad/anuvaad-corpus has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31553 | https://github.com/rainsoupah/sleep-learner has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31554 | https://github.com/rohitnayak/movie-review-sentiment-analysis has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31555 | https://github.com/romain20100/nursequest has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31556 | https://github.com/rusyasoft/TrainEnergyServer has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31557 | https://github.com/seveas/golem has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31559 | https://github.com/tsileo/flask-yeoman has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31560 | https://github.com/uncleYiba/photo_tag has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31561 | https://github.com/varijkapil13/Sphere_ImageBackend has a BSD license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31562 | https://github.com/waveyan/internshipsystem has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository for a student internship). |
| CVE-2022-31563 | https://github.com/whmacmac/vprj has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31564 | https://github.com/woduq1414/munhak-moa has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31565 | https://github.com/yogson/syrabond has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31566 | https://github.com/DSAB-local/DSAB has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31567 | https://github.com/DSABenchmark/DSAB has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31568 | https://github.com/Rexians/rex-web This is the website for Rexians Community and specific to that usecase. It has no license or package that is consumable by another party. |
| CVE-2022-31570 | https://github.com/adriankoczuruek/ceneo-web-scrapper has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31571 | https://github.com/akashtalole/python-flask-restful-api has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31572 | https://github.com/ceee-vip/cockybook has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31574 | https://github.com/deepaliupadhyay/RealEstate has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31575 | https://github.com/duducosmos/livro_python has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31576 | https://github.com/heidi-luong1109/shackerpanel has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31577 | https://github.com/longmaoteamtf/audio_aligner_app has a MIT license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31578 | https://github.com/piaoyunsoft/bt_lnmp has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31579 | https://github.com/ralphjzhang/iasset This was a personal repository, but no longer exists. Regardless it has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31582 | https://github.com/shaolo1/VideoServer, has a GPL license, but still no vendor, no version, no release, no package, no build, and is thus not consumable by another party (it's someone's personal repository). |
| CVE-2022-31583 | https://github.com/sravaniboinepelli/AutomatedQuizEval has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31585 | https://github.com/umeshpatil-dev/Home__internet has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31587 | https://github.com/yuriyouzhou/KG-fashion-chatbot has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
| CVE-2022-31588 | https://github.com/zippies/testplatform has no license, no vendor, no version, no release, no package, no build, and is thus not consumable by another party. |
porcupineyhairs
commented
2 years ago Here's what MITRE has to say about all of this
Thank you for contacting us. We are primarily concerned with the
amount of time required to debate CVE Records for products that are
not widely used. Regardless of whether something is a "valid
vulnerability in a valid Github repo" it is possible that nobody will
ever use the affected code. We cannot devote a lot of time to the
optimal resolution of debates about software that has very few users
and/or would be difficult to incorporate into other projects.
CVE Records need to be about software products, not solely about
Github repos. By far, the most common case is that one repo is used
for one software product. However, as you can see,
https://github.com/RipudamanKaushikDal/projects
is about many unrelated software-development efforts by the same
person. The information in your original CVE ID request pointed only
to https://github.com/github/securitylab/issues/669 and did not point
to the https://github.com/RipudamanKaushikDal/projects/issues/21 issue
that said the vulnerability was in something called
image_search_gallery. This makes the CVE ID request and the CVE Record
completely invalid, and it is removed from the main CVE List. We do
keep it in our GitHub repo forever:
https://github.com/CVEProject/cvelist/blob/c791c48acd4ec8c16b331cc745e98f3118d21568/2022/31xxx/CVE-2022-31569.json
in case someone needs it. However,
https://github.com/RipudamanKaushikDal/projects seems to be about
copying code to GitHub for personal learning without any intention to
make the code usable by other people.
If you need a CVE ID for image_search_gallery, we can provide one, but
we do not encourage CVE ID requests for GitHub code that has such
marginal use cases.
Fan_Platform is a completely different case. Indeed, earlier today
someone wanted it removed, but we did not remove it, Instead we told
them that their objections were not sufficient. We looked at it and
decided:
1. There might be a bug in
https://github.com/jeremylong/DependencyCheck that causes Fan_platform
to match ^pkg:maven/org\.junit\.platform/junit\-platform - in other
words, the presence of the "platform" substring might be enough for
DependencyCheck to guess that there is a dependency
2. There has been an assertion of "no license" in a situation where
multiple GitHub users have been contributing to the codebase. Even if
you do not know what the license is, the continuing activity by
multiple persons makes it reasonable to expect that they have arranged
among themselves to allow use of the software.
Again, because of time constraints, we will not necessarily send any
responses or notifications about additional CVE Records that people
want rejected. Your work is still a valid application of the CodeQL
tool even if the GitHub repos aren't for widely used software, and your
work can potentially improve the process by which other persons use
CodeQL in the future. Thank you for your contribution.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, Microsoft/Olive has merged the fix but is yet to issue a CVE. I received a message from them late last week that they are still working on this and would get back soon. cheo0/MercadoEnLineaBack had merged the fix but now the repo has been deleted. I do have a clone porcupineyhairs/MercadoEnLineaBack which has been included in the LGTM run I shared earlier. As for the forks, scaraude/Piano-LED-Visualizer and Nbobito/Piano-LED-Visualizer, these are forks of onlaj/Piano-LED-Visualizer but have divereged from the original repo. They should be treated as separate projects but I haven't sought a CVE for them and I haven't included them in the LGTM run.
The impact metrics for of these vulnerabilities remains the exactly as we discussed here
skavanagh
commented
2 years ago I'll appeal to NIST directly on the CVEs in question, but to address the points made
There has been an assertion of "no license" in a situation where multiple GitHub users have been contributing to the codebase. Even if you do not know what the license is, the continuing activity by multiple persons makes it reasonable to expect that they have arranged among themselves to allow use of the software.
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?
There might be a bug in https://github.com/jeremylong/DependencyCheck that causes Fan_platform to match ^pkg:maven/org.junit.platform/junit-platform - in other words, the presence of the "platform" substring might be enough for DependencyCheck to guess that there is a dependency'
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!
xcorail
commented
2 years ago 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:
To be eligible for a bounty, you must first coordinate disclosure and fix of the vulnerabilities with the maintainers of the projects
The CVEs must correspond to vulnerabilities that have been disclosed and fixed via coordinated disclosure with the maintainers.
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:
The goal of this program is to incentivize the collaboration with maintainers to fix vulnerabilities.
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!
ghsecuritylab
commented
2 years ago Your submission is now in status Closed.
For information, the evaluation workflow is the following: Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed
porcupineyhairs
commented
2 years ago Okay, so @xcorail and I discussed this on Slack the other day. I am posting a brief below to keep track of the conversation. Here's what I understand so far.
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. @xcorail does not agree with this. They say, the vendor should only be the owner or a previous contributor. I can't deem myself as a vendor and publish a patch.
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?
xcorail
commented
2 years ago 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. @xcorail does not agree with this. They say, the vendor should only be the owner or a previous contributor. I can't deem myself as a vendor and publish a patch.
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 Many open source libraries are maintained by a single person or a small independent team; we still refer to these individuals and groups as vendors which implies that in the open source case, the vendor is a maintainer or a group of maintainers of the projects (and not all contributors). You can totally publish a patch if you want, but you cannot consider yourself as a vendor in the documented CVD. The CVD is a collaboration between the reporter and the vendor, so the reporter cannot be the vendor.
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.
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.
skavanagh
commented
2 years ago I'll just chime in here too.. b/c you are doing things so wrong.
I discovered the underlying issue, validated the vulnerability, drafted a report and even created a patch
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.
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.
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.
porcupineyhairs
commented
2 years ago @xcorail
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,
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.
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.
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.
ascopes
commented
2 years ago Just want to add my last 2¢ on this issue...
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.
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.
The vulnerability was publicly shown on LGTM well before I attempted to patch them.
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.
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
https://github.com/github/securitylab/issues/407
Details
TBA
Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc).
Blog post link
No response