CVE creation process

[Volkan Yazıcı <vo...@yazi.ci>]

Hello,

The recent CVE-2021-44832 has been subject to quite some debate whether it
was CVE-worthy or not. I think that one had far fetched assumptions and
could very well be addressed in a patch release, just like we did, but
without a CVE associated with it. The created CVE caused yet another wave
of FUD surrounding the project. I can imagine millions of deployments all
around the world were marked as flagged by monitoring tools and people
rushed to upgrade in panic, most likely, for no reason. I put aside the
damage CVEs cause on the reputation of the project.

I am told by security@apache.org that what is CVE-worthy is up to the PMC. *I
propose creating a VOTE thread for the CVE creation from now on.* I would
appreciate it if others can share their thoughts on this. If the overall
reception is positive, I will send a VOTE email to make this official.

Kind regards.

Re: CVE creation process

[Matt Sicker <bo...@gmail.com>]

I think this is a good idea. I clarified the CVE details yesterday to note the specific JNDI and LDAP issue, but the FUD is already out there.

—
Matt Sicker

> On Dec 30, 2021, at 03:02, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> Hello,
> 
> The recent CVE-2021-44832 has been subject to quite some debate whether it
> was CVE-worthy or not. I think that one had far fetched assumptions and
> could very well be addressed in a patch release, just like we did, but
> without a CVE associated with it. The created CVE caused yet another wave
> of FUD surrounding the project. I can imagine millions of deployments all
> around the world were marked as flagged by monitoring tools and people
> rushed to upgrade in panic, most likely, for no reason. I put aside the
> damage CVEs cause on the reputation of the project.
> 
> I am told by security@apache.org that what is CVE-worthy is up to the PMC. *I
> propose creating a VOTE thread for the CVE creation from now on.* I would
> appreciate it if others can share their thoughts on this. If the overall
> reception is positive, I will send a VOTE email to make this official.
> 
> Kind regards.

Re: CVE creation process

[Gary Gregory <ga...@gmail.com>]

I like the idea of voting on whether or not we want to CVE a fix because I
hope it will make us focus on how to message the issue as clearly as
possible in addition to having more eyes looking at similar possible issues.

Gary

On Thu, Dec 30, 2021 at 4:02 AM Volkan Yazıcı <vo...@yazi.ci> wrote:

> Hello,
>
> The recent CVE-2021-44832 has been subject to quite some debate whether it
> was CVE-worthy or not. I think that one had far fetched assumptions and
> could very well be addressed in a patch release, just like we did, but
> without a CVE associated with it. The created CVE caused yet another wave
> of FUD surrounding the project. I can imagine millions of deployments all
> around the world were marked as flagged by monitoring tools and people
> rushed to upgrade in panic, most likely, for no reason. I put aside the
> damage CVEs cause on the reputation of the project.
>
> I am told by security@apache.org that what is CVE-worthy is up to the
> PMC. *I
> propose creating a VOTE thread for the CVE creation from now on.* I would
> appreciate it if others can share their thoughts on this. If the overall
> reception is positive, I will send a VOTE email to make this official.
>
> Kind regards.
>

Re: CVE creation process

[Ralph Goers <ra...@dslextreme.com>]

Thanks for putting it into practical terms.  I wish it was that black and white though.
I don’t really know how much JNDI is used any more. When I learned Java JNDI was 
the standard way to access LDAP.  So I can easily imagine that there are configurations 
out there that are retrieving some passwords from it to access something from the 
logging configuration completely unaware that they may already have be compromised.

But how many are there that are doing that? Less than 1%?  What is worse, is that the 
fix will no longer allow them to access LDAP that way so many of those who this fix is 
meant to protect won’t upgrade.

Still, I have to agree that it wasn’t safe to allow users to access LDAP (as well as other 
protocols) this way and users needed to be informed. 

Ralph



