homepage

As reported at
http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065826.html
. There is an integer overflow in imageop module which results in an
interpreter crash. Original proof of concept code is attached.

It's unclear if this only causes a crash or if it can inject data. 
Referenced mailing list post points out where one error is.

Cartman, please refrain from using vulgarities in your sample code. It's
hard to take a bug report seriously with such variable names.

Guido: That code came from the full-disclosure list posting, I think
cartman was just passing it on.

So I think this is all the places integer overflow checking is needed
in imageop.c and rbgimgmodule.c.
 There might be checks here which can't be exploited anyway, and I
haven't checked any other files yet.
 Feel free to comment.
 Ps. This is against the 2.5 in Fedora-7, but it should apply to upstream.

Guido,
The poc is taken as is, sorry.

And now the obvious typo fix, *sigh*.

nevyn: Your patch cleanly applies to python 2.4.4 and fixes the
interpreter crash with poc.py
Thanks.

Hm. First of all, it seems the imageop module has completely missed the
Py_ssize_t changes.
Second, I don't think that "if ( x != len / y )" is a valid replacement
for "if ( x*y != len )" -- consider x==5, y==2, len==11.

Guido: It's true that that len can be slightly bigger than x*y, the big
thing is that it can't be smaller so we can malloc(len) and use upto x*y
(which was my main focus).
 I first looked at any of this code today, but I didn't see any reason
that having len be slightly larger would be a problem ... and in pretty
much all cases it'll be len == x*y.
 However we could have both cases covered by doing:
 if ( (len != x*y) || (x != (len / y)) )
...but esp. at that point it seems like we'd want some interface so that
we could just do something like:
 if ( check_mutliplies2(len, x, y) )

Neal, didn't you say you had a fix for this?

Not sure who Neal is, and this probably isn't a final upstream fix ...
but it's what I've applied to Fedora's python. It's basically the same
patch as before, but it keeps the original * tests instead of just
replacing them with / tests. So given:
 if x * y != len
...the first patch did:
 if len / x != y
...and this patch does:
 if x * y != len ||
 len / x != y

Is this final yet? Our system security group is a little paranoid about
buffer overflows of any sort and are starting to make noises. I can
confirm that the Oct 20 patch applies against Python 2.5.1 on RHEL4, and
that the string length error is generated when running poc.py.

Sigh. I'll try to make time to review & apply this.

I've applied the last patch I posted to recent RHEL and Fedora
releases, and it doesn't seem to break anything ... and from what I
could see it fixed the problem.

Same here for Pardus Linux, applied the patch without a regression.

Sorry this missed the 2.5.2 release. I'll try to look again before
2.5.3 is imminent.

The following test cases still cause bus errors with the patch applied:
import imageop; imageop.rgb82rgb('A'*(2**30), 32768, 32768)
import imageop; imageop.grey2rgb('A'*(2**30), 32768, 32768)

I think this was a module that I skipped. I think Anthony might have
had a patch, but if we have a fix, I'm not sure it matters. We need to
fix this for 2.5.3, upping the priority.

Uploading patch that addresses the test cases above. It applies on top of 
nevyn’s latest patch.

This is not a release blocker for 2.6 or 3.0.

This _must_ be a release blocker for Python 3.0, Its a shame that this
bug still is not fixed and a patch is available for months now.

imageop is deleted in 3.0. See PEP 3108. So it can't be a release
blocker. This also explains my general lack of interest in this module.

I am sorry for the drama then, :)

Does anybody still care about this for 2.6?

The two segfaults reported in msg64682 are still there in 2.6.
I'm elevating this to release blocker but don't have time to fix this
myself.

Looking into this now.

Latest patches applied to 2.5 branch: r65878.
And to 2.6 trunk: r65880.