CPE for stenc

[jonasstein]

I am thinking about registering stenc with an unique CPE number. This would enable us to write proper security advisories and users/distributions get the information quickly.
What do you think @ninthclowd and others?

[jmwilson]

Makes sense; should probably issue an advisory about keys generated in 1.0.8 and earlier.

[jonasstein]

@jmwilson, @ninthclowd @sunwire please have a look at the security advisory draft and send me your comments.

[jmwilson]

Can you paste a link to the draft?

[jonasstein]

seems only I can see the draft in github. I copied it to a pastebin https://dpaste.com/HQW9QTG8R

[sunwire]

For me it looks fine.

[jonasstein]

Update: I have requested an CPE number.

[jonasstein]

CPE is now registered.
For the broken keygenerator I propose a CVSS as follows:
https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N/E:F/RL:O/RC:C/CR:L/IR:X/AR:X/MAV:P/MAC:L/MPR:L/MUI:N/MS:U/MC:H/MI:N/MA:N&version=3.1
any comments?

[sunwire]

I think Exploit Code Maturity (E) should be Unproven that exploit exists (E:U)
Do we know any exploit or PoC? (vulnerable code is not an exploit)

[jonasstein]

I selected this option, because the exploit would just be a trivial for loop. No real exploit is required and I expect that every attacker is has any script language with for at hand. But I have no strong opinion about this item.

[sunwire]

the exploit would just be a trivial for loop.

Do you mean checking every key value?
It's a brute force rather than an exploit, and it takes a lot of time.
A 256 bit key has 1.157920892x10^77 combinations.

[jonasstein]

I agree with you about the wording exploit. So I think Unproven that exploit exists (E:U) makes more sense.
The number of combinations was less for the broken release see: #22 (comment)