haiku
security: Improve our posture to announce critical CVEs
- I think we should only commit to critical severity disclosures given the size of our team.
xz_utils is generally a build-package, so will always be pre-installed in stable versions of Haiku. As pkgman updates update installed packages, all users without installing additional software can have the problematic xz_utils installed.
With that said, pretty much every operating system distribution documents CVE's.
- https://security.archlinux.org/CVE-2024-3094
- https://access.redhat.com/security/cve/CVE-2024-3094
- https://security-tracker.debian.org/tracker/CVE-2024-3094
- https://people.canonical.com/~ubuntu-security/cve/CVE-2024-3094
- https://www.suse.com/security/cve/CVE-2024-3094
- https://security.alpinelinux.org/vuln/CVE-2024-3094
- https://advisories.mageia.org/CVE-2024-3094.html
However, all of those operating systems can be servers, host sensitive data, etc. I think the bare minimum we can do as a desktop operating system where "everyone is root" is get in the habit of documenting critical severity CVE's (especially in build-packages)
+1 for the content, though I wonder if this happens/will happen often enough to get its own segment, or whether (for now) this particular announcement should just be a news article.
I am not saying that we should not try to implement better security practices, but elevating this to a special process might be perceived as making promises that we cannot keep.
Yes, I'm not sure about this either. Are we actually monitoring new CVEs to decide if and how we are affected, or is it just "this is frontpage news on every website, so we should probably check on our side?"
And I also agree that this would be largely a haikuports problem, but still, Haiku users end up pretty directly affected (even more so because there isn't any kind of stable release, so the problems get directly into user's installs).
I guess at least the page should be clear about this: these are the big issues we know about, but we are not currently set up to actively watch for new problems (as far as I know, at least?). And so the list is likely to be incomplete.
Yes, I'm not sure about this either. Are we actually monitoring new CVEs to decide if and how we are affected, or is it just "this is frontpage news on every website, so we should probably check on our side?"
Yup. This was actually a concern I had moving into it. One big reason for this is we might want to issue additional updates / guidance on steps users should take. Today, our only route seems to be sending additional emails to the haiku-security mailing list.
I guess at least the page should be clear about this: these are the big issues we know about, but we are not currently set up to actively watch for new problems (as far as I know, at least?). And so the list is likely to be incomplete.
I agree with this. It's why i used "critical" severity in a lot of places. I don't think our team is big enough to document every CVE that comes along in the thousands of HaikuPorts, however we should at minimum document the "big scary ones" that are critical or above (especially in build-packages which everyone has pre-installed)
In addition to all of this, maybe we want someone to assume a titled security officer role within the project? We could generate a new email ([email protected]) and have it forwarded to the "on-call" security person.
Hobby or not, we are an operating system. Providing tracking and notification of severe security events is likely the bare minimum we should be doing.
Fun side note going off topic. There's a filter on the US NVD that allows you to search based on a CPE (identifier for a piece of software)
As an example, the CPE for tar is:
cpe:2.3:a:gnu:tar:-:*:*:*:*:*:*:*
An example for the CPE for tar 1.11.8 is:
cpe:2.3:a:gnu:tar:1.11.8:*:*:*:*:*:*:*
Theoretically, we could add a NVD_CPE="cpe:2.3:a:gnu:tar:${packageVersion}::::::" to the tar recipe, and show known CVE's at build via haikuporter...
$ curl https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:gnu:tar:1.11.8:*:*:*:*:*:*:* | jq '.vulnerabilities.[].cve | .id + ", " + .published'```
"CVE-2001-1267, 2001-07-12T04:00:00.000"
"CVE-2002-1216, 2002-10-28T05:00:00.000"
"CVE-2007-4476, 2007-09-05T01:17:00.000"
"CVE-2010-0624, 2010-03-15T13:28:25.777"
"CVE-2018-20482, 2018-12-26T18:29:00.373"
"CVE-2019-9923, 2019-03-22T08:29:00.247"
"CVE-2021-20193, 2021-03-26T17:15:12.843"
"CVE-2022-48303, 2023-01-30T04:15:08.030"
Of course though, I can't find a CPE for xz :woozy_face:
Or, store the CPE within the hpkg as a field, then action off of it later from installed hosts :thinking:
At repology potential vulnarable packages are listed, I've tackled quite a few in the past, but there are still quit a lot listed there (not all should/can be solved). https://repology.org/projects/?search=&maintainer=&category=&inrepo=haikuports_master¬inrepo=&repos=&families=&repos_newest=&families_newest=&vulnerable=on
Maybe we start even smaller and only publicly report on security issues discovered in Haiku-only code (not imported or Haikuports)?
