
Categorizing OpenBSD Bugs - Supermighty
https://www.collicutt.co.uk/notebook/openbsd_bugs.html
======
AndyMcConachie
This is good research. Thank you for doing this.

------
comex
This is a good analysis. However, I think it's illuminating to categorize the
security fixes in terms of consequences and severity.

Well, before that, two nitpicks...

\- First, many errata are missing from the list entirely! This includes 6.1
032-039, 6.2 011-024, and 6.3 020-021 and 023-032, based on [1]. (All from 6.4
are accounted for.) The blog post was published today, so I don't know why
they are missing. I only noticed this when I was preparing to submit my
comment here, so I have _not_ gone back and tried to recategorize those
myself, and I don't know how they'd affect the analysis.

\- 6.1 021 and 6.1 022 are both marked "uninitialized value used", which is
another class of errors which Rust fully prevents and which is highly related
to memory safety (because using an uninitialized value, if the value is or
contains a pointer, can violate memory safety). Adding those to the "memory"
category brings the count up to 14.

Now for my categorization:

==========================

(﹡ denotes a memory safety bug, and the fractions listed are of memory safety
bugs.)

 _Low severity_

Memory leak (i.e. memory is not freed) (1/3): 6.1 024﹡, 6.1 028(?), 6.4 013

General-purpose mitigations (requires another bug to exploit) (0/2): 6.1 008,
6.1 026

(Group total: 1/5)

 _Medium severity_

Kernel info leak (5/7): 6.1 021﹡, 6.1 022﹡, 6.1 017﹡, 6.1 018, 6.1 020﹡, 6.1
025﹡, 6.1 031

Other-userland-process info leak (0/2): 6.3 017, 6.4 011

(Group total: 5/9)

 _High severity (local)_

Kernel integrity against local user (2/6): 6.1 002, 6.1 011﹡, 6.3 019, 6.3
015(?), 6.4 010﹡, 6.4 016

Other-userland-process integrity against local user (0/4): 6.1 010, 6.2 002,
6.3 011, 6.4 001

Network safety against local user (0/2): 6.3 009, 6.3 022

(Group total: 2/12)

 _High severity (possibly remote)_

Kernel integrity against remote user (2/2): 6.2 007﹡, 6.3 004﹡

Same-userland-process integrity with malformed input (3/3): 6.1 007﹡, 6.3
001﹡, 6.4 005﹡

Network safety against remote user (0/3): 6.1 003, 6.1 027, 6.2 008

(Group total: 5/8)

 _Other_

Mitigations for newly discovered hardware side channel vulnerabilities (0/5):
6.2 009, 6.3 010, 6.3 014, 6.3 018, 6.4 003

Unknown (0/3): 6.1 019, 6.4 014, 6.4 015

(Group total: 0/8)

(Overall total: 13/42)

==========================

Notes:

\- I put hardware side channel vulnerabilities under "other" because they're
not really security flaws in OpenBSD, per se, but in the processor. You might
dispute this characterization.

\- I divided high severity into local (i.e. low-privileged user wants more
privilege) and possibly remote, but didn't bother to do the same for the other
severities.

\- Within high severity overall, memory safety issues comprised 7/20 (35%) of
errata, similar to the overall rate of 13/42 (31%).

\- However, within the high severity _potentially-remote_ group, memory safety
issues compromised 5/8 (62.5%) of errata! That includes two issues in kernel
network drivers parsing incoming packets, one issue in FreeType, and two in
Perl.

\- "Network safety" included issues in LibreSSL, WPA, and DNSSEC. "Network
safety against local user" refers to two timing side-channel bugs in LibreSSL
that could leak keys (and were not Spectre/Meltdown related).

\- Unsurprisingly, "same-userland-process integrity" is made up entirely of
memory safety issues because there's little other way to specifically
compromise one's own process.

\- On the other hand, "kernel integrity" is split evenly between memory and
non-memory issues, which is not surprising because much of the logic in a
kernel is dedicated to either enforcing security boundaries or setting up
hardware that enforces security boundaries.

\- "Other-userland-process integrity against local user" included a Perl issue
which seemed unlikely to be exploitable remotely, though it might be possible
(required messing with file permissions), an Xorg issue that allowed
escalating privileges (because Xorg is setuid), and a kernel issue that
apparently allowed improper tracing of other processes. (It seems like the
tracing may only have allowed reads, so it might belong in the info-leak
category, but it's a much more severe leak than the others in that category.)

\- To be fair, most of the code that you typically see being remotely
exploited in practice, web application backend stuff, is not represented in
this list, presumably because it's simply not part of OpenBSD proper. That
code tends to be written in memory safe languages and so the vulnerabilities
in in it tend to be things other than memory safety; thus, if the question is
"what percentage of remotely exploitable vulnerabilities on servers involve
memory safety", the 62.5% above is way too high. But that doesn't disprove the
assertion that memory safe languages are, well, safer; it only shows that
memory safety isn't a panacea, but if the same kind of low-quality code were
written in C or even C++, I'm sure you'd seen tons of memory safety
vulnerabilities. In any case, if the question is rather how much _the OpenBSD
project_ should worry about memory safety, it does make sense to limit the
investigation to code within OpenBSD.

[1]
[https://www.openbsd.org/errata61.html](https://www.openbsd.org/errata61.html)

~~~
0xcac04
None of the errata are missing. You are double counting: OpenBSD supports the
last two releases simultaneously, so later errata for one release are also
early errata for the next.

~~~
comex
Ah, thanks for the correction.

