3 ms·
> Mixing data and code in the memory of a running program is what has lead us to every exploit involving a buffer overflow or a stack smash. Not exactly. The t
by jpr 16y ago
> Mixing data and code in the memory of a running program is what has lead us to every exploit involving a buffer overflow or a stack smash.
Not exactly. The totally unsafe programming model of C is what has caused this. Once you have untyped pointers that need not point to objects owned by your program, it is very easy to fuck something up.
> Lisp is not the only language that can build a string and throw it at an eval function.
Well, evaluating a string in (Common) Lisp just returns the string. Evaluating a symbol or list will actually do something interesting.
- wendroid 16y agoWell, you know what I mean re: the last bit, it's not just Lisp that can modify code at runtime. As for C, it's not just the fault of pointers. You just can't shellcode something that doesn't execute data. Like I say, we'd just have a different class of problems, so it's not a panacea.
- wendroid 16y agoI should also say that I have experience working with Manchester cpus (AVR microcontrollers) where the code is fixed when you flash it and you cannot jmp into RAM. Of course one then writes an interpreter instead :)