6 ms·

Heap Overflow in OpenBSD's Slaacd via Router Advertisement

55 points by gray_charger 5y ago

gjadi 5y ago
> The OpenBSD team states that they consider that the vulnerability would be exploitable if there weren't severe privilege separation and pledge involved. Yay!
- Rendello 5y 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-SerenityOS/ https://awesomekling.github.io/pledge-and-unveil-in-Serenity...
  - zibzab 5y 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.
    - Rendello 5y 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 https://www.youtube.com/watch?v=F_7S1eqKsFk
_wldu 5y ago
I wonder if the OpenBSD team would be open to Go or Rust implementations?
- steveklabnik 5y ago
  Unlikely, at least for Rust.
- perihelions 5y ago
  Here's a long thread about that (the short answer is "no"), https://news.ycombinator.com/item?id=23059477 https://news.ycombinator.com/item?id=23059477 ("Theo de Raadt on Rust" / "Integrating "safe" languages into OpenBSD?", 389 comments)
- flatiron 5y 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.
  - volkadav 5y 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)
    - IcePic 5y 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.
  - snvzz 5y 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.
    - flatiron 5y 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
jeffbee 5y ago
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
- pjmlp 5y ago
  Battling that trumpet since 1994, but here we are, with enough systems still using bare bones C.
- jstimpfle 5y 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.
  - jeffbee 5y 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.
    - jstimpfle 5y 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.
jms703 5y ago
I love the fast turnaround time from the report to the release of the patch.
somat 5y 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_slaacd.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/7.0/common/017_s... Honestly, I like their attitude when it comes to deleting code.

55 points by gray_charger 5y ago

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

Rendello 5y 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-SerenityOS/ https://awesomekling.github.io/pledge-and-unveil-in-Serenity...
- zibzab 5y 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.
  - Rendello 5y 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 https://www.youtube.com/watch?v=F_7S1eqKsFk

_wldu 5y ago

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

steveklabnik 5y ago
Unlikely, at least for Rust.
perihelions 5y ago
Here's a long thread about that (the short answer is "no"), https://news.ycombinator.com/item?id=23059477 https://news.ycombinator.com/item?id=23059477 ("Theo de Raadt on Rust" / "Integrating "safe" languages into OpenBSD?", 389 comments)
flatiron 5y 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.
- volkadav 5y 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)
  - IcePic 5y 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.
- snvzz 5y 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.
  - flatiron 5y 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

jeffbee 5y ago

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

pjmlp 5y ago
Battling that trumpet since 1994, but here we are, with enough systems still using bare bones C.
jstimpfle 5y 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.
- jeffbee 5y 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.
  - jstimpfle 5y 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.

jms703 5y ago

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

somat 5y 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_slaacd.patch.sig https://ftp.openbsd.org/pub/OpenBSD/patches/7.0/common/017_s... Honestly, I like their attitude when it comes to deleting code.