> On Dec 30, 2021, at 10:01 AM, Julius Davies <ju...@gmail.com> wrote:
> 
> Hello,
> 
> Long time lurker here.
> 
> There are probably tens of thousands of CVEs in the NVD that are
> theoretically exploitable, but in practice will never be exploited. I
> wouldn't take things people say on twitter too seriously when it comes to
> determining CVE-worthiness.
> 
> I mainly think of the CVE system as a way to boost and amplify
> communication around patch releases, and to help convey to the public the
> importance of taking a given update.
> 
> If the log4j team agreed that it's not safe for consumers of Log4J to
> remain on 2.17.0, then the CVE was appropriate, no matter what anyone else
> thinks.
> 
> 
> yours,
> 
> Julius
> 
> 
> 
> On Thu, Dec 30, 2021 at 8:46 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
> 
>> I have no objection to this but it obviously has to be done on the private
>> list.
>> 
>> I happen to disagree with your assessment of 44832. As far as I am
>> concerned any
>> uncontrolled use of JNDI requires a CVE. People don’t seem to understand
>> just how
>> bad it is. Any design that lets you download code from a random web server
>> that then
>> runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP
>> works.
>> 
>> Ralph
>> 
>>> On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>>> 
>>> Hello,
>>> 
>>> The recent CVE-2021-44832 has been subject to quite some debate whether
>> it
>>> was CVE-worthy or not. I think that one had far fetched assumptions and
>>> could very well be addressed in a patch release, just like we did, but
>>> without a CVE associated with it. The created CVE caused yet another wave
>>> of FUD surrounding the project. I can imagine millions of deployments all
>>> around the world were marked as flagged by monitoring tools and people
>>> rushed to upgrade in panic, most likely, for no reason. I put aside the
>>> damage CVEs cause on the reputation of the project.
>>> 
>>> I am told by security@apache.org that what is CVE-worthy is up to the
>> PMC. *I
>>> propose creating a VOTE thread for the CVE creation from now on.* I would
>>> appreciate it if others can share their thoughts on this. If the overall
>>> reception is positive, I will send a VOTE email to make this official.
>>> 
>>> Kind regards.
>> 
>> 

Re: CVE creation process

[Julius Davies <ju...@gmail.com>]

p.s.  The fact CVE-2021-44832 was scored as CVSS v3 Base 6.6 = Medium means
probably most companies will not urgently take this patch.  I've seen
policies in practice (at companies) that consider 7.0 and up ("HIGH") as
patch-in-7-days, and 9.0 and up ("CRITICAL") as patch-in-3-days, and things
like this.  So the fact you scored it as 6.6 Medium was great for helping
consumers understand the fact this one was not as urgent as some of the
others.

I really wouldn't worry whether the CVE was worthy or not - it's better to
issue a CVE that wasn't needed compared to the inverse!



On Thu, Dec 30, 2021 at 9:01 AM Julius Davies <ju...@gmail.com>
wrote:

> Hello,
>
> Long time lurker here.
>
> There are probably tens of thousands of CVEs in the NVD that are
> theoretically exploitable, but in practice will never be exploited. I
> wouldn't take things people say on twitter too seriously when it comes to
> determining CVE-worthiness.
>
> I mainly think of the CVE system as a way to boost and amplify
> communication around patch releases, and to help convey to the public the
> importance of taking a given update.
>
> If the log4j team agreed that it's not safe for consumers of Log4J to
> remain on 2.17.0, then the CVE was appropriate, no matter what anyone else
> thinks.
>
>
> yours,
>
> Julius
>
>
>
> On Thu, Dec 30, 2021 at 8:46 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> I have no objection to this but it obviously has to be done on the
>> private list.
>>
>> I happen to disagree with your assessment of 44832. As far as I am
>> concerned any
>> uncontrolled use of JNDI requires a CVE. People don’t seem to understand
>> just how
>> bad it is. Any design that lets you download code from a random web
>> server that then
>> runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP
>> works.
>>
>> Ralph
>>
>> > On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
>> >
>> > Hello,
>> >
>> > The recent CVE-2021-44832 has been subject to quite some debate whether
>> it
>> > was CVE-worthy or not. I think that one had far fetched assumptions and
>> > could very well be addressed in a patch release, just like we did, but
>> > without a CVE associated with it. The created CVE caused yet another
>> wave
>> > of FUD surrounding the project. I can imagine millions of deployments
>> all
>> > around the world were marked as flagged by monitoring tools and people
>> > rushed to upgrade in panic, most likely, for no reason. I put aside the
>> > damage CVEs cause on the reputation of the project.
>> >
>> > I am told by security@apache.org that what is CVE-worthy is up to the
>> PMC. *I
>> > propose creating a VOTE thread for the CVE creation from now on.* I
>> would
>> > appreciate it if others can share their thoughts on this. If the overall
>> > reception is positive, I will send a VOTE email to make this official.
>> >
>> > Kind regards.
>>
>>

