Re: [Mailman-Developers] Possible yahoogroups problem.
At 9:19 AM -0400 7/8/03, Barry Warsaw wrote:
The data we use:
- the str() of the output of random.random()
- the str() of the server's current time
- the str() of the "content"
and we concatenate these three strings together before hashing them.
I'm not sitting in front of the source code for Mailman right now (and I don't read Python), so this brings up a few questions.
Can random.random() run out of randomness? That is, if you bombard the machine with requests that call random.random(), will it start sending out predictable responses?
What is the granularity of the server's current time? If it is "seconds", this is becomes easily predictable to an attacker. Even if it is "hundredths of seconds", that only means that the attacker has to send one or two hundred attempts for each confirmation. Unless Mailman notes "failed attempt to confirm a subscription", this could be lost in the noise.
How many bits of the hash are used? I ask because many programs that use hashes will not use the whole hash.
The answer to the above three (particularly the first) determines whether or not an attacker can sensibly forge confirmations. (Of course, watching the outgoing mail would make this attack easier too. :-) )
--Paul Hoffman, Director --Internet Mail Consortium
On Thursday, July 10, 2003, at 12:35 PM, Paul Hoffman / IMC wrote:
(Of course, watching the outgoing mail would make this attack easier too. :-) )
of course, if they're sniffing packets or otherwise intercepting content, the only thing that'll stop it is a phone call... carrier pigeon, maybe.
My worry, of course, is that the e-mail community has had a tendency to see mail-back validation as the solution to many problems (and it is, just not as globally as some might hope) --- but I don't think the community has ever stopped to make sure those techniques were really secure in a formal way, or defined what it takes to be secure. the existance has been enough...
(but then, there are all sorts of attack vectors in mail lists that haven't been properly addressed. If I want to mailbomb your inbox into a cinder, does it matter whether I subscribe you 50 busy mail lists, or simply shove 1,500 "if you want to confirm your subscription..." replies in via a forged address? Most servers will happily keep resending confirmations without rate limiting, so you don't even need to find 1500 lists... Ditto help and info messages, postmaster auto-bots, etc, etc... )
On Thu, 2003-07-10 at 15:54, Chuq Von Rospach wrote:
My worry, of course, is that the e-mail community has had a tendency to see mail-back validation as the solution to many problems (and it is, just not as globally as some might hope) --- but I don't think the community has ever stopped to make sure those techniques were really secure in a formal way, or defined what it takes to be secure. the existance has been enough...
This is an excellent point, and I think deeper than the hash algorithm we use. I think we can make the hash generation unbreakable for all intents and purposes. Much more worrisome to me is the actual protocols we're using for confirmation.
Case in point: MM2.1 supports the ability to encode the confirmation string in the envelope sender so all it takes is a reply to confirm. This is only implemented for a small handful of confirmation scenarios currently. It's frightening to enable that for e.g. subscription confirmations because of the widespread presence of broken vacation programs. E.g. if you know Chuq's vacation program will reply to Precedence:bulk messages, you just have to wait until he's out of the office for a few days to mailbomb subscribe him to hundreds of lists. Not good!
Of course mail-backs tie into opt-in policies and anti-spam policies, as well as usability issues. Make it hard for people to get on or off the list and you'll get slammed (e.g. jwz's out-of-date rant :).
(but then, there are all sorts of attack vectors in mail lists that haven't been properly addressed. If I want to mailbomb your inbox into a cinder, does it matter whether I subscribe you 50 busy mail lists, or simply shove 1,500 "if you want to confirm your subscription..." replies in via a forged address? Most servers will happily keep resending confirmations without rate limiting, so you don't even need to find 1500 lists... Ditto help and info messages, postmaster auto-bots, etc, etc... )
Yep, yep, yep. I want Mailman to be a good citizen as much as possible, while still being usable. It's a darn fine line sometimes. ;)
-Barry
On Thu, 2003-07-10 at 15:35, Paul Hoffman / IMC wrote:
- Can random.random() run out of randomness? That is, if you bombard the machine with requests that call random.random(), will it start sending out predictable responses?
Any pseudo random number generate can, right? Python 2.2's RNG has 45 bits of randomness, Python 2.3's 53 bits. The latter uses the Mersenne Twister algorithm which I'm told is the state of the art.
- What is the granularity of the server's current time? If it is "seconds", this is becomes easily predictable to an attacker. Even if it is "hundredths of seconds", that only means that the attacker has to send one or two hundred attempts for each confirmation. Unless Mailman notes "failed attempt to confirm a subscription", this could be lost in the noise.
Depends on the server OS. We probably only care about *nix systems, but I'm sure there's variability even within that family. On Linux, I believe there is a 1us resolution for time.time() which uses gettimeofday().
- How many bits of the hash are used? I ask because many programs that use hashes will not use the whole hash.
We use all 160 bits of the sha hash.
-Barry
At 4:39 PM -0400 7/10/03, Barry Warsaw wrote:
On Thu, 2003-07-10 at 15:35, Paul Hoffman / IMC wrote:
- Can random.random() run out of randomness? That is, if you bombard the machine with requests that call random.random(), will it start sending out predictable responses?
Any pseudo random number generate can, right?
Some PRNGs have failure modes which become easily predictable. These are almost always triggered when the source of random bits is exhausted. If you ask for too much randomness too quickly, you can start getting predictable data. Well-written PRNGs are smarter than this: they put out not-very-random but very-random-looking values, usually based on "hash of ( the last random value | current time | job number )".
Python 2.2's RNG has 45 bits of randomness, Python 2.3's 53 bits. The latter uses the Mersenne Twister algorithm which I'm told is the state of the art.
Then this is sufficient. And so is 45 bits of randomness.
- What is the granularity of the server's current time? If it is "seconds", this is becomes easily predictable to an attacker. Even if it is "hundredths of seconds", that only means that the attacker has to send one or two hundred attempts for each confirmation. Unless Mailman notes "failed attempt to confirm a subscription", this could be lost in the noise.
Depends on the server OS. We probably only care about *nix systems, but I'm sure there's variability even within that family. On Linux, I believe there is a 1us resolution for time.time() which uses gettimeofday().
As long as your random value has 45 bits of randomness (and none of those bits rely on the time!), then it doesn't matter how predictable your time value is.
- How many bits of the hash are used? I ask because many programs that use hashes will not use the whole hash.
We use all 160 bits of the sha hash.
Good!
In summary, assuming that the first answer above (about the pseudo-random number generator) is correct and it gives 45 bits of randomness at each invocation, there is no way that an attacker can attack the auto-responder without sending about 35 trillion messages.
--Paul Hoffman, Director --Internet Mail Consortium
participants (3)
-
Barry Warsaw -
Chuq Von Rospach -
Paul Hoffman / IMC