You folks have a favorite type/buffer safe language for doing packet decoding, time math, and cert decoding kinds of things? Or are we still bit banging and trying not to F it up?
Conversation
"Packet decoding" can be done safely in any language, and unsafely in any language. The idea that a language is either needed or sufficient for packet decoding is wrong. Memory safe languages are needed, but not for packet decoding.
2
3
2
For example, somebody decided to write a "safe" DNS server in Rust (a memory safe language). And then it had a buffer overflow in parsing "name compression recursion" -- which is the most obvious and frequent bug in DNS packet decoding.
4
3
2
It's fine to make a mistake about this, but now that you know that all Rust builds have robust checks for stack overflow, you should tweet a correction.
2
1
17
I don’t know rust, at least not yet. I’m curious what it is able to do with running out of stack due to recursion that is meaningfully different from just failing to allocate more stack memory.
1
1
It can fail cleanly and stop executing the thread, rather than trampling on memory the other side of the stack and causing security problems.
2
8
Ok, so it used to blow past the end of the stack. Thanks for the info.
1
No, I think before stack probes there used to be an explicit check for enough space at allocation time.
1
4
There was a window of time where it was unsafe due to a bad decision to prematurely drop the legacy approach before the replacement was deployed across all platforms. However, that was a long time ago, and it's definitely safe across platforms now. It was an old historical issue.
2
1
It's also important to note that there was always a guard page at the bottom of the stack, so most stack overflows were always reliably caught on normal platforms. Originally, all edge cases were also caught due to the explicit checks. Typical stack exhaustion was never unsafe.
1
The issue was that stack probes were not being generated by LLVM on non-Windows platforms yet when the explicit checks were dropped in favour of stack probes. It was known this was an issue, and I don't understand why it was decided to have a window of time where this was broken.
Stack probes are needed to catch overflows overshooting the guard page, due to having more than a page worth of data on the stack that's untouched before later data is used. By the way, this is still an issue for Clang and most other LLVM frontends on non-Windows platforms...