This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author phr
Recipients
Date 2001-10-14.22:27:39
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Logged In: YES 
user_id=72053

My understanding of marshal (I better check it, but I did
mention the issue in the original request) is that it can
create code objects but it doesn't actually execute the code
in them.  My implementation currently uses marshal but
checks that the stuff marshal returns doesn't contain
anything unexpected.  Unpickle is different--it looks like
it can execute hostile code before the loads call ever
returns.  By the time you have a chance to check the result,
it's too late.  cPickle.c appears to work exactly the same
way (using eval and creating arbitrary instances, but maybe
not calling marshal) as pickle.py.

It never would have occured to me that the unpickler would
work that way (and I'm still not convinced I understand
it--I better try putting together a test to see if it's
really like that).  That's why I didn't notice the security
issue til we started discussing pickle and I actually looked
at the code.  I'm sorry if that sounds like I'm adding
requirements.  I'd have thought it would go without saying
that an important utility shouldn't have security holes.

I'm ok with using pickle if the doc and security concerns
are taken care of.  More efficient longs would be helpful
but they would break interoperability with old versions
and I can probably live without them.  It's really sad that
longs were shrugged off when the pickle binary format was
designed.  Now in order to have efficient longs, yet another
flag will have to be added to the constructor.

Btw, if the unpickle security issue is real (I'm still not
convinced!), I feel it should be treated as a major bug
and that an announcement should be sent out.  Unpickle 
already anticipates hostile pickled strings in the
non-binary format and checks for them (see
_is_secure_string) though I'd want want to spend an hour
or two checking both the `...` code and the evaluator
before believing that _is_secure_string is really safe--
and even if it is, it's brittle.  But it looks like
object creation security is an area they didn't think about.

Basically I have nothing against pickle in principle, but
it has these (fixable) problems, and while marshal is 
straightforwardly written, both pickle implementations
are excessively clever and make me queasy.

Anyway, I can go along with the idea that the right solution
is to fix pickle--but at present, pickle looks like it's in
worse shape than marshal.
History
Date User Action Args
2007-08-23 16:01:36adminlinkissue467384 messages
2007-08-23 16:01:36admincreate