>>> bashing on this one is misplaced. This particular attack is not
>>> Microsoft-specific in any way other than having happened to be written
>> If document macros ran in a limited environment analagous to the Java
>> sandbox, things would be a lot safer.
>
>Has *Java* even gotten their sandbox right? Sure, I agree with you, but
>Microsoft is a seriously broken company that's done a lot of evil in the
>world, but this specific problem I place square at the feet of the
>prevelant attitude of "don't try to make me understand what I'm doing,
>just make it work."
That and a "code first, secure later" mentality when designing software
that's uses by literally millions of naive users. I'll bet the designer of
macros in Word never thought about the internet as a mechanism for
connecting malicious external parties with naive internal users. (Well I
hope they didn't think of it. Knowing it and proceding nonetheless is far
worse of course).
Obqmail: That you start with security as a fundamental goal has to put you
in a lot better stead than worrying about it after you ship functionality.
Particularly relevant to Melissa is the content leakage it causes by
sending the infected document (which could be highly confidential or
embarrassing) to the 50 recipients (or is that 60 with papa?).
It's interesting to note the information leaks in qmail in light of this.
There are not many and they are pretty well constrained to providing traces
for local administrators rather than information to the wider internet.
Examples?
1. uid (but not username!) in Received:
2. qid & qp on 250 ok (they largely provide traffic analysis-type info)
3. IP addresses and reverse names (possibly from a split DNS) in Received:
lines
Not too bad. Are there others that cannot be stopped with the standard
qmail? One could argue that there should be a ~alias/.qmail-default
installed as a default.
I don't know of any fundamental content leak capability that's not user
initiated. Anyone?
Regards.
