Ivanti and Juniper Networks accused of bending the rules with CVE assignments

Critics are accusing major tech companies of not sticking to the rules when it comes to registering vulnerabilities with the appropriate authorities. Both Juniper Networks and Ivanti have attracted criticism from members of the infosec industry for the way they've handled the disclosure of vulnerabilities over the past week …

[Anonymous Coward]

Bug reporting programs

I have several friends that report bugs to companies, and sometimes go to MITRE directly for CVEs. the main gripe with bugbounty programs from these guys is that they have to agree to sit on the exploits. Sometimes for months or years. While companies think they are secure holding back public disclosure, often they are just leaving exploitable customers out to dry.

It always makes me wonder how long an exploit has really been active, when companies push out patches.

[DS999]

Re: Bug reporting programs

Maybe that should be required information that has to be provided with a CVE. The earliest known software release/date that was vulnerable, and for 0 days the earliest known date when it was being exploited.

[Michael Wojcik]

Re: Bug reporting programs

Affected versions are part of the information in the CVE submission. I don't know under whose authority it could be "required" to be correct, or who would enforce that, or what would happen in cases where that couldn't be determined.

The CVE program is voluntary. Historically, it has worked (to the extent that it has worked), in no small part because it is voluntary. In many organizations, even relatively large ones, CNAs handle CVE submissions in addition to full-time responsibilities elsewhere. While I am often in favor of using regulation to convert externalities into direct costs for offenders, regulating the CVE process seems likely to have severe revenge effects. It would have to be brought under legal compliance structures in any organization large enough to perceive it as a liability. Fewer issues would be reported, they'd go longer before being reported, there would be less information in the reports, and gaming CVEs (as in the examples in this article) would likely become more prevalent, not less.

Some CNAs have always been better than others. There are rogue CNAs who create bogus CVEs for packages not under their control, such as the infamous CVE-2020-19909. Some CNAs are pressured by corporate management or legal counsel to do a poor job of creating CVE submissions. Opinions differ among reasonable area experts on how much information should be included in a CVE. It's a complex area.

[Paul Crawford]

Seems another good reason not to trust your security to private code.

[Michael Wojcik]

Plenty of FLOSS packages aren't great about reporting security vulnerabilities either. Do you review all the software you use for vulnerabilities?

[Paul Crawford]

I do look for reported CVEs for stuff I plan on using. Generally I find far less on my choices then some of the bib name (Cisco, SonicWall, Fortinet, Juniper here...)

[Sk1]

I submitted a bug to Canon, they spent a month on it before diacovering they already knew about it but had never made a CVE, so naturally they intentionally repeated their mistake.

I've submitted bugs to Cisco over the years, 8 I believe. Some remote unauthebticated attacks. Cisco claimed the product was EOL. Then released several more firmware updates. I tried submitting again. Nope.

I found 3 bug that let me do remove code execution via magnetic waves on an NFMI defcon badge, and gave a talk. Someone else (I assume a MITRE employee) submitted my work and got a CVE for 1 of the bugs. So I submitted the other 2. They was in early 2002, still waiting on a reply.

I hope to have 1 CVE before I retire,assuming that abortion of a program lasts much longer