Securing 'pickle'

[David McNab]

Hi,

I'm writing a web app framework which stores pickles in client cookies.

The obvious security risk is that some 5cr1p7 X1ddi35 will inevitably try
tampering with the cookie and malforming it in an attempt to get the
server-side python code to run arbitrary code, or something similarly
undesirable.

To protect against this, I've subclassed pickle.Unpickle r, and added
overrides of the methods load_global, load_inst, load_obj and find_class.

My override methods simply raise exceptions unconditionally , which causes
any unpickle to fail if the pickle tries to unpack anything even
resembling code or an object.

I did this in preference to using the reputable 'bencode' module from
BitTorrent, because bencode doesn't support floats.

My question - have I done enough, or are there still ways where my hobbled
unpickler could be subverted by a malformed cookie?

Cheers
David

[Paul Rubin]

jj*@pobox.com (John J. Lee) writes:

Security isn't a big deal -- or rather, securing cookies isn't a big
deal.

I don't understand. The problem is that pickles can be constructed
that can damage systems when unpickled, is that right? If that's
true, then surely unpickling cookie data is unsafe, because stuff
coming in from the network has to be regarded as malevolent. Are you
saying that web server environments are sufficiently-well bolted down
that no pickle attack will work? But belt-and-braces is the best
policy, isn't it?

The point is that you can use cryptographic signatures to make sure
any cookie you receive is one that the server actually sent, before
deciding to unpickle it. That means if the attacker constructs a
malicious cookie, you never unpickle it.

[Alan Kennedy]

Paul Rubin wrote:

My suggestion is to
authenticate the cookies with a cryptographic checksum and verify the
authentication before deserializing the cookies. That's probably the
simplest approach. Keeping session info on a multi-process server (or
worse, a multi-server network) needs some kind of concurrent storage
mechanism.

Paul,

Do you mean transmit the checksum to the client with the cookie? And
check that they match when the cookie and checksum come back?

Or is the checksum stored on the server, in some form of lookup
dictionary keyed by some user session identifier?

regards,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan

[Paul Rubin]

Alan Kennedy <al****@hotmail .com> writes:

Do you mean transmit the checksum to the client with the cookie? And
check that they match when the cookie and checksum come back?
Yes. See other posts in the thread for sample code.
Or is the checksum stored on the server, in some form of lookup
dictionary keyed by some user session identifier?

If you have a convenient way to do that, it's best to just send a
session number in the cookie, and keep all the session data on the
server. Then you don't ever have to unpickle anything.

[Nagy László Zsolt]

>

Security isn't a big deal -- or rather, securing cookies isn't a big
deal.

I don't understand. The problem is that pickles can be constructed
that can damage systems when unpickled, is that right? If that's
true, then surely unpickling cookie data is unsafe, because stuff
coming in from the network has to be regarded as malevolent. Are you
saying that web server environments are sufficiently-well bolted down
that no pickle attack will work? But belt-and-braces is the best
policy, isn't it?

I'm sorry, I just caught this thread and I don't know your problem very
well.
I'm extensively using this (see below). It is unable to pickle class
instances but
you won't accidentally run constructors. I think it is safe for
sending/receiving data.
I did not try to publish this yet but it would be great to know if this
is safe or not
so please make comments.

Laci 1.0

import cStringIO
import cPickle

def dumps(obj):
f = cStringIO.Strin gIO()
p = cPickle.Pickler (f,1)
p.dump(obj)
return f.getvalue()

def loads(s):
f = cStringIO.Strin gIO(s)
p = cPickle.Unpickl er(f)
p.find_global = None
return p.load()

[Nagy László Zsolt]

>

My suggestion is to
authenticat e the cookies with a cryptographic checksum and verify the
authenticatio n before deserializing the cookies. That's probably the
simplest approach. Keeping session info on a multi-process server (or
worse, a multi-server network) needs some kind of concurrent storage
mechanism.

Paul,

Do you mean transmit the checksum to the client with the cookie? And
check that they match when the cookie and checksum come back?

Or is the checksum stored on the server, in some form of lookup
dictionary keyed by some user session identifier?

I think he wanted to write a digital signature instead. Right?

Laci 1.0

[Paul Rubin]

Nagy László Zsolt <na*****@freema il.hu> writes:

Or is the checksum stored on the server, in some form of lookup
dictionary keyed by some user session identifier?

I think he wanted to write a digital signature instead. Right?

I used "cryptograp hic checksum" in a broad sense. More specifically
the suggestion is to use a secret-key authentication code like HMAC-MD5.

[Ian Bicking]

On Fri, 2003-07-11 at 10:00, John J. Lee wrote:

Ian Bicking <ia**@colorstud y.com> writes:
[...]

Security isn't a big deal -- or rather, securing cookies isn't a big
deal.

I don't understand. The problem is that pickles can be constructed
that can damage systems when unpickled, is that right? If that's
true, then surely unpickling cookie data is unsafe, because stuff
coming in from the network has to be regarded as malevolent. Are you
saying that web server environments are sufficiently-well bolted down
that no pickle attack will work? But belt-and-braces is the best
policy, isn't it?

I should have said "securing cookies isn't hard", so that's not the
reason not to use them (though you shouldn't just use plain-vanilla
cookies).

Ian

[Paul Rubin]

Ian Bicking <ia**@colorstud y.com> writes:

I should have said "securing cookies isn't hard", so that's not the
reason not to use them (though you shouldn't just use plain-vanilla
cookies).

The signature scheme we've discussed does cause some configuration
hassle. There has to be a host-specific secret key and it has to be
kept secret. If it leaks to an attacker, the attacker can then create
malicious cookies. So the scheme has to be used with care.