This is a good analysis. However, I think it's illuminating to categorize the security fixes in terms of consequences and severity.<p>Well, before that, two nitpicks...<p>- 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 <i>not</i> gone back and tried to recategorize those myself, and I don't know how they'd affect the analysis.<p>- 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.<p>Now for my categorization:<p>==========================<p>(﹡ denotes a memory safety bug, and the fractions listed are of memory safety bugs.)<p><i>Low severity</i><p>Memory leak (i.e. memory is not freed) (1/3): 6.1 024﹡, 6.1 028(?), 6.4 013<p>General-purpose mitigations (requires another bug to exploit) (0/2): 6.1 008, 6.1 026<p>(Group total: 1/5)<p><i>Medium severity</i><p>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<p>Other-userland-process info leak (0/2): 6.3 017, 6.4 011<p>(Group total: 5/9)<p><i>High severity (local)</i><p>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<p>Other-userland-process integrity against local user (0/4): 6.1 010, 6.2 002, 6.3 011, 6.4 001<p>Network safety against local user (0/2): 6.3 009, 6.3 022<p>(Group total: 2/12)<p><i>High severity (possibly remote)</i><p>Kernel integrity against remote user (2/2): 6.2 007﹡, 6.3 004﹡<p>Same-userland-process integrity with malformed input (3/3): 6.1 007﹡, 6.3 001﹡, 6.4 005﹡<p>Network safety against remote user (0/3): 6.1 003, 6.1 027, 6.2 008<p>(Group total: 5/8)<p><i>Other</i><p>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<p>Unknown (0/3): 6.1 019, 6.4 014, 6.4 015<p>(Group total: 0/8)<p>(Overall total: 13/42)<p>==========================<p>Notes:<p>- 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.<p>- 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.<p>- Within high severity overall, memory safety issues comprised 7/20 (35%) of errata, similar to the overall rate of 13/42 (31%).<p>- However, within the high severity <i>potentially-remote</i> 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.<p>- "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).<p>- 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.<p>- 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.<p>- "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.)<p>- 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 <i>the OpenBSD project</i> should worry about memory safety, it does make sense to limit the investigation to code within OpenBSD.<p>[1] <a href="https://www.openbsd.org/errata61.html" rel="nofollow">https://www.openbsd.org/errata61.html</a>