[Bug 900896] New: VUL-0: CVE-2014-8240 tigervnc: integer overflow flaw, leading to a heap-based buffer overflow in screen size handling
http://bugzilla.suse.com/show_bug.cgi?id=900896 Bug ID: 900896 Summary: VUL-0: CVE-2014-8240 tigervnc: integer overflow flaw, leading to a heap-based buffer overflow in screen size handling Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: security-team@suse.de Reporter: krahmer@suse.com QA Contact: qa-bugs@suse.de Found By: Security Response Team Blocker: --- rh#1151307 References: https://bugzilla.redhat.com/show_bug.cgi?id=1151307 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=900896
Sebastian Krahmer
http://bugzilla.suse.com/show_bug.cgi?id=900896
Michal Srb
http://bugzilla.suse.com/show_bug.cgi?id=900896
--- Comment #1 from Michal Srb
http://bugzilla.suse.com/show_bug.cgi?id=900896
--- Comment #2 from Sebastian Krahmer
http://bugzilla.suse.com/show_bug.cgi?id=900896
--- Comment #3 from Michal Srb
"Integer overflow" sounds different though. Sounds like there is some computation inside e.g. malloc(a*b*c) itself, that cannot be checked after malloc returns - assert() or not.
Alright, I found one possible overflow, but it's not actually dangerous. The width and height in VNC protocol are transported as unsigned 16bit number. Tigervnc picks them up and stores them into ints. They are stored as ints without any calculations until they are fed into XCreateImage or XShmCreateImage. In case of XCreateImage one suspicious place follows: malloc(xim->bytes_per_line * xim->height); Where xim is structure filled by XCreateImage, xim->height is int equal to the height and xim->bytes_per_line is int equal to the width times 4 (at most, depends on screen depth). So at worst you can smuggle 0xffff as width and height and you get (int)0xffff * (int)0xffff * 4 = -524284 as parameter of malloc. You never overflow far enough to get back to positive numbers. Parameter of malloc is size_t, so on 64 bit system it turns into 18446744073709027332, on 32 bit into 4294443012. Both should fail and tigervnc quits. Even if it somehow got pass this point, tigervnc will most probably abort because of error message from X server who will protest against such big images. Relying on that is of course not good practice and I will make patch that will prevent the overflow explicitly. But my question remains - we don't know what the Red Hat bug is about. Whether they found this or something else...
I also see we have it on SLE12?
Yes, we have tigervnc in SLE12. And any fixes will go there as well. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=900896
Egbert Eich
http://bugzilla.suse.com/show_bug.cgi?id=900896
Sebastian Krahmer
http://bugzilla.suse.com/show_bug.cgi?id=900896
Egbert Eich
http://bugzilla.suse.com/show_bug.cgi?id=900896
Sebastian Krahmer
http://bugzilla.suse.com/show_bug.cgi?id=900896
Michal Srb
http://bugzilla.suse.com/show_bug.cgi?id=900896
Sebastian Krahmer
http://bugzilla.suse.com/show_bug.cgi?id=900896
Michal Srb
participants (1)
-
bugzilla_noreply@novell.com