On 2013-04-25 23:57:24 -0500, Derek Martin wrote:
> On Fri, Apr 26, 2013 at 01:48:36AM +0200, Vincent Lefevre wrote:
> > On 2013-04-25 10:13:30 -0500, Derek Martin wrote:
> > > In "normal" e-mail operations, this may be dependent on the behavior
> > > of the mail client, i.e. if it sends separate messages for each
> > > recipient. In an attack, this is not interesting. The attacker is at
> > > your site (he must be, in order to effect a temp file attack). So, he
> > > can either send the message to the target and himself from your
> > > machine, or he can just telnet to your SMTP server and write the
> > > message by hand.
> > The server normally adds a "Received:" header with some information
> > unknown to the attacker.
>
> I'm sorry Vincent but you're wrong. The header gets added, it's the
> same in both the target and attacker's copies.
Wrong. This is not what I can see. Well, if I send the same mail
to 2 addresses different due to aliasing, the IDs are the same,
but if I use 2 addresses <local@domain> and <local+foo@domain>,
the IDs of the latest Received are different:
Received: from localhost (localhost [127.0.0.1])
by jabiru.ens-lyon.fr (Postfix) with ESMTP id A681BA3AE3
for <[email protected]>; Fri, 26 Apr 2013 13:19:24 +0200
(CEST)
Received: from localhost (localhost [127.0.0.1])
by jabiru.ens-lyon.fr (Postfix) with ESMTP id A9C99A3AFE
for <[email protected]>; Fri, 26 Apr 2013 13:19:24 +0200 (CEST)
> All that's required to guarantee this is to name both recipients in
> the same SMTP transaction on the target's SMTP server.
I'm not sure that the same SMTP transactions can be used (at least the
latest ones in the chain): different users may have different antispam
rules at the site level...
The behavior may depend on the site. But at least on some sites, it
could be regarded as a source of random, even if the attacker has
mail access on the same site. So, there's no reason to reject this
method, unless there's a 100% safe random source somewhere else.
> > Anyway, I've seen that you haven't proposed anything else.
> > Is your point to make Mutt uninstallable on machines without
> > a /dev/random?
>
> I have in fact. Two and a half years ago even.
Where?
> Use mkstemp() and use the link() method to create the full name.
But how to you get the full name? That's the point of this subthread.
> The whole point of this subthread is that choosing not to rely on
> the system-provided library routines is folly. You can't provide
> anything better portably--your system libraries will already use the
> best source of randomness available to them.
Of course one can: just add randomness to what the system libraries
provided. In particular, mkstemp() will just provide a unique
filename, without a suffix. The unique filename may be predictable
(the spec doesn't require that it shouldn't be). And even if it
isn't, randomness is gone just after the call if an attacker can
exploit the race condition.
--
Vincent Lefèvre <[email protected]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
