Probably a bug in synchronization and a criticism

[mir-hossein]

Hello,

MITRE has revoked some CVEs but advisories are available in github advisories.

CVE-2021-43503 MITRE Reviewed by github :-|
CVE-2022-31279 MITRE Reviewed by github :-|

Revoked CVEs:
CVE-2021-43503
CVE-2022-34943
CVE-2021-37298
CVE-2022-31279
CVE-2022-30779
CVE-2022-30778
CVE-2019-9081

Please don't publish advisories for POP chains. These are not vulnerabilities and mislead the developers and the cyber security community.

More CVEs will be revoked in the next few days. Please keep your advisories up-to-date to MITRE db.
Probably there is a bug in synchronization. Please address the issue.

Thank you,
Regards,
Mirhossein Rahmani

#595
#594

[KateCatlin]

Hi @mir-hossein, thanks for reaching out!

Both of the advisories linked have been marked as "withdrawn," which means they will no longer send alerts! We do need better synchronization however to automatically do so when CVEs are revoked, though I've looked into it and it seems we need to wait until the CVE 5.0 release (coming this fall) to automate. I'll create an issue internally to address this as soon as we can. Thank you!

[mir-hossein]

Hello @KateCatlin,

Thank you for your response.

Good luck 🌸,
Thank you,
Regards,
Mirhossein

[mir-hossein]

I hadn't seen your edit, I will edit my previous comment.

[mir-hossein]

Edit: I made a mistake, I read this:

We do need better synchronization

as

We don't need better synchronization

Sorry 🌼,

Regards,
Mirhossein

[mir-hossein]

Hello,

Would you please review these advisories again? @KateCatlin @darakian

I didn't submit a "Suggest improvements for this vulnerability" because I want you to review these advisories please and decide about them.

I'm sure these CVEs have been issued for POP chains:
CVE-2022-33107
CVE-2021-36564
CVE-2021-36567
CVE-2020-15148
CVE-2021-3007
CVE-2019-10912

I think these CVEs have been issued for POP chains:
CVE-2021-23592
CVE-2021-23420

I mentioned only reviewed advisories. The list of unreviewed advisories is terrible and I think it's better that you have a connection with MITRE and ask them to review these POP chains again and decide to revoke the CVEs or not. MITRE has issued CVEs for POP chains recently and I think it's better you contact them.

Thank you,
Regards,
Mirhossein

[darakian]

Hey @mir-hossein 👋

Iterating down the list I see
https://nvd.nist.gov/vuln/detail/CVE-2022-33107
https://nvd.nist.gov/vuln/detail/CVE-2021-36564
https://nvd.nist.gov/vuln/detail/CVE-2021-36567
https://nvd.nist.gov/vuln/detail/CVE-2019-10912
https://nvd.nist.gov/vuln/detail/CVE-2021-23592
https://nvd.nist.gov/vuln/detail/CVE-2021-23420
as still live / not disputed / not revoked
In general we want the assigning authority or the software maintainer to be the revoking authority.

https://nvd.nist.gov/vuln/detail/CVE-2020-15148 / GHSA-699q-wcff-g9mj
is a self report by the maintainers of the software with us assigning the CVE on their behalf.

https://nvd.nist.gov/vuln/detail/CVE-2021-3007
is disputed and we can certainly take another look

I'm curious too what the focus on POP chains is about. Can you elaborate on what your goals here are?

[mir-hossein]

Thank you @darakian for your response.

Hey @mir-hossein wave

Iterating down the list I see https://nvd.nist.gov/vuln/detail/CVE-2022-33107 https://nvd.nist.gov/vuln/detail/CVE-2021-36564 https://nvd.nist.gov/vuln/detail/CVE-2021-36567 https://nvd.nist.gov/vuln/detail/CVE-2019-10912 https://nvd.nist.gov/vuln/detail/CVE-2021-23592 https://nvd.nist.gov/vuln/detail/CVE-2021-23420 as still live / not disputed / not revoked In general we want the assigning authority or the software maintainer to be the revoking authority.

https://nvd.nist.gov/vuln/detail/CVE-2020-15148 / GHSA-699q-wcff-g9mj is a self report by the maintainers of the software with us assigning the CVE on their behalf.

https://nvd.nist.gov/vuln/detail/CVE-2021-3007 is disputed and we can certainly take another look

I shared the list because the CVEs have been issued for POP chains. I don't mean the CVEs were revoked. I ask you to contact MITRE and request them to review these CVEs again and to stop issuing new CVEs for POP chains. I contacted MITRE but they sometimes revoke CVEs and sometimes not. (without any explanation).

Recently, MITRE has issued CVE-2022-2886 and CVE-2022-2870.

I'm curious too what the focus on POP chains is about. Can you elaborate on what your goals here are?

Some users have started requesting CVEs for POP chains in 2019. As you know, POP chains are not vulnerabilities, the users use the maintainers' lack of security knowledge to achieve a CVE.

