1 |
On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon wrote: |
2 |
> Hi, |
3 |
> |
4 |
> On 2022/11/10 06:13, John Helmert III wrote: |
5 |
> >>> - Drop synopsis and description fields. These fields contain the same |
6 |
> >>> information and will be superceded by the existing impact field. |
7 |
> >> Well, I'm not saying "no" but it feels a bit weird reading a GLSA that |
8 |
> >> doesn't say a word what the problem is but specifies impact. |
9 |
> > You're right, but with 19 CVEs (for example), is anyone really |
10 |
> > interested in hearing about the problem that caused each of the 19 |
11 |
> > issues? In the current format we've resorted to writing descriptions |
12 |
> > like... |
13 |
> Actually yes! Also a way to check whether my specific configuration is |
14 |
> vulnerable for this specific CVE, something like "If you're setting |
15 |
> foo=bar in /etc/pkg.conf your system is vulnerable, if you've got |
16 |
> foo=phew you're most likely fine". Obviously we could rely a bit more |
17 |
> on package maintainers (myself included) to provide these. |
18 |
|
19 |
That would greatly increase the care necessary for us to release a |
20 |
GLSA. It's already a big pain (even with the new GLSAMaker being a |
21 |
huge improvement over the old one), and I'd like to make it less of a |
22 |
pain. Maybe a proxy for this information for you would be the "type" |
23 |
field of the impact? |
24 |
|
25 |
> I don't think I've seen a single "workaround" and usually the text here |
26 |
> just says "No known workaround", where the reality is that for something |
27 |
> like asterisk just not using the affected module is good enough. So |
28 |
> workaround: "Don't use chan_sip, use chan_pjsip instead" would be |
29 |
> perfectly fine here. |
30 |
> |
31 |
> One could thus also link GLSA issues to specific USE flags, taking |
32 |
> asterisk again, let's say the problem is with the http web server having |
33 |
> a buffer overflow in the http basic authenticator, then if that embedded |
34 |
> server isn't even compiled in, how can the package be vulnerable? So |
35 |
> here vulnerable would be something like |
36 |
> <net-misc/asterisk-16.X.Y:16[http], <net-misc/asterisk-18.A.B[http], |
37 |
> which then also indicates the "fixed" versions, as has been pointed out |
38 |
> "affected" and "not affected" are inverses. |
39 |
|
40 |
The "atom" attribute of each constraint is using atom syntax, so along |
41 |
with that we get the ability to specify USE exactly like |
42 |
"asterisk-16.X.Y:16[http]". |
43 |
|
44 |
> A mechanism to QUERY which installed packages are affected by known |
45 |
> GLSA's would also be tremendously helpful. |
46 |
|
47 |
Like glsa-check? |
48 |
|
49 |
> > |
50 |
> > Multiple vulnerabilities have been discovered in $PACKAGE. Please |
51 |
> > review the CVE identifiers referenced below for details. |
52 |
> > |
53 |
> > ... simply because it's infeasible (and in my opinion, not really |
54 |
> > necessary) for us to enumerate the issues in this way. Also, I note |
55 |
> > that the section being called "impact" doesn't preclude us from |
56 |
> > incorporating text that we would currently put in the "description" or |
57 |
> > "synopsis" fields. |
58 |
> |
59 |
> Of course giving the full details in the GLSA is a pain in the backside, |
60 |
> is there a way to retrieve this information automatically from the CVE |
61 |
> database? In other words, just get the blurp from there and include it |
62 |
> here. It won't give full details, but at least it will give some extra |
63 |
> details not currently available. Effectively we choose to ignore |
64 |
> certain GLSAs if we consider their impact to be low. |
65 |
|
66 |
We could import CVE descriptions, but then we'd end up with a huge |
67 |
wall of mostly useless text, such as CVE-2021-35648's: |
68 |
|
69 |
Vulnerability in the MySQL Server product of Oracle MySQL (component: |
70 |
Server: FTS). Supported versions that are affected are 8.0.26 and |
71 |
prior. Easily exploitable vulnerability allows high privileged |
72 |
attacker with network access via multiple protocols to compromise |
73 |
MySQL Server. Successful attacks of this vulnerability can result in |
74 |
unauthorized ability to cause a hang or frequently repeatable crash |
75 |
(complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability |
76 |
impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
77 |
|
78 |
MySQL bugs usually have dozens of CVEs associated with them. Would it |
79 |
really be useful to have dozens of those paragraphs in GLSAs? Would it |
80 |
be useful to have that text included in a GLSA for MariaDB or |
81 |
PostgreSQL if they're affected by the same issue? |
82 |
|
83 |
On the other end of the spectrum (CVE-2022-41035): |
84 |
|
85 |
Microsoft Edge (Chromium-based) Spoofing Vulnerability. |
86 |
|
87 |
Does that tell anyone anything about the vulnerability? Not really, I |
88 |
think. It'd just be added noise in a GLSA. |
89 |
|
90 |
> It would also help a great deal to automate that if the CVE scores and |
91 |
> the "inputs" into that could be made available, eg, CVE score 7.0, |
92 |
> remote=yes/no, .... (And I'm fairly certain importing this from the CVE |
93 |
> database should be possible). |
94 |
|
95 |
It is possible, but is it really useful? CVSS scores are really |
96 |
just arbitrary numbers produced by CNAs (just like descriptions are |
97 |
arbitrary text). Even worse, sometimes the CNA changes the CVSS score, |
98 |
so if we reproduce it into GLSAs, would we have to keep track of any |
99 |
changes and update the GLSA accordingly? |
100 |
|
101 |
The CVE IDs are already exposed by the GLSA as references.uri |
102 |
fields. From those, it'd be trivial to automate the retrieval of the |
103 |
CVE data from their authoritative sources (e.g. NIST's NVD API [1] or |
104 |
cvelist.git itself [2]). But, maybe it would be useful to have a |
105 |
"type" attribute in the uri field indicating what kind of identifier |
106 |
it is (whether CVE, WSA, XSA, etc), and then other tools could more |
107 |
easily grok each kind of reference. |
108 |
|
109 |
[1] https://nvd.nist.gov/developers/vulnerabilities |
110 |
[2] https://github.com/CVEProject/cvelist |
111 |
|
112 |
> Of course, someone has to do the work, and the current status quo |
113 |
> doesn't irritate me enough to free up cycles to fix it, but if the above |
114 |
> could be (partially) accommodated that would be really, really great, if |
115 |
> not, no harm done. |
116 |
> |
117 |
> Much appreciate that there is work being done in this area. |
118 |
> |
119 |
> Kind Regards, |
120 |
> Jaco |
121 |
> |
122 |
> |