Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SECURITY: Heap use-after-free in tightvnc-filetransfer extension #241

Closed
PaulCher opened this issue Aug 14, 2018 · 0 comments
Closed

SECURITY: Heap use-after-free in tightvnc-filetransfer extension #241

PaulCher opened this issue Aug 14, 2018 · 0 comments
Assignees
Labels

Comments

@PaulCher
Copy link

Since security issues have been already reported to this repository and I didn't manage to find any other information about reporting vulnerabilities, I feel that it is okay to report this issue here.

In libvncserver/tightvnc-filetransfer/handlefiletransferrequest.c function HandleFileDownloadCancelRequest contains the following code :

    if((n = rfbReadExact(cl, reason, msg.fdc.reasonLen)) <= 0) {
        if (n < 0)
            rfbLog("File [%s]: Method [%s]: Error while reading " 
                

"FileDownloadCancelMsg\n", __FILE__, __FUNCTION__);
            rfbCloseClient(cl);
    }

    rfbLog("File [%s]: Method [%s]: File Download Cancel Request received:"
        " reason <%s>\n", __FILE__, __FUNCTION__, reason);
	
    pthread_mutex_lock(&fileDownloadMutex);
    CloseUndoneFileTransfer(cl, rtcp);
    pthread_mutex_unlock(&fileDownloadMutex);

This vulnerability requires tight file transfer extesion to be enabled. rfbCloseClient function calls rfbTightExtensionClientClose extension destructor routine which free()s extension data, in this case -- rfbTightClientPtr rtcp variable. rtcp is later used as argument to CloseUndoneFileTransfer function, which results use-after-free. Asan report:

==49353==ERROR: AddressSanitizer: heap-use-after-free on address 0x625000004960 at pc 0x000000670c4e bp 0x7ffe16985710 sp 0x7ffe16985708
READ of size 4 at 0x625000004960 thread T0
    #0 0x670c4d in CloseUndoneFileTransfer /libvncserver/tightvnc-filetransfer/filetransfermsg.c:745:21
    #1 0x663f82 in HandleFileDownloadCancelRequest libvncserver/tightvnc-filetransfer/handlefiletransferrequest.c:592:2
    #2 0x65d2e9 in handleMessage /libvncserver/tightvnc-filetransfer/rfbtightserver.c:390:2
    #3 0x65cf9d in rfbTightExtensionMsgHandler /libvncserver/tightvnc-filetransfer/rfbtightserver.c:418:9
    #4 0x570611 in rfbProcessClientNormalMessage /libvncserver/rfbserver.c:2677:13
    #5 0x5610ab in rfbProcessClientMessage /libvncserver/rfbserver.c:650:9

0x625000004960 is located 8288 bytes inside of 8320-byte region [0x625000002900,0x625000004980)
freed by thread T0 here:
    #0 0x515670 in __interceptor_free.localalias.0 /llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:68
    #1 0x65d3a0 in rfbTightExtensionClientClose /libvncserver/tightvnc-filetransfer/rfbtightserver.c:452:3
    #2 0x5a3543 in rfbCloseClient /libvncserver/sockets.c:527:13
    #3 0x663ee9 in HandleFileDownloadCancelRequest /libvncserver/tightvnc-filetransfer/handlefiletransferrequest.c:585:6
    #4 0x65d2e9 in handleMessage /libvncserver/tightvnc-filetransfer/rfbtightserver.c:390:2
    #5 0x65cf9d in rfbTightExtensionMsgHandler /libvncserver/tightvnc-filetransfer/rfbtightserver.c:418:9
    #6 0x570611 in rfbProcessClientNormalMessage /libvncserver/rfbserver.c:2677:13
    #7 0x5610ab in rfbProcessClientMessage /libvncserver/rfbserver.c:650:9

previously allocated by thread T0 here:
    #0 0x515840 in __interceptor_malloc /llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:88
    #1 0x65d907 in rfbHandleSecTypeTight /libvncserver/tightvnc-filetransfer/rfbtightserver.c:497:50
    #2 0x599cbd in rfbProcessClientSecurityType /libvncserver/auth.c:351:8
    #3 0x561061 in rfbProcessClientMessage /libvncserver/rfbserver.c:640:9

SUMMARY: AddressSanitizer: heap-use-after-free /libvncserver/tightvnc-filetransfer/filetransfermsg.c:745:21 in CloseUndoneFileTransfer
Shadow bytes around the buggy address:
  0x0c4a7fff88d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff88e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff88f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff8900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a7fff8910: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c4a7fff8920: fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd
  0x0c4a7fff8930: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff8940: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff8950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff8960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fff8970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb

This security issue is a result of my work at Kaspersky Lab ICS CERT Vulnerability Research Group at position of Security Researcher.

For more information about ICS CERT please contact:
ics-cert@kaspersky.com
https://ics-cert.kaspersky.com/

Best regards,
Pavel Cheremushkin

@bk138 bk138 self-assigned this Aug 21, 2018
@bk138 bk138 added the bug label Aug 21, 2018
@bk138 bk138 added this to the Release 0.9.12 milestone Aug 21, 2018
@bk138 bk138 closed this as completed in ca2a5ac Oct 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants