> 1. 'you gotta change the code'
Yes, of course this it the longterm solution.
sed 's/gets/fgets/g' :)
> 2. 'hmm. what if you change the compiler?'
This is a good for short term fixes, _IF_ you make it a switch.
for example: "gcc --bound-check ..." (Hmm, maby this is already
implemented). If somebody screams, buffer overflow in... then just
recompile, and use it until the problem is fixed.
And/or you have the ability to recompile known security risk programs
permanently (aka sendmail, or other daemon/suid) just in case.
> 3. 'ok, what about the CPU/OS kernel stack exec permission?'
Another long term fix, yes. Meanwhile, make it an kernel option.
Code should remain in "code segment", and data should remain in
"data/stack segment" [my opinion]. Some processors rely on this, as they
already have physically separated code and data memory. Hardware is
constructed with this philosophy in mind (cache, branch prediction, and so
on). It's like self modifying code... it's ugly, but fun sometimes, though
it definatley destroys more then it gains.
Real selfmodyfying artificial intelligent code might be reallity decades
in the future, but not now. When that time is, I guess we would have other
things to worry about. [sorry for the off-topic :]
If the programmers follows this philosophy too, then it should'nt be any
problem removing exec on data/stack. You could even make the code-segment
read-only, and viola, now we only have file-writing/creation/linking,
trojans, viruses, denial of service attacs and air pollution to worry
about, almost...
-|- Daniel Ryde, Tripnet AB Tel: +46 31 7252500
`-' System Administrator Fax: +46 31 7252501