Being safe on the internet (was Re: Here we go again - ISP DPI, but is it interception?)

[Tony Naggs]

Hi

I have enjoyed reading all the reminiscing about ICL and its predecessors.
Many of the stories predate my early encounters with computers, though
as a precociously geeky child I did enjoy disassembling a decommissioned
ICL terminal and studying how the logic boards worked. (Painted blue &
gray and possibly used with a 1904.) I think the only part that I actually
used was the isolating transformer - very reassuring when tinkering inside
other electronic gadgets.


All that apart, I think the discussions of software security are rather odd
for getting so hung-up on discussons of buffer overflows.


On 11 August 2010 22:23, Charles Lindsey <chl at clerew.man.ac.uk> wrote:
>
> The real solution for buffer overflow attacks is to keep the executable code
> in read-only partitions, and to forbid execution of code in data partitions.

Buffers overflows are only one class of security issue, and generally occur
in legacy code or code writen outside professional development environments.

Sadly thinking that "Read-Only" memory for code and read-write memory for data
is a solution to buffer overflow security issues is akin to thinking
an adhesive plaster
will fix a broken leg!

Often the buffer is in the stack, an overflow can be crafted to
corrupt the return
address or data used by other code in the call stack. For a notrious example
check out "Return to libc" attacks, for example here:
http://en.wikipedia.org/wiki/Return-to-libc_attack

Most corporate coding environments have protections against direct buffer
overflow attacks e.g. by having codng standards that outlaw functions such
as strcpy(), using only String classes that have intrinsic length attributes,
using static code analysis to find dodgy constructs, and using flags to the
C compiler that prevent those outlawed funcions being included.

Of course there is more that can be done, but at the end of the day it is
economics that governs things: graduate C/C++ coders are fairly cheap
and plentiful; the consequencies of shipping insecure are relatively mild,
("everybody" clearly does it); bean counters think that if there were
security issues in the last year the company is probably spending too
much on security!

> AIUI, this is routine practice in Unix, subject to suitable provisions in
> the hardare (as certainly provided in SPARC and ARM - ASIUI). I believe it
> is also possible in i86*, but that Bill Gates has painted himself into a
> corner that prevents taking advantage of it. BICBW.

Intel's XD (Execute Disable) and AMD's EVP (Enhanced Virus Protection)
are have been used by MS Windows since mid/late autumn 2004. (It was
in Windows XP Service Pack 2, released in August 2004.)
Refs:
http://support.microsoft.com/kb/875352
Ref: http://en.wikipedia.org/wiki/NX_bit


In environments that may run user scripts, Java or support scripting or
run executable data (Silverlight or Flash) in a web browser fetched from
untrusted locations there are plenty of other security issues to be
worrying about. All without considering the failure of security systems,
WEP or WPA encryption anyone?

Cheers,
Tony