By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,276 Members | 1,406 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,276 IT Pros & Developers. It's quick & easy.

Insecure Pickling

P: n/a
The pickle module is so powerful. It has probably saved me thousands
and thousands of lines of code over the years. It alone is enough to
pursuede me to use Python in many instances.

However, it is so insecure it can hardly ever be used. How often can
you truly trust the think you're unpickling?

Has anyone seen a secure pickle alternative?
Jul 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Am Freitag, 11. Juni 2004 21:14 schrieb Jeff:
Has anyone seen a secure pickle alternative?


<shameless plug>

Check out Flatten (available under Files on
http://sourceforge.net/projects/yawpycrypto). It basically offers the same
functionality as Pickle, but user classes are only picklable after they have
been registered with the module, and must implement explicit __store__ and
__load__ functionality.

Automatic type checking of class variables is only one of the additional
gimmicks it offers. I'm currently working on a new release of Flatten which
includes signing/encrypting parts of a pickle by the pickle creator/for a
specific recipient, but this implementation isn't finished yet.

There is one incompatability with Pickle, which is explicitly noted in the
documentation, and which refers to storing tuples which contain references to
themselves (in some form, such as using themselves as a dict key in a dict
which is contained in themselves, etc.); under several circumstances this
doesn't get unserialized properly. But this is the only real problem there is
with Flatten (AFAIK).

</shameless plug>

There are other packages out there, but I'll leave it to the others to point
you at them (twisted implements a storage protocol which is secure (which can
be made secure), for example, and IIRC it's called twisted.banana).

HTH!

Heiko.

Jul 18 '05 #2

P: n/a
su********@gmail.com (Jeff) writes:
However, it is so insecure it can hardly ever be used. How often can
you truly trust the think you're unpickling?
If it's a pickle you created yourself and nobody else has had a chance
to tamper with, then it's presumably trustworthy.
Has anyone seen a secure pickle alternative?


I think anything with the amount of flexibility that pickles have is
inherently insecure. But there are certainly lots of serialization
formats with less flexibility and more security.
Jul 18 '05 #3

P: n/a
Paul Rubin <http://ph****@NOSPAM.invalid> writes on 11 Jun 2004 13:40:33 -0700:
su********@gmail.com (Jeff) writes:
However, it is so insecure it can hardly ever be used. How often can
you truly trust the think you're unpickling?


If it's a pickle you created yourself and nobody else has had a chance
to tamper with, then it's presumably trustworthy.


You could use encrypted pickles to make sure that nobody without
knowledge of the encryption key can create pickles you are
ready to unpickle.

Of course, this raises the question how secure you can manage
the encryption key.
Dieter
Jul 18 '05 #4

P: n/a
Dieter Maurer <di****@handshake.de> writes:
You could use encrypted pickles to make sure that nobody without
knowledge of the encryption key can create pickles you are
ready to unpickle.

Of course, this raises the question how secure you can manage
the encryption key.


I think you mean "authenticate" rather than "encrypt", but I don't
know whether either is enough, especially if your program uses
multiple pickles. It might be safe to unpickle something in one
context but not in another. For example, say a certain section of
your web app sets cookies X, that contains an encrypted/authenticated
pickle. Navigating to some other section of the app clears the cookie
and sets it to some different pickle. The attacker holds onto a copy
of X from the first section and plays it back into the second section
where unpickling has a completely different effect.

Basically you have to be real real careful with this stuff, no matter what.
Jul 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.