4 ms·

"... I'm not smart enough to write C code that deals with hostile data off the network." I just don't believe you for one minute. It's quite easy to guard agai

"... I'm not smart enough to write C code that deals with hostile data off the network." I just don't believe you for one minute. It's quite easy to guard against unwanted memory access over serial ports and sockets. You have to know the size of the buffer, but that's just not hard. If you go throwing pointers-as-if-they-were-tokens/handles around and blindly following them, you'll get in trouble. So don't do that. If you constrain operation only to valid data ( which isn't all that difficult ) then ( and I ask out of ignorance ), how can they hurt you? What do I mean by "constrain operation..." yadda yadda? I mean if somebody "misspells" something, you dump the input. Your recognizer accepts only valid tokens. Usually, the tokens are in a table, with an FSM knitting them together. So the table can be wrong, or the FSM can be wrong. That's it. Recently, all commands were in a simple subset of XML ( by the customer's choice ). That was particularly easy. I grew up in environmentally hostile environments where you'd lose things like PHY chips and serial port drivers, so this was how it was done. If you mean exploits in the O/S itself, then yeah - I agree. But then my choice of language is irrelevant. I won't disagree about the C compiler thing, but that shouldn't be at issue here.

steveklabnik 10y ago
> I just don't believe you for one minute. The author demonstrated this by pointing to a list of CVEs caused by their code, so.
- ArkyBeagle 10y ago
  I understand that completely. "Doing it wrong" is simply a choice that has been made.
  - MaulingMonkey 10y ago
    To err is human. Beyond the scope of simple, small, toy programs - "doing it wrong" is not a choice, it is a statistic. You do have choices to make in terms of techniques and tools you can apply (assuming you're aware of them) to modify the statistics, but you will not be perfect in your application of them, and the tools were not written by perfect people either. There's another choice here - how high you set the security bar for "deals with hostile data off the network". Ekidd chose to set this bar high enough to rule out C. How high do you set it?
- ekidd 10y ago
  Not technically my code, and that's the part I don't know how to fix. I used every security technique I knew of back then, including extensive unit tests, manual auditing, malloc debuggers (including Electric Fence), and pretty much every open source tool that was well-known in 2000. I'm sure a modern fuzzer could find some errors, particularly integer overflows, because this was 32-bit code and I didn't understand some modern exploitation tricks. But as hard as I tried, I still failed, because I relied on 3rd-party code (by an extremely talented programmer), and he made mistakes. Perfection is not a scalable strategy.

steveklabnik 10y ago

> I just don't believe you for one minute. The author demonstrated this by pointing to a list of CVEs caused by their code, so.

ArkyBeagle 10y ago
I understand that completely. "Doing it wrong" is simply a choice that has been made.
- MaulingMonkey 10y ago
  To err is human. Beyond the scope of simple, small, toy programs - "doing it wrong" is not a choice, it is a statistic. You do have choices to make in terms of techniques and tools you can apply (assuming you're aware of them) to modify the statistics, but you will not be perfect in your application of them, and the tools were not written by perfect people either. There's another choice here - how high you set the security bar for "deals with hostile data off the network". Ekidd chose to set this bar high enough to rule out C. How high do you set it?
ekidd 10y ago
Not technically my code, and that's the part I don't know how to fix. I used every security technique I knew of back then, including extensive unit tests, manual auditing, malloc debuggers (including Electric Fence), and pretty much every open source tool that was well-known in 2000. I'm sure a modern fuzzer could find some errors, particularly integer overflows, because this was 32-bit code and I didn't understand some modern exploitation tricks. But as hard as I tried, I still failed, because I relied on 3rd-party code (by an extremely talented programmer), and he made mistakes. Perfection is not a scalable strategy.