Content of glibc advisories vs. CVE JSON v5 and CNA rules?

Content of glibc advisories vs. CVE JSON v5 and CNA rules?

[Carlos O'Donell]

I want to make it as easy as a cut-and-paste to complete the work of
publishing the CVE data when the advisory text is complete.

When the glibc security team publishes an advisory as part of CNA process
we must comply with the CNA Rules and our goal is to use CVE JSONv5 format
uploads.

The JSONv5 format has a title and description field that must be provided.

The most interesting part is that the CVE description has some explicit
requirements in [1] that mean we would adopt similar requirements for
the text of our own advisories.

My opinion is as follows:

- The first line of our advisories should be the CVE title.
- The descriptive text of the advisory should be the CVE description.
  - Note the rules say "8.2.6 MAY contain information not listed here."
    so we can provide whatever else we want.

Thoughts?

-- 
Cheers,
Carlos.

[1] https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_8-2_cve_record_prose_description_requirements

Re: Content of glibc advisories vs. CVE JSON v5 and CNA rules?

[Siddhesh Poyarekar]

On 2024-05-02 17:40, Carlos O'Donell wrote:
> I want to make it as easy as a cut-and-paste to complete the work of
> publishing the CVE data when the advisory text is complete.
> 
> When the glibc security team publishes an advisory as part of CNA process
> we must comply with the CNA Rules and our goal is to use CVE JSONv5 format
> uploads.
> 
> The JSONv5 format has a title and description field that must be provided.
> 
> The most interesting part is that the CVE description has some explicit
> requirements in [1] that mean we would adopt similar requirements for
> the text of our own advisories.
> 
> My opinion is as follows:
> 
> - The first line of our advisories should be the CVE title.
> - The descriptive text of the advisory should be the CVE description.
>    - Note the rules say "8.2.6 MAY contain information not listed here."
>      so we can provide whatever else we want.

The CVE title is optional.  However we do need a title for our 
advisories (i.e. the first line of the advisory file), so I'm fine with 
us making it mandatory.

The CVE description (for the Mitre database) is recommended to be a 
single descriptive passage (preferrably a sentence) that encompasses all 
of the necessary information, i.e. nature, version range affected, 
module and impact of the flaw.  We could make this the first passage of 
our advisory file and then choose to augment our advisories in following 
passages when we can.

That is something like this:

Buffer overflow in posix_foo may result in arbitrary code execution

The function posix_foo in the GNU C Library versions 2.32 to 2.39 has a 
buffer overflow which may be exploited by an attacker to achieve 
arbitrary code execution.

The function posix_foo takes foo_buf as an input but it fails to 
validate the buffer against some_size. An attacker may pass a small 
enough buffer as foo_buf and cause the function to overflow into 
sensitive_struct, allowing it to control the jump destination from the 
funcptr function pointer. This was fixed with...


Does that align with what you're suggesting?

Thanks,
Sid

Re: Content of glibc advisories vs. CVE JSON v5 and CNA rules?

[Carlos O'Donell]

On 5/3/24 08:57, Siddhesh Poyarekar wrote:
> On 2024-05-02 17:40, Carlos O'Donell wrote:
>> I want to make it as easy as a cut-and-paste to complete the work
>> of publishing the CVE data when the advisory text is complete.
>> 
>> When the glibc security team publishes an advisory as part of CNA
>> process we must comply with the CNA Rules and our goal is to use
>> CVE JSONv5 format uploads.
>> 
>> The JSONv5 format has a title and description field that must be
>> provided.
>> 
>> The most interesting part is that the CVE description has some
>> explicit requirements in [1] that mean we would adopt similar
>> requirements for the text of our own advisories.
>> 
>> My opinion is as follows:
>> 
>> - The first line of our advisories should be the CVE title. - The
>> descriptive text of the advisory should be the CVE description. -
>> Note the rules say "8.2.6 MAY contain information not listed
>> here." so we can provide whatever else we want.
> 
> The CVE title is optional.  However we do need a title for our
> advisories (i.e. the first line of the advisory file), so I'm fine
> with us making it mandatory.

Right.

> The CVE description (for the Mitre database) is recommended to be a
> single descriptive passage (preferrably a sentence) that encompasses
> all of the necessary information, i.e. nature, version range
> affected, module and impact of the flaw.  We could make this the
> first passage of our advisory file and then choose to augment our
> advisories in following passages when we can.
> 
> That is something like this:
> 
> Buffer overflow in posix_foo may result in arbitrary code execution
> 
> The function posix_foo in the GNU C Library versions 2.32 to 2.39 has
> a buffer overflow which may be exploited by an attacker to achieve
> arbitrary code execution.
> 
> The function posix_foo takes foo_buf as an input but it fails to
> validate the buffer against some_size. An attacker may pass a small
> enough buffer as foo_buf and cause the function to overflow into
> sensitive_struct, allowing it to control the jump destination from
> the funcptr function pointer. This was fixed with...
> 
> Does that align with what you're suggesting?

Your prose above looks good to me.

And it meets:
- 5.2.1 It summarizes the vuln.
- 5.2.2 It provides information from 5.1 (not in another part)
  - 5.1.3 Must identify product
  - 5.1.4 Must identify affected product
  - 5.1.7 Must identify type of vuln.
    - We should just ref the CWE and CAPEC we use here?
- 5.2.5 Must include a description in English minimally

Even more specifically I'm saying we should minimally adhere to CNA Rules v4
section 5.2 in order that we can just cut and paste the results.

I want to avoid having to rewrite something when I copy text into the JSON
files for upload.

If I can get review of the advisory and that text is then copied into the
description then that works for me.

Note the interlock in process here, I must *push* to our advisories/ directory
the changes before I can make the CVE published because the public reference
from 5.1.10 must exist before publishing. I think that's fine and acceptable.

-- 
Cheers,
Carlos.