ietf
[Top] [All Lists]

Re: contest: win valuable Microsoft stock!

2000-05-08 04:00:02
On Mon, 08 May 2000, James P. Salsman wrote:
Keith Moore wrote:

...  I do think there is some culpability on the part of the
software vendor.  and from a purely pragmatic perspective, it's a
lot easier for the vendor to make software that is less susceptible
to such things, than it is to get rid of the virus writers.

and if the folks who sell such software would just fix this, we
wouldn't need to care so much about culpability.  but I'm not
holding my breath waiting for this to happen.

I think the issue is one of bounds.  What is off bounds and what is ok for an
internet client, such as an email reader, to have access to on any system.  If
the requirements of these bounds could be clearly defined in temrs of what is
allowed, then by default dissalow access to everything else.  Do not make this
a configurable option.  We have to remember that he who giveth CANNOT taketh
away, so we must ensure that the flexability of scripting languages remains (
although I'd love to shut down their access ) as some people are now reliant on
certain functionality.  

The "Java" sandbox idea in my mind is a great one.  When code is run from an
internet client,  constant bounds checking must occur.  Whenever the code steps
over the mark we either stop it in it's tracks, clean up and offer to send a
potential virus alert, or we thow some alarm hoping that the user is actually
able to read and understand the potential dangers.

The core issue is certainly not a new one, however it is wearing a different
hat.  Attempting to get programming teams to impliment security, such as bounds
checking, input validation ( not just "is it a number etc. ) and various other
forms of development/coding technices is nothing new.  It is here however that
we must focus our attentions.  It is the fault directly, of the designers of
the software.  It is these designers that think almost solely about the
functionality of the code rather than necessary robustness and security.  Once
the designers have been - re-aligned - it is the turn of the programmers.  To
educatie them in the kinds of attacks people are perpetrating through their
code and how they should be writing code to avoid this.  For both parties, the
process of peer revies is important.  This peer revieew is where I have
personally found a good deal of discovery occurs.  Certain nuances taat one
persone may overlook another may not.

In summary.  Re-education for designers and programmers.  Peer review.  Require
solid definitions for what an internet client can do.  On execution of internet
based code, bounds checking must occur constantly.  Bounds execption actions
must be agreed, defined and predictable.

Garreth J Jeremiah,
"If the light is on, but no one is home.......we simply left the light on"
"The light at the end of the tunnel could be a train"



<Prev in Thread] Current Thread [Next in Thread>