summaryrefslogtreecommitdiffstats
path: root/libvncclient/rfbproto.c
diff options
context:
space:
mode:
authorChristian Beier <dontmind@freeshell.org>2014-10-10 13:51:48 +0200
committerChristian Beier <dontmind@freeshell.org>2014-10-10 13:51:48 +0200
commit95efcfbf0c39e0b493509d2ad829b0d688641b41 (patch)
treec1450ccf5dbcd3763e081aa0549621f1081a3bd1 /libvncclient/rfbproto.c
parentcdc5b5196c65fba7ad90caafc9c8090c72458c4c (diff)
downloadlibvncserver-95efcfbf0c39e0b493509d2ad829b0d688641b41.zip
libvncserver-95efcfbf0c39e0b493509d2ad829b0d688641b41.tar.gz
Fix potential memory corruption in libvncclient.
Fixes (maybe amongst others) the following oCERT report ([oCERT-2014-008]): LibVNCServer HandleRFBServerMessage rfbServerCutText malicious msg.sct.length It looks like there may be a chance for potential memory corruption when a LibVNCServer client attempts to process a Server Cut Text message. case rfbServerCutText: { char *buffer; if (!ReadFromRFBServer(client, ((char *)&msg) + 1, sz_rfbServerCutTextMsg - 1)) return FALSE; msg.sct.length = rfbClientSwap32IfLE(msg.sct.length); << Retrieve malicious length buffer = malloc(msg.sct.length+1); << Allocate buffer. Can return 0x0 if (!ReadFromRFBServer(client, buffer, msg.sct.length)) << Attempt to write to buffer return FALSE; buffer[msg.sct.length] = 0; << Attempt to write to buffer if (client->GotXCutText) client->GotXCutText(client, buffer, msg.sct.length); << Attempt to write to buffer free(buffer); break; } If a message is provided with an extremely large size it is possible to cause the malloc to fail, further leading to an attempt to write 0x0.
Diffstat (limited to 'libvncclient/rfbproto.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud