On Fri, Mar 11, 2005 at 12:54:47PM +0000, Matthias Scheler wrote: >On Thu, Mar 10, 2005 at 06:37:06PM -0500, David Dawes wrote: >> How about the attached patch? > >I just pulled OpenBSD-current's Xpm source into NetBSD. It has fixes >for this vulnerability and various other bug fixes from X.org.
I looked at one of the patches out there for this, and it only seemed to solve one end of the problem: trapping a negative XImage.bitmap_unit value, which, when converted to a signed value allowed the heap to be overflowed. It didn't address the same problem arising from a large positive XImage.bitmap_unit value, or a similar problem with the XImage.bits_per_pixel field, but the patch I sent does. There are also other XImage fields that are not validated, but from a cursory look they don't appear to be used by Xpm in a way that can cause write-to-stack or heap overflows. >> What is the mechanism for getting the bad data into the privileged >> program to start with? > >Maybe a web browser? Well, the bad XImage data has to come from somewhere. The two places that libXpm gets XImage data that it (or libX11) doesn't have direct control of is via XGetImage() and XCreateImage(), both of which use data provided by the X server without any validation. This is why I suggested that perhaps libX11 should validate such data before passing it back to the application. If an application is using user-supplied data to generate an XImage in another way and not validating it, then that is arguably a bug in the application. Either way the patch should trap that within libXpm. I'm curious about the mechanism because it might hint at other issues that need attention. Anyway, this is from a quick look at the reported problem based on the description in the CAN. If you or anyone else see something that I'm missing, let me know. David _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
