GNOME Bugzilla – Bug 641802
Vino 2.26.1 and 2.32.1 allows remote attackers to trigger an out-of-bounds write
Last modified: 2011-05-02 17:01:03 UTC
Summary ======= Program: vino-server (vino 2.32.1) Type: Out-of-bounds write to arbitrary memory location Impact: Critical Authors ======= The Bitblaze group at UC Berkeley. http://bitblaze.cs.berkeley.edu/ Description =========== The rfbTranslateNone function in rfbserver.c in vino-server in Vino 2.26.1 and 2.32.1 (the latest release) allows remote attackers to trigger an out-of-bounds write, via a very large "X position" value or a vary large "Y position" value in a "client framebuffer update request" packet. Platforms affected ================== The bug has been tested on a Ubuntu 9.04 platform using both Vino 2.26.1 and Vino 2.32.1, the latter one is the latest version of the program. Other versions between these two releases could similarly be affected. Vulnerable function =================== In process: vino-server Function backtrace stack (in vino 2.32.1):
+ Trace 225886
Impact ====== Critical (Arbitrary write) Reproducible ============ Yes, the bug is reproducible. And the pcap file is as attached. Vulnerability description ========================= The vulnerability is a out-of-bounds write. It is triggered by the memcpy function in rfbTranslateNone, when handling the "client framebuffer update request" packet from a vnc client: void rfbTranslateNone(char *table, rfbPixelFormat *in, rfbPixelFormat *out, char *iptr, char *optr, int bytesBetweenInputLines, int width, int height) { int bytesPerOutputLine = width * (out->bitsPerPixel / 8); while (height > 0) { memcpy(optr, iptr, bytesPerOutputLine); //out-of-bounds write iptr += bytesBetweenInputLines; optr += bytesPerOutputLine; height--; } } Here 'optr' points out of the boundary, and 'optr' is from the caller: rfbSendRectEncodingRaw (rfbserver.c:1328) (*cl->translateFn)(cl->translateLookupTable, &(cl->screen->rfbServerFormat), &cl->format, fbptr, &cl->updateBuf[cl->ublen], cl->screen->paddedWidthInBytes, w, nlines); // (*cl->translateFn) is rfbTranslateNone, and the value of fbptr is passed to optr. In rfbSendRectEncodingRaw, fbptr is calculated from some fields in the packet: char *fbptr = (cl->screen->frameBuffer + (cl->screen->paddedWidthInBytes * y) + (x * (cl->screen->bitsPerPixel / 8))); where x is 29696 and y is 32768 in our PoC packet. Also the core dump file and original binary are attached with this email.
Created attachment 182540 [details] [review] Validate framebuffer update packet size Hi Kevin, I am the new maintainer of Vino, and I would very much like to get this bug fixed quickly. I am not that familiar with the libvncserver code, but I have attached a patch to this bug which I think should fix the problem. Can you verify that it is a correct fix? I also realised that this part of the Vino code is from libvncserver (http://libvncserver.git.sourceforge.net/git/gitweb.cgi?p=libvncserver/libvncserver;a=blob;f=libvncserver/rfbserver.c;h=73be34cb8a8cc70a19ff10d85b928d8e1cfed87d;hb=HEAD#l2968) and that code also seems to have the same problem, which could affect other projects.
Hi David, Yes I tried this patch on Vino 2.32.1 and it fixes this bug. However, Bug 641803 (https://bugzilla.gnome.org/show_bug.cgi?id=641803) remains unpatched, which I believe can be patched together with this bug by somehow. I think patching somewhere else can fix both of these two bugs from the root cause. Thanks! Thanks, Kevin
Thanks for your testing Kevin. I will have a fix for bug 641803 by tonight, hopefully. I checked the krfb (KDE equivalent of Vino) source code and discovered that it also does not validate the framebuffer update packet, in the same way as the libvncserver code linked from comment 1 and as the code in Vino. I think that we should let those projects know and try to coordinate a security announcement. Do you have any experience with this process?
Unfortunately I'm a newbie in this vulnerability reporting process. But I did reserved a CVE number for this vulnerability(CVE-2011-0904). Similarly, I also reserved a CVE number for Bug 641803, which I'll comment in that thread for consistency. I'm not sure whether krfb have similar security issues because it's possible that they have a boundary check before reaching the library. But I think it might help by letting them know this issue. Thanks, Kevin
Distro contacts for security issues: security@gnome.org , security@kde.org . To coordinate a CVE among distributions, last time I was involved vendor-sec@lst.de was used, but situation is in a flux right now, see http://lwn.net/Articles/431228/ and http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec
Created attachment 182842 [details] [review] Avoid out-of-bounds memory write Updated patch to include CVE information. As mentioned in bug 641803, comment 5, this is just pending on an email to (and response from) security@gnome.org
Would it be possible to share the reproducer for this and bug 641803? Red Hat has to backport this fix to a number of versions of vino, so being able to verify we've actually fixed it would be helpful. Thanks.
Created attachment 186688 [details] [review] updated patch with generic fix for this bug and 641803 Attaching an updated patch that solves this bug and bug 641803 generically. This fix has been tested successfully with the reproducer that Kevin supplied.
*** Bug 641803 has been marked as a duplicate of this bug. ***
Comment on attachment 186688 [details] [review] updated patch with generic fix for this bug and 641803 Pushed to gnome-2-28, gnome-2-30, gnome-2-32, gnome-3-0 and master branches as commits dff52694a384fe95195f2211254026b752d63ec4, 0c2c9175963fc56bf2af10e42867181332f96ce0, e17bd4e369f90748654e31a4867211dc7610975d, 456dadbb5c5971d3448763a44c05b9ad033e522f and 8beefcf7792d343c10c919ee0c928c81f73b1279. I released new tarballs of 2.28.3, 2.32.3 and 3.0.2. If any more are desired, please reopen this bug and request them.