secure unpickle?

[Tim Peters]

[John J. Lee, on Gandalf's safe(r) restricted unpickling code,
 which assigns None to an unpickler's .find_global attr]

> Aha.
>
> I see from past messages that this is thought to solve the security
> problems (for this restricted case), at least by Martin v. Loewis, but
> also that Paul Rubin believes a careful audit would be required to
> have confidence in it (whether that's FUD, as Martin accuses, or
> sensible caution, I have no idea...).

Oh, who knows.  Start by defining "security problem" -- I don't know what
exactly people mean by that, although I do know I lose interest long before
they finish demanding impossibilities <0.6 wink>.  For example, I wouldn't
be surprised if some otherwise idle postdoc found a way to trick cPickle
into segfaulting by constructing an enormously large and/or enormously
deeply nested composition of simple scalar types, lists, tuples and dicts.
I don't know whether that's possible, but long experience certainly suggests
that virtually all C programs have problems with "too much" of anything.

>
http://www.google.com/groups?threadm=mailman.1012591743.10841.python-list%40
python.org

In the specific case discussed there of unpickling a string, I agree with
Martin that there's no plausible attack, perhaps apart from creating a
pickle that unpickled to a multi-gigabyte string (will the system malloc()
properly return NULL if it can't satisfy the request?  even if it does, will
cPickle deal with the NULL return correctly?  will cPickle screw up by
failing to account for the possibility of integer overflow when adding the
size of the string header to number of string bytes requested?  etc -- beats
me).  I expect this is because Martin and I are both familiar with the
actual front-end code that parses a string, and Paul isn't.  Familiarity
doesn't *always* breed contempt <wink>.