1 |
Hi, |
2 |
|
3 |
On 2022/11/10 16:24, John Helmert III wrote: |
4 |
> On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon wrote: |
5 |
>> Hi, |
6 |
>> |
7 |
>> On 2022/11/10 06:13, John Helmert III wrote: |
8 |
>>>>> - Drop synopsis and description fields. These fields contain the same |
9 |
>>>>> information and will be superceded by the existing impact field. |
10 |
>>>> Well, I'm not saying "no" but it feels a bit weird reading a GLSA that |
11 |
>>>> doesn't say a word what the problem is but specifies impact. |
12 |
>>> You're right, but with 19 CVEs (for example), is anyone really |
13 |
>>> interested in hearing about the problem that caused each of the 19 |
14 |
>>> issues? In the current format we've resorted to writing descriptions |
15 |
>>> like... |
16 |
>> Actually yes! Also a way to check whether my specific configuration is |
17 |
>> vulnerable for this specific CVE, something like "If you're setting |
18 |
>> foo=bar in /etc/pkg.conf your system is vulnerable, if you've got |
19 |
>> foo=phew you're most likely fine". Obviously we could rely a bit more |
20 |
>> on package maintainers (myself included) to provide these. |
21 |
> That would greatly increase the care necessary for us to release a |
22 |
> GLSA. It's already a big pain (even with the new GLSAMaker being a |
23 |
> huge improvement over the old one), and I'd like to make it less of a |
24 |
> pain. Maybe a proxy for this information for you would be the "type" |
25 |
> field of the impact? |
26 |
|
27 |
Fair enough at pain. Limited people, limited resources. I do think |
28 |
that package maintainers should get involved in the process though, to |
29 |
help provide this information, but this should not cause delays in |
30 |
getting the GLSAs released. Even if the GLSA gets updated on a future |
31 |
iteration to add some of this information. |
32 |
|
33 |
What I'm after is being able to quickly decide (since we sometimes see a |
34 |
fair number of of GLSAs coming in around the same time, affecting |
35 |
different systems, with variable degrees of "exposedness" and need to be |
36 |
able to prioritise which systems to update first) whether we can |
37 |
(relatively) safely ignore a GLSA (at least temporarily). |
38 |
|
39 |
> |
40 |
>> I don't think I've seen a single "workaround" and usually the text here |
41 |
>> just says "No known workaround", where the reality is that for something |
42 |
>> like asterisk just not using the affected module is good enough. So |
43 |
>> workaround: "Don't use chan_sip, use chan_pjsip instead" would be |
44 |
>> perfectly fine here. |
45 |
>> |
46 |
>> One could thus also link GLSA issues to specific USE flags, taking |
47 |
>> asterisk again, let's say the problem is with the http web server having |
48 |
>> a buffer overflow in the http basic authenticator, then if that embedded |
49 |
>> server isn't even compiled in, how can the package be vulnerable? So |
50 |
>> here vulnerable would be something like |
51 |
>> <net-misc/asterisk-16.X.Y:16[http], <net-misc/asterisk-18.A.B[http], |
52 |
>> which then also indicates the "fixed" versions, as has been pointed out |
53 |
>> "affected" and "not affected" are inverses. |
54 |
> The "atom" attribute of each constraint is using atom syntax, so along |
55 |
> with that we get the ability to specify USE exactly like |
56 |
> "asterisk-16.X.Y:16[http]". |
57 |
> |
58 |
>> A mechanism to QUERY which installed packages are affected by known |
59 |
>> GLSA's would also be tremendously helpful. |
60 |
> Like glsa-check? |
61 |
We currently use that, but it really just says which GLSAs are |
62 |
applicable to the system, it doesn't tell me net-misc/asterisk-16.0.1:16 |
63 |
- we've got ways of working from the glsa-check output to that. Of |
64 |
particular annoyance if a GLSA lists multiple packages, of which you |
65 |
have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I can |
66 |
quite quickly determine that emerge -1av net-misc/asterisk:16 will |
67 |
resolve the problem with the lowest possible risk of breakage to other |
68 |
components on the system, and without having to perform a full update. |
69 |
>>> Multiple vulnerabilities have been discovered in $PACKAGE. Please |
70 |
>>> review the CVE identifiers referenced below for details. |
71 |
>>> |
72 |
>>> ... simply because it's infeasible (and in my opinion, not really |
73 |
>>> necessary) for us to enumerate the issues in this way. Also, I note |
74 |
>>> that the section being called "impact" doesn't preclude us from |
75 |
>>> incorporating text that we would currently put in the "description" or |
76 |
>>> "synopsis" fields. |
77 |
>> Of course giving the full details in the GLSA is a pain in the backside, |
78 |
>> is there a way to retrieve this information automatically from the CVE |
79 |
>> database? In other words, just get the blurp from there and include it |
80 |
>> here. It won't give full details, but at least it will give some extra |
81 |
>> details not currently available. Effectively we choose to ignore |
82 |
>> certain GLSAs if we consider their impact to be low. |
83 |
> We could import CVE descriptions, but then we'd end up with a huge |
84 |
> wall of mostly useless text, such as CVE-2021-35648's: |
85 |
> |
86 |
> Vulnerability in the MySQL Server product of Oracle MySQL (component: |
87 |
> Server: FTS). Supported versions that are affected are 8.0.26 and |
88 |
> prior. Easily exploitable vulnerability allows high privileged |
89 |
> attacker with network access via multiple protocols to compromise |
90 |
> MySQL Server. Successful attacks of this vulnerability can result in |
91 |
> unauthorized ability to cause a hang or frequently repeatable crash |
92 |
> (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability |
93 |
> impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). |
94 |
> |
95 |
> MySQL bugs usually have dozens of CVEs associated with them. Would it |
96 |
> really be useful to have dozens of those paragraphs in GLSAs? Would it |
97 |
> be useful to have that text included in a GLSA for MariaDB or |
98 |
> PostgreSQL if they're affected by the same issue? |
99 |
> |
100 |
> On the other end of the spectrum (CVE-2022-41035): |
101 |
> |
102 |
> Microsoft Edge (Chromium-based) Spoofing Vulnerability. |
103 |
> |
104 |
> Does that tell anyone anything about the vulnerability? Not really, I |
105 |
> think. It'd just be added noise in a GLSA. |
106 |
|
107 |
Fair. Both those descriptions can be significantly better. |
108 |
|
109 |
> |
110 |
>> It would also help a great deal to automate that if the CVE scores and |
111 |
>> the "inputs" into that could be made available, eg, CVE score 7.0, |
112 |
>> remote=yes/no, .... (And I'm fairly certain importing this from the CVE |
113 |
>> database should be possible). |
114 |
> It is possible, but is it really useful? CVSS scores are really |
115 |
> just arbitrary numbers produced by CNAs (just like descriptions are |
116 |
> arbitrary text). Even worse, sometimes the CNA changes the CVSS score, |
117 |
> so if we reproduce it into GLSAs, would we have to keep track of any |
118 |
> changes and update the GLSA accordingly? |
119 |
Not quite arbitrary, there is supposed to be a set of input variables |
120 |
that is from what I recall yes/no in nature (eg, directly remotely |
121 |
exploitable, require auth to exploit etc ...) that factors into a |
122 |
formula that generates the score. The Chromium one above I note has |
123 |
been manually adjusted the severity to moderate in spite of the |
124 |
calculated base score being 8.2. |
125 |
> |
126 |
> The CVE IDs are already exposed by the GLSA as references.uri |
127 |
> fields. From those, it'd be trivial to automate the retrieval of the |
128 |
> CVE data from their authoritative sources (e.g. NIST's NVD API [1] or |
129 |
> cvelist.git itself [2]). But, maybe it would be useful to have a |
130 |
> "type" attribute in the uri field indicating what kind of identifier |
131 |
> it is (whether CVE, WSA, XSA, etc), and then other tools could more |
132 |
> easily grok each kind of reference. |
133 |
|
134 |
Yes, so glsa-check -cl already provides the CVE id's, and yes, given the |
135 |
API url or git repo this can be automated, but why not have glsa-check |
136 |
do that? Ie, if I do glsa-check -cd 202211-?? then that additional |
137 |
information can be retrieved and dumped too. It would be helpful if at |
138 |
least some of this information could be automatically pulled in and |
139 |
displayed without having to build further tooling: |
140 |
|
141 |
$ curl https jqservices.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2022-41035 |
142 |
|
143 |
In particular this is useful: |
144 |
|
145 |
{ |
146 |
"source": "secure@×××××××××.com", |
147 |
"type": "Primary", |
148 |
"cvssData": { |
149 |
"version": "3.1", |
150 |
"vectorString": |
151 |
"CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H", |
152 |
"attackVector": "NETWORK", |
153 |
"attackComplexity": "HIGH", |
154 |
"privilegesRequired": "NONE", |
155 |
"userInteraction": "REQUIRED", |
156 |
"scope": "CHANGED", |
157 |
"confidentialityImpact": "HIGH", |
158 |
"integrityImpact": "HIGH", |
159 |
"availabilityImpact": "HIGH", |
160 |
"baseScore": 8.3, |
161 |
"baseSeverity": "HIGH" |
162 |
}, |
163 |
"exploitabilityScore": 1.6, |
164 |
"impactScore": 6.0 |
165 |
}, |
166 |
|
167 |
Even this potentially, which really gives somewhat more information than |
168 |
the CVE itself (in this case at least): |
169 |
|
170 |
"references": [ |
171 |
{ |
172 |
"url": |
173 |
"https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41035", |
174 |
"source": "secure@×××××××××.com", |
175 |
"tags": [ |
176 |
"Patch", |
177 |
"Vendor Advisory" |
178 |
] |
179 |
}, |
180 |
{ |
181 |
"url": "https://security.gentoo.org/glsa/202210-16", |
182 |
"source": "secure@×××××××××.com" |
183 |
} |
184 |
] |
185 |
|
186 |
Obviously the gentoo link doesn't really help, but the former gives good |
187 |
details lower down. |
188 |
|
189 |
So perhaps rather than storing reference links one could store: |
190 |
|
191 |
<references> |
192 |
<cve>CVE-2022-41035</cve> |
193 |
<url>https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41035</url> |
194 |
</references> |
195 |
|
196 |
Retrieving the CVSS details like above can then at a later stage go into |
197 |
tooling, for now just converting <cve> into "another URL" for display is |
198 |
fine, this doesn't step back, but allows for future changes to utilize |
199 |
the API calls to retrieve more details from the CVE itself for display |
200 |
as part of the dump (which would then obviously always display the |
201 |
latest information). |
202 |
|
203 |
> [1] https://nvd.nist.gov/developers/vulnerabilities |
204 |
> [2] https://github.com/CVEProject/cvelist |
205 |
> |
206 |
Kind Regards, |
207 |
Jaco |