[arch-security] [Arch Linux Security Advisory ASA-201410-10] libvncserver: remote code execution, denial of service

Remi Gacogne rgacogne at archlinux.org
Fri Oct 24 11:51:25 UTC 2014

Arch Linux Security Advisory ASA-201410-10

Severity: Critical
Date    : 2014-10-24
CVE-ID  : CVE-2014-6051, CVE-2014-6052, CVE-2014-6053, CVE-2014-6054,
Package : libvncserver
Type    : Remote code execution, Denial of service
Remote  : Yes
Link    : https://wiki.archlinux.org/index.php/CVE-2014


The package libvncserver before version 0.9.10-1 is vulnerable to remote
code execution client-side, and denial of service server-side.


Upgrade to 0.9.10-1.

# pacman -Syu "libvncserver>=0.9.10-1"

The problem has been fixed upstream in version 0.9.10.




CVE-2014-6051 Integer overflow in MallocFrameBuffer() on client side.

A malicious VNC server could advertise a very large screen size (by RFB
protocol, width and height are 16-bit integers), resulting in an integer
overflow during malloc() on client-side. Heap corruption, and possibly
remote code execution on client-side could ensue.

CVE-2014-6052 Lack of malloc() return value checking on client side.

malloc() return value was not checked on client-side during framebuffer
setup. A malicious VNC server that advertises a large enough screen size
to make malloc() fail could basically map the framebuffer at address 0,
and write anything-anywhere in client process memory using selective
FramebufferUpdate messages. This could certainly turn into remote code
execution on client-side.

CVE-2014-6053 Server crash on a very large ClientCutText message.

A malicious client could advertise a very large ClientCutText message
size (by RFB protocol, size is encoded on a 32-bit integer). malloc() is
likely to fail in that case; as malloc() return value is not checked,
this will most likely result in a server crash.

CVE-2014-6054 Server crash when scaling factor is set to zero.

A malicious client could set the scaling factor to 0, which will result
in a server crash (division by zero).

CVE-2014-6055 Multiple stack overflows in File Transfer feature.

1/ The non-standard file transfer messages (UltraVNC feature) will
blindly strcpy() client-provided file and directory names into a
stack-based buffer of size MAX_PATH, resulting in multiple stack-based
buffer overflows on server-side.

2/ Client-supplied FileTime attribute is copied into a stack-based
buffer of size 64 during rfbFileTransferOffer message parsing, resulting
in a stack-based buffer overflow on server-side.


A malicious server or an attacker in position of man-in-the-middle could
remotely execute arbitrary code on a vulnerable client.
A malicious client or an attacked in position of man-in-the-middle could
remotely crash a vulnerable server.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-security/attachments/20141024/fc3a4fe5/attachment.bin>

More information about the arch-security mailing list