Heap Overflow in OpenBSD's Slaacd via Router Advertisement (opens in new tab)

(blog.quarkslab.com)

55 pointsgray_charger4y ago28 comments

28 comments

20 comments · 5 top-level

_wldu4y ago· 8 in thread

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)

steveklabnik4y ago

Unlikely, at least for Rust.

flatiron4y ago

> 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.

snvzz4y ago

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.

flatiron4y ago

is there any reason they are still using i386 hardware? i can think of a million reasons to upgrade but not many to stay

4 more replies

tedunangst4y ago

Of course people are still updating.

volkadav4y ago

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)

IcePic4y ago

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.

jeffbee4y ago· 4 in thread

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

jstimpfle4y ago

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.

jeffbee4y ago

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.

jstimpfle4y ago

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.

pjmlp4y ago

Battling that trumpet since 1994, but here we are, with enough systems still using bare bones C.

gjadi4y ago· 3 in thread

> The OpenBSD team states that they consider that the vulnerability would be exploitable if there weren't severe privilege separation and pledge involved.

Yay!

Rendello4y ago

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...

zibzab4y ago

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.

Rendello4y ago

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

somat4y ago

Wow! that's a hardcore patch.

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.

jms7034y ago

I love the fast turnaround time from the report to the release of the patch.

j / k navigate · click thread line to collapse

28 comments

20 comments · 5 top-level

_wldu4y ago· 8 in thread

I wonder if the OpenBSD team would be open to Go or Rust implementations?

perihelions4y ago

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)

steveklabnik4y ago

Unlikely, at least for Rust.

flatiron4y ago

> 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.

snvzz4y ago

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.

flatiron4y ago

is there any reason they are still using i386 hardware? i can think of a million reasons to upgrade but not many to stay

4 more replies

tedunangst4y ago

Of course people are still updating.

volkadav4y ago

IcePic4y ago

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.

jeffbee4y ago· 4 in thread

https://godbolt.org/z/Mfnxq15Ma

jstimpfle4y ago

The right way to handle this might be to interpret the data as unsigned, or to handle a negative value by bailing out.

jeffbee4y ago

jstimpfle4y ago

pjmlp4y ago

Battling that trumpet since 1994, but here we are, with enough systems still using bare bones C.

gjadi4y ago· 3 in thread

> The OpenBSD team states that they consider that the vulnerability would be exploitable if there weren't severe privilege separation and pledge involved.

Yay!

Rendello4y ago

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...

zibzab4y ago

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.

Rendello4y ago

https://www.youtube.com/watch?v=F_7S1eqKsFk

somat4y ago

Wow! that's a hardcore patch.

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.

jms7034y ago

I love the fast turnaround time from the report to the release of the patch.

j / k navigate · click thread line to collapse