For years no one protested them. It started with less-known Softwares. Now they target Laravel and other popular frameworks.

POP chains are important but aren't vulnerabilities. If an attacker wants to exploit Laravel, he/she can use well-known Monolog POP chains. Please take a look at this one and this one. These two POP chains cover all the software that uses Monolog. E.g. Laravel, Symfony, ...

Another issue about POP chains is that who will detect the duplication?
MITRE issues a CVE when they see something works, but who is investigating the duplication?
Are all of them new? Please look at reference to this revoked CVE. CVE-2022-30779.

Everyone can request a new CVE with a small change to previous POP chains. All will work but it's deceiving.
Probably, some of them know this weakness.

I focused on all PHP related vulnerabilities and attacks. I intend to collect all types of related vulnerabilities and related attacks and tricks used to exploit them because I will publish a repository about them in the next months.

You see only my protest against CVEs related to POP chains because MITRE has been issued CVE for those.

I contacted some maintainers and suggested solutions to them. E.g. This commit prevents RCE in Monolog 3. * . *
My POP chains for Monolog 3 . * . * are available here and here
Also, For older versions this one. We requested CVE for the chains? No.

Or even recently, for the includeFile function in Composer that is being used in attacks, we didn't request a CVE, because it's NOT a vulnerability. composer/composer#11015

Vulnerability definition is something different. Even if maintainers requested a CVE for POP chains, it is a mistake. They can have their advisories and it's very good to inform their users.

I don't protest POP chains, I protest the CVEs.

As I told you three months ago, (Please check reference of this CVE), documenting POP chains is very good, but issuing a CVE for those is a mistake. I asked there to find a solution to document these types of risks. Something like an issuing EF-????-????? (Exploit Facilitator).

If you have any other questions, I can answer. (If I know the answer)

Thank you,
Regards,
Mirhossein

[darakian]

Apologies about the delayed reply. I've been a little sick recently.

I hear your complaint about CVEs being assigned when you believe they should not be. Certainly CVEs are assigned when they should not be and we try to avoid including advisories which we can be certain do not have any security impact. What constitutes "security impact" is of course poorly defined. For what it's worth Mitre has some documentation on the subject. That said we (GitHub) are a member of the CVE system as maintained by Mitre. We do not have authority to unilaterally revoke CVEs nor do we provide a service of contesting CVEs.

What we try to do with our database is to index as many vulnerabilities in as much software as possible so that consumers of software have visibility into what they're using. While I agree that not all POP chains have a security impact some do and the software affected should have those vulnerabilities indexed for the sake of visibility.

I focused on all PHP related vulnerabilities and attacks. I intend to collect all types of related vulnerabilities and related attacks and tricks used to exploit them because I will publish a repository about them in the next months.

I look forward to reading it 😃

Or even recently, for the includeFile function in Composer that is being used in attacks, we didn't request a CVE, because it's NOT a vulnerability. composer/composer#11015

I would suggest that you could/should get a CVE for that. You've identified a bug in a program which could have a negative impact if exploited. Why not communicate that to your users?

I don't protest POP chains, I protest the CVEs.

I will point you at Mitre for protests about the CVE system.
https://cve.mitre.org/about/contactus.html
https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_9_appeals_process

[ljharb]

CVEs aren't for bugs or "negative impacts", they're only for security issues. If the definition of "security issue" is stretched to include "any bug that could disrupt an application" then it becomes so thin that it's meaningless.

[darakian]

Again, we are not the assigning CNA in these cases. For complaints on these specific CVEs please contact mitre

https://cve.mitre.org/about/contactus.html
https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_9_appeals_process

[ljharb]

@darakian agreed and understood :-) i was responding to

I would suggest that you could/should get a CVE for that. You've identified a bug in a program which could have a negative impact if exploited.

[darakian]

Oh. On that point I tend to see the vuln numbering systems as tools to index and inform. Obviously the choice on getting a CVE is theirs to make, but if there's a potential credential leak (or denial of service even) then why not get a CVE and kick off a bunch of automation to inform people? If the disclosure is well written and informative then the disclosure consumer can make the determination on what action to take (if any) and it's a few minutes of work in the no-op case.

I'm very hesitant to make sweeping statements on these things since it's basically 100% edge cases, but that's a more fleshed out rational as to why I suggested they might get a CVE there :)

[mir-hossein]

Hello,

Thank you for your answers,

I understood that Github cannot revoke the CVEs. I just provided a suggestion to have a connection with MITRE because:

• CVEs are not suitable to cover POP chains.
• CVEs are not suitable to cover all types of security risks. (Conditional)
• ...

About POP chains:
If you investigate these CVEs, they targeted "Frameworks", they used their own unserialize function and provided a demo based on it. If no one protests against it, requesting CVEs for POP chains will be epidemic and we will face a flood of CVEs that will mislead users.

Conclusion:
I will contact MITRE again.