3 ms·

So, I also have near zero cybersecurity expertise (I took an online intro course on cryptography due to curiousity) and no expertise in writing kernel modules a

So, I also have near zero cybersecurity expertise (I took an online intro course on cryptography due to curiousity) and no expertise in writing kernel modules actually, but why if ever would you parse an array of pointers...in a file...instead of any other way of serializing data that doesn't include hardcoded array offsets in an on-disk file... Ignore this failure which was catastrophic, this was a bad design asking to be exploited by criminals.

Jare 2y ago
Performance, I assume. Right now it may look like the wrong tradeoff, but every day in between incidents like this we're instead complaining that software is slow. Of course it doesn't have to be either/or; you can have fast + secure, but it costs a lot more to design, develop, maintain and validate. What you can't have is a "why don't they just" simple and obvious solution that makes it cheap without making it either less secure, less performant, or both. Given all the other mishaps in this story, it is very well possible that the software is insecure (we know that), slow and also still very expensive. There's a limit to how high you can push the triangle, but there's not bottom to how bad it can get.
deaddodo 2y ago
I'm curious, how else would you store direct memory offsets? No matter how you store/transmit them, eventually you're going to need those same offsets. The problem wasn't storing raw memory offsets, it was not having some way to validate the data at runtime.
- noobermin 2y ago
  You don't store direct memory offsets if possible. You have a system of handles and store the handle keys instead ofndirect pointer addresses. Yes you still need to validate the keys to avoid logic errors, but you can avoid the memory errors.
  - deaddodo 2y ago
    In this case, the direct memory addresses are literally needed. The addresses aren't being generated internal to the program, so there are no "handles". They are referencing external data by design. That's like saying "you shouldn't use a hard-coded volatile pointer to reference a hardware device". No, you literally need to do that sometimes; especially in embedded software.

Jare 2y ago

Performance, I assume. Right now it may look like the wrong tradeoff, but every day in between incidents like this we're instead complaining that software is slow. Of course it doesn't have to be either/or; you can have fast + secure, but it costs a lot more to design, develop, maintain and validate. What you can't have is a "why don't they just" simple and obvious solution that makes it cheap without making it either less secure, less performant, or both. Given all the other mishaps in this story, it is very well possible that the software is insecure (we know that), slow and also still very expensive. There's a limit to how high you can push the triangle, but there's not bottom to how bad it can get.

deaddodo 2y ago

I'm curious, how else would you store direct memory offsets? No matter how you store/transmit them, eventually you're going to need those same offsets. The problem wasn't storing raw memory offsets, it was not having some way to validate the data at runtime.

noobermin 2y ago
You don't store direct memory offsets if possible. You have a system of handles and store the handle keys instead ofndirect pointer addresses. Yes you still need to validate the keys to avoid logic errors, but you can avoid the memory errors.
- deaddodo 2y ago
  In this case, the direct memory addresses are literally needed. The addresses aren't being generated internal to the program, so there are no "handles". They are referencing external data by design. That's like saying "you shouldn't use a hard-coded volatile pointer to reference a hardware device". No, you literally need to do that sometimes; especially in embedded software.