Re: CVE creation process

[Julius Davies <ju...@gmail.com>]

Hello,

Long time lurker here.

There are probably tens of thousands of CVEs in the NVD that are
theoretically exploitable, but in practice will never be exploited. I
wouldn't take things people say on twitter too seriously when it comes to
determining CVE-worthiness.

I mainly think of the CVE system as a way to boost and amplify
communication around patch releases, and to help convey to the public the
importance of taking a given update.

If the log4j team agreed that it's not safe for consumers of Log4J to
remain on 2.17.0, then the CVE was appropriate, no matter what anyone else
thinks.


yours,

Julius



On Thu, Dec 30, 2021 at 8:46 AM Ralph Goers <ra...@dslextreme.com>
wrote:

> I have no objection to this but it obviously has to be done on the private
> list.
>
> I happen to disagree with your assessment of 44832. As far as I am
> concerned any
> uncontrolled use of JNDI requires a CVE. People don’t seem to understand
> just how
> bad it is. Any design that lets you download code from a random web server
> that then
> runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP
> works.
>
> Ralph
>
> > On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> >
> > Hello,
> >
> > The recent CVE-2021-44832 has been subject to quite some debate whether
> it
> > was CVE-worthy or not. I think that one had far fetched assumptions and
> > could very well be addressed in a patch release, just like we did, but
> > without a CVE associated with it. The created CVE caused yet another wave
> > of FUD surrounding the project. I can imagine millions of deployments all
> > around the world were marked as flagged by monitoring tools and people
> > rushed to upgrade in panic, most likely, for no reason. I put aside the
> > damage CVEs cause on the reputation of the project.
> >
> > I am told by security@apache.org that what is CVE-worthy is up to the
> PMC. *I
> > propose creating a VOTE thread for the CVE creation from now on.* I would
> > appreciate it if others can share their thoughts on this. If the overall
> > reception is positive, I will send a VOTE email to make this official.
> >
> > Kind regards.
>
>

Re: CVE creation process

[Ralph Goers <ra...@dslextreme.com>]

I have no objection to this but it obviously has to be done on the private list.

I happen to disagree with your assessment of 44832. As far as I am concerned any 
uncontrolled use of JNDI requires a CVE. People don’t seem to understand just how 
bad it is. Any design that lets you download code from a random web server that then 
runs in your JVM is a disaster, and that is exactly the way JNDI/LDAP works.

Ralph

> On Dec 30, 2021, at 2:02 AM, Volkan Yazıcı <vo...@yazi.ci> wrote:
> 
> Hello,
> 
> The recent CVE-2021-44832 has been subject to quite some debate whether it
> was CVE-worthy or not. I think that one had far fetched assumptions and
> could very well be addressed in a patch release, just like we did, but
> without a CVE associated with it. The created CVE caused yet another wave
> of FUD surrounding the project. I can imagine millions of deployments all
> around the world were marked as flagged by monitoring tools and people
> rushed to upgrade in panic, most likely, for no reason. I put aside the
> damage CVEs cause on the reputation of the project.
> 
> I am told by security@apache.org that what is CVE-worthy is up to the PMC. *I
> propose creating a VOTE thread for the CVE creation from now on.* I would
> appreciate it if others can share their thoughts on this. If the overall
> reception is positive, I will send a VOTE email to make this official.
> 
> Kind regards.