Heap Overflow in OpenBSD's Slaacd via Router Advertisement(blog.quarkslab.com)
blog.quarkslab.com
Heap Overflow in OpenBSD's Slaacd via Router Advertisement
https://blog.quarkslab.com/heap-overflow-in-openbsds-slaacd-via-router-advertisement.html
5 comments
> The OpenBSD team states that they consider that the vulnerability would be exploitable if there weren't severe privilege separation and pledge involved.
Yay!
Yay!
I'm a big fan of OpenBSD's pledge and unveil syscalls; the best overview of them is from SerenityOS' implementation:
https://awesomekling.github.io/pledge-and-unveil-in-Serenity...
https://awesomekling.github.io/pledge-and-unveil-in-Serenity...
How old is this idea?
At a conference years ago, someone proposed the idea of using this as the _only_ security mechanism in really tiny embedded systems. The implementation was 100-200 bytes in total.
At a conference years ago, someone proposed the idea of using this as the _only_ security mechanism in really tiny embedded systems. The implementation was 100-200 bytes in total.
The specific syscalls are quite new. Theo de Raadt gave this talk on pledge in 2015, and you can see that it was a bit different then. The "pledge path" feature never had a good enough API that didn't slow down the system too much, so they split that functionality into unveil a few years later.
https://www.youtube.com/watch?v=F_7S1eqKsFk
https://www.youtube.com/watch?v=F_7S1eqKsFk
I love the fast turnaround time from the report to the release of the patch.
Function is such a mess. Even C++ would clean this right up, and then you'd actually be able to read it. I'm not even going to claim this is beautiful or flawless or whatever, but to me this kind of C++ is head and shoulders above the C code in the article in terms of readability.
https://godbolt.org/z/Mfnxq15Ma
https://godbolt.org/z/Mfnxq15Ma
You can write bad code in any language. Frankly the example you linked isn't a great read either. Without being a C++ expert, I wouldn't trust the comment there - are you sure the (unsafe) "rv[skip]" can't be reordered before the ("safe") "rv.at(skip)"?
The right way to handle this might be to interpret the data as unsigned, or to handle a negative value by bailing out.
The right way to handle this might be to interpret the data as unsigned, or to handle a negative value by bailing out.
There's a lot going on here that could be improved, for example the compiler could decide that it's going to just elide the whole thing about `skip + 1 < skip` on platforms with signed char, because signed overflow is UB. My point was that in languages that aren't as primitive as C your function contains mainly just the dangerous logic, and you can read and reason about it. In the C version, it's full of noise like checking calloc return value for null, manually freeing locally-allocated memory, moving data with memcpy instead of just assignment, etc.
Yes, local allocations are a pain to maintain. But it doesn't have to be that way. You can always attach allocations to a structure and have them freed in a central place. Personally I'd rather think about what this code should do and would then think how to write in C. The big difference with C++ is the implicit stuff it does - RAII and exceptions. I have a distaste for those, and while I agree it often makes code shorter, the code also becomes more script like, it's putting some important things under the rug. For plain C, there are very elegant ways to improve most code by thinking more globally.
Battling that trumpet since 1994, but here we are, with enough systems still using bare bones C.
I wonder if the OpenBSD team would be open to Go or Rust implementations?
Here's a long thread about that (the short answer is "no"),
https://news.ycombinator.com/item?id=23059477 ("Theo de Raadt on Rust" / "Integrating "safe" languages into OpenBSD?", 389 comments)
https://news.ycombinator.com/item?id=23059477 ("Theo de Raadt on Rust" / "Integrating "safe" languages into OpenBSD?", 389 comments)
Unlikely, at least for Rust.
> Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.
is that really a reason not to use it? nobody is using i386 anymore that is updating to the latest openbsd.
is that really a reason not to use it? nobody is using i386 anymore that is updating to the latest openbsd.
does amd64 provide a benefit for virtual machines with less than 4gb of ram provisioned? (e.g. i have a small bastion host on obsd 7.0, and even 256mb of ram is slightly overkill based on what i've seen so far of resource usage)
Yes, the larger amount of cpu registers, the very much larger virtual memory space adds performance and security benefits, regardless of if you have less or more than 4G ram.
I know at least one person who's using openbsd _precisely_ because it is a low-maintenance and relatively safe option that still supports their i386 hardware.
is there any reason they are still using i386 hardware? i can think of a million reasons to upgrade but not many to stay
Not polluting the planet and being a rampant consumer for one is a very good reason not to upgrade.
If one is to actually use a computer not as a glorified web terminal, you'll find that for most things that aren't video/audio/image editing computing power really stopped being relevant after about 1998.
If one is to actually use a computer not as a glorified web terminal, you'll find that for most things that aren't video/audio/image editing computing power really stopped being relevant after about 1998.
Image editing can be fast enough on a Pentium 3/4 up to 1280x800 and imagemagick.
For audio/video, a Pentium 3 or similar would be enough with a good video card, some mplayer/mpv settings to skip the loop filter on decoding and video should be good enough up to 720p on Pentium 4 with SSE2 or pre 2010 Celerons. Celerons from 2010 and beyond can play 108p at 30FPS without sweating.
EDIT: I use Slackware and OpenBSD too :D.
Fluxbox, Rox, XTerm, Mocp, Djview, MuPDF, Groff+MS, Bitlbee+sic... you don't need a high end machine, for sure.
For Rox:
If any, you can install fbmenugen and config it to set some automatic XDG menu entries and some of them to suspend/hibernate your laptop.
For audio/video, a Pentium 3 or similar would be enough with a good video card, some mplayer/mpv settings to skip the loop filter on decoding and video should be good enough up to 720p on Pentium 4 with SSE2 or pre 2010 Celerons. Celerons from 2010 and beyond can play 108p at 30FPS without sweating.
EDIT: I use Slackware and OpenBSD too :D.
Fluxbox, Rox, XTerm, Mocp, Djview, MuPDF, Groff+MS, Bitlbee+sic... you don't need a high end machine, for sure.
For Rox:
mkdir ~/lib
cd ~/lib
git clone https://github.com/jun7/VideoThumbnail
mkdir -p ~/tmp
cd ~/tmp
git clone https://repo.or.cz/rox-lib.git
cd rox-lib
cp -r ROX-Lib2 ~/lib
If any, you can install fbmenugen and config it to set some automatic XDG menu entries and some of them to suspend/hibernate your laptop.
I still have an old G4 powermac hanging around to do most of my image and audio editing in under (gasp) OS9 no less. I can still do huge modern-pixel-count images with Photoshop 6 just fine, because I don't really care about 10bit color or whatever the hell the kids are up to these days.
But then again, we're talking about computers, not media consumption machines.
But then again, we're talking about computers, not media consumption machines.
It could be for reliability reasons as well, Something which was running for decades in a low-maintenance environment can be expected to continue doing so unlike modern semiconductors which are iterated and manufactured at very high volume that longevity is questionable.
I've been burned by semiconductors earlier due to bad design/manufacturing e.g. Pentium-D, SD 810 etc.
Also with current semiconductor shortage/supply chain issues/inflation, Anything to re-use (or) re-purpose old compute hardware is valuable to many.
I've been burned by semiconductors earlier due to bad design/manufacturing e.g. Pentium-D, SD 810 etc.
Also with current semiconductor shortage/supply chain issues/inflation, Anything to re-use (or) re-purpose old compute hardware is valuable to many.
OpenBSD runs on a lot of different platforms, and for inclusion into base it has to run on every platform. A few years ago this meant even on a VAX.
The most "obscure" platform today might be luna88k(m88k).
The most "obscure" platform today might be luna88k(m88k).
It's a laptop with a 32bit cpu. It works for its task, as well as it did when it was purchased. It uses very little power. It has an integrated UPS (laptop's battery).
There's absolutely no reason for them to retire that hardware and buy something newer to replace it.
There's absolutely no reason for them to retire that hardware and buy something newer to replace it.
Of course people are still updating.
expectation: signed vs unsigned overflow... probably a one line diff.
openbsd: ehhh... do we really need dnssl? lets tear the whole thing out.
https://ftp.openbsd.org/pub/OpenBSD/patches/7.0/common/017_s...
Honestly, I like their attitude when it comes to deleting code.