Re: [Mailman-Developers] Possible yahoogroups problem.
On Tue, 2003-07-08 at 15:32, Barry Warsaw wrote:
[Removing list-managers from the recipients]
You took off mailman-developers too... I've put that one back. :-)
On Tue, 2003-07-08 at 08:54, Nigel Metheringham wrote:
Since it looks like the attacker in this case generated an initial subscribe request, and then the confirmation, he will have had access to the UserDesc data - after all its all from data he sent to them in the subscribe request.
Except that in an email request, we auto-generate the password, so there's a little more randomness there.
I had missed that.
So it comes down to how good is the output of random.random() since the receipt time could be guessed within a few minutes giving a small number of hundreds of seconds to work with.
time.time() is a float with precision equal to the system clock precision, probably closer to microseconds than 100s of secs on Linux <wink>.
So that means to guess the subscription cookie, given a mailed subscription, you need to guess:- * the account password - basically a few characters of base64, so say 2^24 (16 million) * time.time() - so the real clock resolution over 100 seconds - which is probably 5000 (50 (Hz) * 100) on older Linux, up to 102400 on more modern versions. [Load of assumptions here...] call it around 2^12 being conservative * random.random() - since its a stringified real I guess thats probably not much better than 10^6 (say 2^20).
So that gives us around 2^56 for mailed requests, 2^32 for web requests (password is known - and the time is known better, maybe should reduce that by 2^7 or so).
Thats a fair amount to attack.
One thing that could be considered to protect ourselves against such attacks if there was a way of reducing the complexity to reasonable levels, would be to drop pending subscription requests after a couple (think of an appropriate number) of failed cookie cracking attempts. That of course transforms this into a denial of service attack :-(
BTW, is there something we can do to prevent Mailman addresses from getting subscribed to Yahoo! or other listservs? I'd rather not hardcode in Yahoo! brain damage, so I'm looking for a more principled approach.
List-* headers?
I.e. never respond to messages with List-* headers? Probably Precedence: bulk|junk|list too.
Nigel.-- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ]
On Tue, 2003-07-08 at 11:00, Nigel Metheringham wrote:
One thing that could be considered to protect ourselves against such attacks if there was a way of reducing the complexity to reasonable levels, would be to drop pending subscription requests after a couple (think of an appropriate number) of failed cookie cracking attempts.
That's a good idea...
That of course transforms this into a denial of service attack :-(
Which are always much harder to prevent. :/
-Barry
On Tue, 2003-07-08 at 11:00, Nigel Metheringham wrote:
One thing that could be considered to protect ourselves against such attacks if there was a way of reducing the complexity to reasonable levels, would be to drop pending subscription requests after a couple (think of an appropriate number) of failed cookie cracking attempts. That of course transforms this into a denial of service attack :-(
Oh whoops, I just realized that if you get the cookie wrong, you have no idea which subscription request they intended to confirm. sha has 160 bits of data in it and if you're off by one, you don't get a hit and we error out. But there's no way to match the sha hexdigest that you got in the confirmation attempt with one in the database of pending subscription requests.
-Barry
On Tue, 2003-07-08 at 17:53, Barry Warsaw wrote:
On Tue, 2003-07-08 at 11:00, Nigel Metheringham wrote:
One thing that could be considered to protect ourselves against such attacks if there was a way of reducing the complexity to reasonable levels, would be to drop pending subscription requests after a couple (think of an appropriate number) of failed cookie cracking attempts. That of course transforms this into a denial of service attack :-(
Oh whoops, I just realized that if you get the cookie wrong, you have no idea which subscription request they intended to confirm. sha has 160 bits of data in it and if you're off by one, you don't get a hit and we error out. But there's no way to match the sha hexdigest that you got in the confirmation attempt with one in the database of pending subscription requests.
Of course - I had been thinking that you are confirming a subscription address so the sender address is used as a key, but that is not how it works.
You can't reasonably shut off all confirmations if you get a number of failed confirmations, and expecting the sender address to be useful is not too good either so I guess there is no real way to do this.
Nigel.-- Nigel Metheringham <Nigel.Metheringham@dev.intechnology.co.uk> ...at home... they call this a day off :-)
participants (3)
-
Barry Warsaw -
Nigel Metheringham -
Nigel Metheringham