From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 5BEF4158020 for ; Thu, 10 Nov 2022 20:07:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 79760E0A43; Thu, 10 Nov 2022 20:07:23 +0000 (UTC) Received: from uriel.iewc.co.za (uriel.iewc.co.za [IPv6:2c0f:f720:0:3::9a49:2248]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 14D8FE089A for ; Thu, 10 Nov 2022 20:07:22 +0000 (UTC) Received: from [2c0f:f720:fe0c:7900::1] (helo=tauri.local.uls.co.za) by uriel.iewc.co.za with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1otDpV-00021L-AG; Thu, 10 Nov 2022 22:07:17 +0200 Received: from [192.168.42.209] by tauri.local.uls.co.za with esmtp (Exim 4.94.2) (envelope-from ) id 1otDpS-0002wX-9e; Thu, 10 Nov 2022 22:07:15 +0200 Message-ID: <9f40eb94-8c0b-db72-e004-53bce39f9b88@uls.co.za> Date: Thu, 10 Nov 2022 22:07:13 +0200 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [gentoo-dev] [RFC] A new GLSA schema Content-Language: en-GB To: gentoo-dev@lists.gentoo.org, John Helmert III References: <39df0838-8dc0-4775-3b66-b7e7d14150dd@uls.co.za> From: Jaco Kroon Organization: Ultimate Linux Solutions (Pty) Ltd In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-report: Relay access (uriel.iewc.co.za). X-Archives-Salt: ed3325c5-420c-49ee-9c62-46f3cd77b388 X-Archives-Hash: 510668ba86decbf75a2c61b0337ac76b Hi, On 2022/11/10 16:24, John Helmert III wrote: > On Thu, Nov 10, 2022 at 10:43:55AM +0200, Jaco Kroon wrote: >> Hi, >> >> On 2022/11/10 06:13, John Helmert III wrote: >>>>>  - Drop synopsis and description fields. These fields contain the same >>>>>    information and will be superceded by the existing impact field. >>>> Well, I'm not saying "no" but it feels a bit weird reading a GLSA that >>>> doesn't say a word what the problem is but specifies impact. >>> You're right, but with 19 CVEs (for example), is anyone really >>> interested in hearing about the problem that caused each of the 19 >>> issues? In the current format we've resorted to writing descriptions >>> like... >> Actually yes!  Also a way to check whether my specific configuration is >> vulnerable for this specific CVE, something like "If you're setting >> foo=bar in /etc/pkg.conf your system is vulnerable, if you've got >> foo=phew you're most likely fine".  Obviously we could rely a bit more >> on package maintainers (myself included) to provide these. > That would greatly increase the care necessary for us to release a > GLSA. It's already a big pain (even with the new GLSAMaker being a > huge improvement over the old one), and I'd like to make it less of a > pain. Maybe a proxy for this information for you would be the "type" > field of the impact? Fair enough at pain.  Limited people, limited resources.  I do think that package maintainers should get involved in the process though, to help provide this information, but this should not cause delays in getting the GLSAs released.  Even if the GLSA gets updated on a future iteration to add some of this information. What I'm after is being able to quickly decide (since we sometimes see a fair number of of GLSAs coming in around the same time, affecting different systems, with variable degrees of "exposedness" and need to be able to prioritise which systems to update first) whether we can (relatively) safely ignore a GLSA (at least temporarily). > >> I don't think I've seen a single "workaround" and usually the text here >> just says "No known workaround", where the reality is that for something >> like asterisk just not using the affected module is good enough.  So >> workaround:  "Don't use chan_sip, use chan_pjsip instead" would be >> perfectly fine here. >> >> One could thus also link GLSA issues to specific USE flags, taking >> asterisk again, let's say the problem is with the http web server having >> a buffer overflow in the http basic authenticator, then if that embedded >> server isn't even compiled in, how can the package be vulnerable?  So >> here vulnerable would be something like >> > which then also indicates the "fixed" versions, as has been pointed out >> "affected" and "not affected" are inverses. > The "atom" attribute of each constraint is using atom syntax, so along > with that we get the ability to specify USE exactly like > "asterisk-16.X.Y:16[http]". > >> A mechanism to QUERY which installed packages are affected by known >> GLSA's would also be tremendously helpful. > Like glsa-check? We currently use that, but it really just says which GLSAs are applicable to the system, it doesn't tell me net-misc/asterisk-16.0.1:16 - we've got ways of working from the glsa-check output to that.  Of particular annoyance if a GLSA lists multiple packages, of which you have one installed, and one not. Given net-misc/asterisk-16.0.1:16 I can quite quickly determine that emerge -1av net-misc/asterisk:16 will resolve the problem with the lowest possible risk of breakage to other components on the system, and without having to perform a full update. >>> Multiple vulnerabilities have been discovered in $PACKAGE. Please >>> review the CVE identifiers referenced below for details. >>> >>> ... simply because it's infeasible (and in my opinion, not really >>> necessary) for us to enumerate the issues in this way. Also, I note >>> that the section being called "impact" doesn't preclude us from >>> incorporating text that we would currently put in the "description" or >>> "synopsis" fields. >> Of course giving the full details in the GLSA is a pain in the backside, >> is there a way to retrieve this information automatically from the CVE >> database?  In other words, just get the blurp from there and include it >> here.  It won't give full details, but at least it will give some extra >> details not currently available.  Effectively we choose to ignore >> certain GLSAs if we consider their impact to be low. > We could import CVE descriptions, but then we'd end up with a huge > wall of mostly useless text, such as CVE-2021-35648's: > > Vulnerability in the MySQL Server product of Oracle MySQL (component: > Server: FTS). Supported versions that are affected are 8.0.26 and > prior. Easily exploitable vulnerability allows high privileged > attacker with network access via multiple protocols to compromise > MySQL Server. Successful attacks of this vulnerability can result in > unauthorized ability to cause a hang or frequently repeatable crash > (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability > impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). > > MySQL bugs usually have dozens of CVEs associated with them. Would it > really be useful to have dozens of those paragraphs in GLSAs? Would it > be useful to have that text included in a GLSA for MariaDB or > PostgreSQL if they're affected by the same issue? > > On the other end of the spectrum (CVE-2022-41035): > > Microsoft Edge (Chromium-based) Spoofing Vulnerability. > > Does that tell anyone anything about the vulnerability? Not really, I > think. It'd just be added noise in a GLSA. Fair.  Both those descriptions can be significantly better. > >> It would also help a great deal to automate that if the CVE scores and >> the "inputs" into that could be made available, eg, CVE score 7.0, >> remote=yes/no, .... (And I'm fairly certain importing this from the CVE >> database should be possible). > It is possible, but is it really useful? CVSS scores are really > just arbitrary numbers produced by CNAs (just like descriptions are > arbitrary text). Even worse, sometimes the CNA changes the CVSS score, > so if we reproduce it into GLSAs, would we have to keep track of any > changes and update the GLSA accordingly? Not quite arbitrary, there is supposed to be a set of input variables that is from what I recall yes/no in nature (eg, directly remotely exploitable, require auth to exploit etc ...) that factors into a formula that generates the score.  The Chromium one above I note has been manually adjusted the severity to moderate in spite of the calculated base score being 8.2. > > The CVE IDs are already exposed by the GLSA as references.uri > fields. From those, it'd be trivial to automate the retrieval of the > CVE data from their authoritative sources (e.g. NIST's NVD API [1] or > cvelist.git itself [2]). But, maybe it would be useful to have a > "type" attribute in the uri field indicating what kind of identifier > it is (whether CVE, WSA, XSA, etc), and then other tools could more > easily grok each kind of reference. Yes, so glsa-check -cl already provides the CVE id's, and yes, given the API url or git repo this can be automated, but why not have glsa-check do that?  Ie, if I do glsa-check -cd 202211-?? then that additional information can be retrieved and dumped too. It would be helpful if at least some of this information could be automatically pulled in and displayed without having to build further tooling: $ curl https jqservices.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2022-41035 In particular this is useful:             {               "source": "secure@microsoft.com",               "type": "Primary",               "cvssData": {                 "version": "3.1",                 "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",                 "attackVector": "NETWORK",                 "attackComplexity": "HIGH",                 "privilegesRequired": "NONE",                 "userInteraction": "REQUIRED",                 "scope": "CHANGED",                 "confidentialityImpact": "HIGH",                 "integrityImpact": "HIGH",                 "availabilityImpact": "HIGH",                 "baseScore": 8.3,                 "baseSeverity": "HIGH"               },               "exploitabilityScore": 1.6,               "impactScore": 6.0             }, Even this potentially, which really gives somewhat more information than the CVE itself (in this case at least):         "references": [           {             "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41035",             "source": "secure@microsoft.com",             "tags": [               "Patch",               "Vendor Advisory"             ]           },           {             "url": "https://security.gentoo.org/glsa/202210-16",             "source": "secure@microsoft.com"           }         ] Obviously the gentoo link doesn't really help, but the former gives good details lower down. So perhaps rather than storing reference links one could store:    CVE-2022-41035 https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-41035 Retrieving the CVSS details like above can then at a later stage go into tooling, for now just converting into "another URL" for display is fine, this doesn't step back, but allows for future changes to utilize the API calls to retrieve more details from the CVE itself for display as part of the dump (which would then obviously always display the latest information). > [1] https://nvd.nist.gov/developers/vulnerabilities > [2] https://github.com/CVEProject/cvelist > Kind Regards, Jaco