home tags events about login
one honk maybe more

benjojo posted 15 May 2026 12:30 +0000

It seems relatively clear at this point that we (the wider industry) now have an extremely good C/C++ linters, with the only downside that they are expensive (relative to previous tools) to run.

Much like the "if your company depends on running other people's x86 code, then Spectre/Meltdown/etc are devastating", I think if your company is/was depending on the user separation boundaries in the OS to work, then you are in a lot of trouble.

[Unauth'd file read/Local Priv Esc]'s have always kind of been low(er) hanging fruit, but they are nowhere near as cool/good at RCEs.

Now that we have machines to find these at reasonable competence and speed, it is probably a good time to look at anything that you run that [processes user supplied data, or speaks over the network] that is written in C/C++ and find memory safe alternatives. It's not those memory safe alternatives are going to be bug free, but they are far less likely to cause you to need to upgrade your kernel every few days to urgently catch up with local LPE's

Even if you are not going to use the new auditing systems for whatever reason, the "enemy" (whether that is your intelligence agencies, ransom gangs, etc) will have no problem trading a few 100$ for what used to cost $10,000's to do.

benjojo replied 15 May 2026 12:26 +0000
in reply to: https://mas.to/users/srtcd424/statuses/116578568691048319

@srtcd424 To be fair a lot of the CPU Vulns are not a (paraphrased) " Hello, here is a 1M lines of C code can you find problems? " type of problem.

But yes, it was a bold assumption that hardware virtualisation totally sealed away from other guests, I think/suspect proponents of such technology decided to overlook it because for most people other than AWS/Azure/etc a data side channel between VM guests is not company breaking

benjojo replied 15 May 2026 12:10 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/l2zQ9zj13286CD5zXt

In related news, I am happy to have just finished moving away from OpenSMTPd, there are basically only 2 C/C++ components left in the whole of bgp.tools stack that speak to things over the internet:

Unbound DNS

(which has recently eaten a bunch of vulns)

rpki_client

(which I need to figure out a good solution for, because I depend on a bunch of it's quirks, the solution probably being extreme bomb proofing of the container/vm/whatever)

benjojo replied 15 May 2026 12:23 +0000
in reply to: https://mastodon.social/users/madduci/statuses/116578559056385118

@madduci Yeah I mean, I do trust the OpenBSD people to probably write better C than others, but I've have had (and now somewhat vindicated) this view that it's almost impossible to write 100% safe C when you consider the wider ecosystem, and if there are alternatives that don't run that risk, then what are we doing...