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