pickle security

[Paul Rubin]

martin at v.loewis.de (Martin v. Loewis) writes:
> > The code to deal with quote strings calls eval, and without actually
> > examining the eval implementation (big, complicated) there's no way to
> > confirm that it can't somehow run arbitrary code found in the string.
> 
> Then, please do examine the code. Not doing so and still claiming
> there is a problem means to spread FUD.

There is a lot of code and the very size of the code means I might
miss something.  However, it's not FUD to say that a complicated piece
of code is harder to check for exploits than a simple one.

> > Microsoft does that and that's why we keep hearing about new
> > exploits being discovered in Microsoft products.  The code has to be
> > checked thoroughly, which is easier to do when the code is simple.
> 
> In this specific case, it is relatively easy to check that the eval is
> safe. It is not the case that the risk of an exploit has been
> ignored. Instead, it is the case that the risk has been analysed and
> found to be non-existing. If you chose to ignore this analysis, fine -
> but please don't tell people that there is a security risk.

I spent a few minutes checking the eval when I first reported the
pickle security bug, and the few minutes was enough to see that to do
a really thorough check, I'd have to spend hours, and I still might
miss something, or eval could change in a some future Python version
when no one is thinking about how it interacts with hostile pickles
(that's how pickles got to be insecure in the first place).  Since the
correct fix is to just not use eval, I don't want to spend hours
checking eval (and re-checking it with each new Python release) unless
someone is paying me.  Are you offering?

> In any case, there is a patch on SF that removes the eval, see
> 
> http://sourceforge.net/tracker/?func=detail&aid=505705&group_id=5470&atid=305470
> 
> The rationale for doing so is different, though: eval interns strings,
> which is undesirable for unpickling.

The patch is desirable for security reasons too, so I'm glad it's
there.  I'll look at the pickle code again next time I have an
application where I want to unpickle hostile data.  For now, I'm doing
ok with alternative serialization methods.