Secure Coding mailing list archives
Re: Hypothetical design question
From: Andreas Saurwein <saurwein () uniwares com>
Date: Wed, 28 Jan 2004 15:15:01 +0000
At 27/1/2004 22:54 Tuesday, you wrote: On 1/27/04 4:38 PM, "Kenneth R. van Wyk" <[EMAIL PROTECTED]> wrote:
Can it be done? What sort of design features would you put into the application to help prevent the system from being used to propagate viruses -- e.g., compartmentalizing or sandboxing the execution of attachments such that they have no network or file resources? What sort of design/feature trade-offs would you think need to be made?
I don't think this represents a valid approach to the problem. That is, the problem is not with the email client but with the environment in which the launched applications execute. This is a problem with the operating system that runs the mail client, not the client itself. While you could create some sort of sandboxing technology inside the email client, that strikes me as bad design. I.e. That sort of functionality doesn't belong in an email client. Thus, any solution you would come up with would work as well with Microsoft Outbreak as with any other client. Sorry, but I really can not agree with you. I could also come up with the argument that execution of an attachment is not a functionality which belongs to an email client. Its the client which OFFERS this functionality as a feature for the user. So, instead of needing to save the attachment to disk and executing it from there as you would do with any other application (and where control is possible), you just click on a feature provided by the email client and, bang, there goes your system. An OS can never cover all functionality. Somewhere we have to draw the line. For example: where is the difference between executing an script embedded in an HTML mail inside an email client and executing the same script embedded in an HTML file on a CD? There are no mechanisms available which even allows a distinction without crippling the user. One feature that is abused a lot by viruses is the email automation API. That is, the ability to read the address book and programmatically send messages. This is a vital API, though, for Windows programs to be able to send legitimate mail. It's like having /usr/bin/sendmail available to unix programs that want to originate mail. So what? Remove it? Knifes kill people, yet everybody can buy/use them. I hate to be all curmudgeony about it, but my outlook on the whole thing is bleak. It's the OS that's broken, not the email client. Email is just a vector for getting attack code in that is ultimately attacking the OS. You can make the email client more resistant, but it doesn't address the real problem. If email isn't the easiest way to get attack code in, they'll find another way (maybe go back to macro viruses). There is always the simple excuse that the OS should do it. So far OS'es are not intelligent enough to protect users from stupid programmers and itself from stupid users. I think its time that we think about how much features we offer to our users and how they affect the environment they are running in. We [programmers] are not aware of the consequences of our implementations. cheers Andreas
Current thread:
- Hypothetical design question Kenneth R. van Wyk (Jan 27)
- Re: Hypothetical design question Paco Hope (Jan 27)
- Re: Hypothetical design question Andreas Saurwein (Jan 28)
- RE: Hypothetical design question Dave Paris (Jan 28)
- RE: Hypothetical design question Andreas Saurwein (Jan 28)
- RE: Hypothetical design question Dave Paris (Jan 28)
- RE: Hypothetical design question Michael S Hines (Jan 28)
- Re: Hypothetical design question Kenneth R. van Wyk (Jan 29)
- Re: Hypothetical design question Andreas Saurwein (Jan 28)
- Re: Hypothetical design question Paco Hope (Jan 27)
- Re: Hypothetical design question Paco Hope (Jan 28)
- Re: Hypothetical design question Dave Aronson (Jan 28)
- Re: Hypothetical design question Andreas Saurwein (Jan 28)