On Wed, 29 Aug 2007 the voices made Guy Hulbert write:
GH> On Tue, 2007-08-28 at 23:04 -0400, Charlie Brady wrote:
GH> > > On 28-Aug-07, at 3:51 PM, JT Moree wrote:
GH> > >>> hires_time.pid.local_port
GH> > ...
GH> > >> my $conn = $args{connection};
GH> > >> my $ip = $conn->local_port || "0";
GH> > >> my $start = time;
GH> > >> my $id = "$start.$$.$ip";
GH> > >>
GH> > >> Some people have suggested adding the remote IP address. I'm
GH> > curious
GH> > >> why use local port instead of remote port? would both be better?
GH> > >
GH> > > Err, actually I had a brain fart. It should be remote_port.
GH> >
GH> > No, it should be remote_IP.remote_port.local_port and should include
GH> > a
GH> > transaction_within_connection count. I don't think that pid adds
GH> > anything.
GH> This does not guarantee a unique message ID. That's why we are using
GH> hi_res time.
If this' meant to go into the core it might not be a bad idea to make the
first part of a "guaranteed" unique message ID identify the server itself; just
to avoid that someone manages to write a plugin which relies on the ID being
unique, and then in some (maybe very rare) cases isn't so in a busy multi-mx
setup.
I'm thinking aggregated/centralized logging, simple/custom supportsystems
relying on an already provided "unique" ID, mailqueues/filters/whatever using
this ID to know where to pick up its work after an interruption, "report this
e-mail as spam"-links added in e-mails... but most of all I'm thinking that if
it might be possible to time an attack such that something might show an, at
least to some, unexpected behaviour, like the creation of a unique ID that
isn't "unique enough" for its usage, then someone out there will sooner or
later figure out a way to use it to his advantage.
Including the PID might be enough to differentiate the IDs, but if it is it's
more, from a security POV, works-by-accident than by design; PID+random-string-
created-when-qpsmtpd-is-started might be a tempting way to keep resource usage
at a minimum, but would once again not feel as safe as might be prefered... but
using a public IPaddress used by qpsmtpd might do the trick. Then agan, if we
start to think about security, then there might be several (semi-paranoid)
reasons why one wouldn't want to just use the/a IPadress (esp. not since it
might freak out some qpsmtpd-users if they use the ID externally without
knowing about this); so how about, at the start of qpsmtpd, creating a unique
ID for that startup by hashing something along the lines of (IPs-listened-to,
PID, hi-res-time), possibly with randomized positions or a random string
somewhere.
That unique server ID would then be used as the first part of the unique IDs
created for each e-mail processed on that server.
Sure, this is more convoluted than truly needed for the requirements of a
unique ID in this case, and one could rightfully argue that the usage of a
hashing algorithm will increase the chance that two servers will end up with
the same ID; further weaknesses would be in situations where qpsmtpd isn't
using any IPaddresses uniquely assigned (such as on a local network) or where
two servers are intentionally designed to be identical and maybe (re)activated
from the same saved image of a previously started system (perhaps a teeny weeny
bit more esoteric usage of qpsmtpd to ever be setup by anyone that would rely
on a "guaranteed" unique ID without checking the code thoroughly).
HOWEVER, this never was about cryptographically perfect security; but about
greatly reducing the potential number of situations in which 1) a vulnerability
might be introduced, and 2) where vulnerable setups might be identified.
A scheme such as that I've outlined would do just that, it would also reduce
the window of opportunity for the already unlikely error/exploit to no longer
than when qpsmtpd is restarted on one of the two affected servers; to the cost
of a very slight extra resource usage at the startup.
(Only reason I gave this some thought was because I few days ago wanted unique
IDs traceable to a single server, without having to use statically assigned
identifiers. The purely security implications of adding unique IDs to qpsmtpd
without them possibly being less unique in a multi-mx setup seems quite
neglectable; but still easily avoidable... )
/Tony
--
"Generally speaking, taunting mentally unstable people is a bad idea."
