Bugs item #1517663, was opened at 2006-07-05 17:33
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517663&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interpreter crash: filter() + gc.get_referrers()
Initial Comment:
Similar to the bug in tuple() shown in the current
(r47245) version of Lib/test/crashers/gc_inspection.py,
filter() can be exploited in similar ways.
Rather than the tricky generator used to exploit
tuple(), the attached test case uses a subclass of
tuple with a malicious __getitem__ method. The pattern
being exploited is the same, however: a built-in
function pre-allocates a tuple, then fills it using
calls to user-defined code.
gc_inspection.py.diff also expands the infrastructure
in gc_inspection.py, allowing multiple test functions
to run that could crash the interpreter.
The second patch, fix_filter_crash.patch, is against
Python/bltinmodule.c and adds
_PyObject_GC_TRACK/UNTRACK macros around the call to
the type's sq_item slot in filtertuple().
----------------------------------------------------------------------
>Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 13:01
Message:
Logged In: YES
user_id=849994
I will not disagree with Raymond :)
Furthermore, with your patch to gc_inspection.py, it doesn't
even crash anymore (without the other patch applied).
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-07-05 18:01
Message:
Logged In: YES
user_id=80475
FWIW, I think these safe-cracking style efforts at
creating crashers is a waste of time. Please focus your
efforts on fixing real bugs that matter, not in creating
strange self-referential twists designed to poke holes in
specific implementation details. There is no end to the
kind of things like this that can be found and "fixing"
them involves either making the code more convoluted or
making the code slower but it won't make life better for
most users. Also, I'm concerned that these "fixes" would
need to be reviewed with extreme care, lest we introduce
some new, real bug that DOES impact people's lives. If
there were a real problem with filter(), we would have
known it long ago.
----------------------------------------------------------------------
Comment By: Collin Winter (collinwinter)
Date: 2006-07-05 17:54
Message:
Logged In: YES
user_id=1344176
An alternative fix for this would be not to invoke
filter{tuple,string,unicode} on instances of subclasses of
tuple, str and unicode.
This would fix this bug because you have to be using a
subclass of one of these types to exploit the preallocation.
As a side-effect, this would also resolve the issue I raised
in bug #1517509 concerning filter()'s treatment of these
subtypes re: the iterator protocol.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517663&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
