[Mailman-Developers] Cookie security hole in admin interface

[Harald Meland]

[John Morton]

> Harald Meland writes:
>  > As the extra complexity added by having to save session state on the
>  > server side (i.e. have Mailman keep track of session IDs) is rather
>  > large, and as Mailman isn't safe from package sniffing anyway (unless
>  > you're running things on a SSL server, in which case cookie sniffing
>  > shouldn't be of any trouble anyway), I settled for slightly less.
>  
> True. Though stealing a cookie via packet sniffing will still require
> the thief to be on the same IP as the original cookie owner, or it
> will require them to fake their IP as well.

I wasn't really thinking of cookie stealing, but rather on plain text
password sniffing... and to remove that vulnerability, one would have
to use SSL or somesuch.

> [Note, I'm not a python hacker, so bear with me :-) ]
> 
> Do add the domain that this mailman for this list is supposed to be
> under (or the browser will send this cookie to every site you connect
> to!)

RFC 2109 has this to say:

  4.3  User Agent Role
  
  4.3.1  Interpreting Set-Cookie
  
     The user agent keeps separate track of state information that arrives
     via Set-Cookie response headers from each origin server (as
     distinguished by name or IP address and port).  The user agent
     applies these defaults for optional attributes that are missing:
  [...]
     Domain Defaults to the request-host.  (Note that there is no dot at
            the beginning of request-host.)

... so I think that the current behaviour of not specifying the
cookie's domain at all is correct.

> and restrict the scripts that it is sent to to /mailman/ at worst,
> /mailman/admin and /mailman/admindb separately at best (allowing
> separate passwords for those two scripts is a needed feature for a
> proper distinction between list admins and moderators, anyway).

Current behaviour is to restrict to /mailman (well, the code is really
using path part of mm_cfg.DEFAULT_URL) -- to allow the same cookie to
authenticate against both admin and admindb pages.

If a separate admindb password is implemented, it won't be a problem
to issue a cookie with a different name for authentication with that
password (e.g. use the 'listname:admin' cookie for access to both
admin and admindb, and also test for 'listname:admindb' if the first
fails on admindb access).

> I'd prefer to grab the secret from a file that's refreshed via a
> cronjob every 24hrs or so.

Uhm, then anyone getting their cookie just before the secret is
refreshed will have to re-enter their password before their cookie
should have expired.  Do we really want that?

>  >         mac = hash(secret + client_ip + `issued` + `expires`)
> 
> Is the hash() function one way?

Yup, at least for now (and I believe it wouldn't be of much use as a
hashing function if it wasn't).

> The FAQ talks about doing a second round of MD5 hashing to '...avoid
> an attack in which additional data is appended to the end of the
> cookie and a new hash recalculated by the attacker.', but I don't
> really understand why that's necessary.

Neither did I -- but I believe the FAQ answer made the assumption that
the server stores more session state than Mailman does.

> Should we check that expires - issued = mm_cfg.ADMIN_COOKIE_LIFE ? 

Depends on whether you want cookies issued directly before the site
admin changes ADMIN_COOKIE_LIFE to go dead immediately or not until
after they were set to expire on creation.

> The combination of a cryptographic hashing function and a secret key
> that's regenerated on a 24hour cycle makes an attack by constructing
> a cookie infeasible (at least, within the useful lifetime of
> whatever hashing function we're using).

I'm hoping that using the list's encrypted admin password as secret,
in combination with a relatively short expire time, is sufficient --
but I'm no cryptography expert.  I _am_ trying to keep the applied
security mechanisms within reason, though -- if you want a completely
bullet-proof Mailman, use an SSL-enabled server.

> Remaining sources of attacks are:
> 
> Packet sniffing: They could steal the cookie this way. But they'd
> just steal the password, anyway, so it's a moot point. Use SSL if
> you're that paranoid.

Exactly.

> Stealing the cookie: Presumably by some method other than packet
> sniffing or direct access to your terminal; maybe a broken browser
> could be distributing the cookie to every site it meets. The
> attacker will need to fake your IP to the web server _and_ get the
> response back, which is rather hard.

Hmmmm... how do proxies (e.g. web cache servers) enter into this
picture?

> Getting access to your terminal: The short expiry time is supposed
> to help defeat this problem.

I was wondering whether Mailman should re-issue a new cookie on each
successful cookie authentication, but decided against it -- partly due
to this possible problem, partly because it would annoy people who
have their web browser warn them before accepting new cookies, and
partly because anyone struggling with Mailman's web admin interface to
a single list for more than (the default) three hours probably is such
a humble person that having to enter the admin password once more
won't be a big problem :)

> The price to pay for the convenience of not having to type the
> password in every time.

Indeed.

> Perhaps having an option to turn off the use of cookies will keep
> the paranoid happy and allow admins to use their servers native
> authentication methods. Perhaps modules to interface between mailman
> and the various different web servers is a direction someone would
> like to go in?

An option to disable cookie authentication altogether is easily
implemented (have a look at SecurityManager.WebAuthenticate()) -- but
I don't know anything about "native authentication methods", so I
think I'll put it off until I understand the issues better.
-- 
Harald