Secure Coding mailing list archives

Re: Hypothetical design question


From: der Mouse <mouse () Rodents Montreal QC CA>
Date: Fri, 30 Jan 2004 14:14:39 +0000

Nothing recieved from email should ever be able to execute rm -rf,
nor should it ever be able to send email itself, nor open sockets,
etc - even if it has been saved to disk and is being executed later.

I'm not sure I agree with that.  I see no security hazard in this
provided it's done properly.  For example, say I'm visiting a friend
and have my laptop with me.  I ssh back to my home machine and demo a
program (my two-player X chess game, for example).  Friend wants a
copy.  So I mail it and we verify the md5 on the spot to ensure that
the file as received equals the file as sent.  Absent very peculiar
threat models, this is "safe", certainly about as safe as my scping it
to a floppy on the laptop and sneakernetting the floppy to the friend's
machine.  (Not that I actually would do either one; I'd send the
source.  But I think the principle is clear.)

Of course, if you're talking about the sort of user whose idea of
software installation amounts to clicking "[Next>" until the
installation wizard goes away, I think you might well have a point.
But even for them, I have trouble imagining how this could be done that
wouldn't lead directly to worse abuses.

Also, what does it mean to "execute rm -rf"?  I take it you are
speaking somewhat loosely; after all, systems that even _have_ rm
generally aren't what we have to worry about here.  Where is the line
beyond which lies "executing"?  Someone else mentioned something
similar in the context of spreadsheets - there are a great many things
which are not intended as programming languages but which can be
pressed into such service that if you take out anything that could
possibly be a programming language, you severely cripple functionality.

/~\ The ASCII                           der Mouse
\ / Ribbon Campaign
 X  Against HTML               [EMAIL PROTECTED]
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B








Current thread: