[20898] in bugtraq

home help back first fref pref prev next nref lref last post

Re: SECURITY.NNOV: Outlook Express address book spoofing

daemon@ATHENA.MIT.EDU (Dan Kaminsky)
Thu Jun 7 13:17:42 2001

Message-ID: <01fa01c0eee8$75270a10$8256d281@na.cisco.com>
From: "Dan Kaminsky" <dankamin@cisco.com>
To: "Peter W" <peterw@usa.net>
Cc: "3APA3A" <3APA3A@SECURITY.NNOV.RU>, <bugtraq@securityfocus.com>
Date: Wed, 6 Jun 2001 17:26:10 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> Novell Groupwise has similar problems with displaying the address book
> "name" instead of the address (though Groupwise is *not* vulnerable to the
> same attack that forces the spoofed entry into the address book). It would
> be nice if these email systems would always display both the name and the
> address. Perhaps use both different colors, and the familiar <> construct,
> e.g. "myfriend@good.example.org <attacker@evil.example.net>" the way
> other packages like Netscape Messenger, Mozilla Mail, Pine, and Mutt do.

Good example of how user interface theory can be critical to resolving
security concerns.

Full name/address expansion works very badly when there's a decently sized
list of people receiving emails; instead of a mailing list reading:

Alice, Bob, Charlie, Mallory

You have:

Alice <alice@foo.com>, Bob <bob@bar.com>, Charlie
<charlietangouniform@foobar.com>, Mallory <timmy@gobbles.com>

This can be cleaned up slightly by only having one entry per line, but that
gets wasteful of space.  While its true that this provides a moderately
effective method for authenticating destinations(at least in this context),
it's so much less succinct that it poses a distinct usability constraint.
Since the job of software is to be usable, not necessarily secure, the
impact of the security noise would probably be enough to prevent the
deployment of the fix.

Nobody applies a patch that breaks what works--guaranteed immediate damage
is much more compelling than theoretical future damage.

A couple people have questioned why not just reject all "true names" that
contain an @ sign.  For better or worse, having an @ in your name is not
necessarily a sign of illegitimacy:  A small but non ignorable minority of
individuals tend to spell their names using an @ as a replacement for a.
While not particularly my style, I don't think any of us can arbitrarily
choose to reject the character when more than a few of us receive network
links from @Home and respect people at @Stake.

Perhaps a "true name" filter along the lines of *@*.TLD?  I think that's
pretty much what the user is interpreting as a differentiator between real
names and email addresses.

Yours Truly,

    Dan Kaminsky, CISSP
    Cisco Systems, Inc.
    http://www.doxpara.com



home help back first fref pref prev next nref lref last post