RE: CBV

"Seth Goodman" <[email protected]>
Newsgroups gmane.mail.spam.srs.general
Message-ID <[email protected]>
> From: Meng Weng Wong
> Sent: Thursday, April 29, 2004 12:52 PM

<...>

> Meng was thinking about SES/CBV during his shower this morning and
> wondered if we'd addresses the problem of replay attacks yet.  If a
> spammer gets his hands on a good SES return-path, can't he send out a
> spam with return-path?  CBV would pass.

We probably have not fully addressed that, so let's try.  Yes, a replay
attack would definitely work.  SRS rewritten addresses are similarly
vulnerable to replay attacks, as far as I can tell.  Both SES and SRS
addresses are protected by the same timestamp field, so the usefulness of a
harvested address would be time limited in both cases.

The real question here is how easy is it to harvest a signed envelope
address, regardless of the signing protocol?  When I originally brought this
up as a possible exploit against SRS to Shevek, his answer was to not send
email to spammers and then they wouldn't have your signed return-path.
Though I groused about it at the time, that really was a pretty good answer.
If you don't send email to spammers, how _would_ someone go about harvesting
signed envelope addresses?

Thinking about this further, a full signed return-path address should never
appear in an MUA anyway.  I say this since the Return-Path: header in a
successfully delivered message cannot, by definition, be used to send a
legitimate DSN.  Therefore, the signed address has no legitimate use at this
point since it will not accept normal (non-DSN) mail.  I think you will have
to address this same issue as you integrate SRS functionality into the MX
modules you are developing.  My guess is that you will end up unwrapping the
SRS-rewritten address down to the unsigned source address buried inside it
and putting that address in the Return-Path: header.

If you make this implementation choice, what methods are left to harvest
signed return-paths?  A malicious party could hack the mailer to get it to
divulge the full signed return-path, but then harvesting signed
return-path's is the least of your concerns.  I can imagine eavesdropping on
the network connecting the MSA's to the MTA's, but if the signing takes
place in the MTA, this wouldn't get you anywhere.  Eavesdropping on the link
between an MTA and the border router is perhaps the best place to do
mischief, but that would be a dedicated link in any sane implementation and
someone on the inside would have to cut cables and install hardware without
detection.  Sounds like a job for 007, though M would have to agree.
Eavesdropping on the lines exiting the provider's border routers is
imaginable, but that's not trivial even on the T1's or DS-3's that small
providers use and pretty much impossible (without detection) on the fiber
links used by most other providers.

Perhaps I'm missing something basic, and if so, I'd appreciate you clueing
me in, as usual.

--

Seth Goodman
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.