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

heap-buffer-overflow [tls_bench+0x50ff15] #2032

Closed
RootUp opened this issue Jan 15, 2019 · 4 comments
Closed

heap-buffer-overflow [tls_bench+0x50ff15] #2032

RootUp opened this issue Jan 15, 2019 · 4 comments
Assignees

Comments

@RootUp
Copy link

RootUp commented Jan 15, 2019

Hi Team,

Summary

I have compiled wolfSSL using clang and a heap based buffer overflow is observed in tls_bench.c

System info:

Linux zero 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

ASAN

==4088==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000000480 at pc 0x00000050ff16 bp 0x7fef206fdbf0 sp 0x7fef206fdbe8
WRITE of size 1 at 0x619000000480 thread T2
    #0 0x50ff15  (/wolfssl/examples/benchmark/tls_bench+0x50ff15)
    #1 0x4dfa52  (/wolfssl/examples/benchmark/tls_bench+0x4dfa52)
    #2 0x7fef243ac6da  (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
    #3 0x7fef23ab188e  (/lib/x86_64-linux-gnu/libc.so.6+0x12188e)

0x619000000480 is located 0 bytes to the right of 1024-byte region [0x619000000080,0x619000000480)
allocated by thread T2 here:
    #0 0x4d1fa0  (/wolfssl/examples/benchmark/tls_bench+0x4d1fa0)
    #1 0x50f277  (/wolfssl/examples/benchmark/tls_bench+0x50f277)
    #2 0x4dfa52  (/wolfssl/examples/benchmark/tls_bench+0x4dfa52)

Thread T2 created by T0 here:
    #0 0x435490  (/wolfssl/examples/benchmark/tls_bench+0x435490)
    #1 0x50cbf5  (/wolfssl/examples/benchmark/tls_bench+0x50cbf5)
    #2 0x5101d0  (/wolfssl/examples/benchmark/tls_bench+0x5101d0)
    #3 0x7fef239b1b96  (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/wolfssl/examples/benchmark/tls_bench+0x50ff15) 
Shadow bytes around the buggy address:
  0x0c327fff8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c327fff8080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c327fff8090:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff80a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff80b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff80c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff80d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c327fff80e0: 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
==4088==ABORTING
@dgarske dgarske self-assigned this Jan 15, 2019
@dgarske
Copy link
Contributor

dgarske commented Jan 15, 2019

Hi RootUp,

Thanks for the detailed report. I will personally investigate and make sure this is resolved in our TLS benchmark by cipher suite tool.

Its possible the issue has already been fixed in PR #2013 here:
#2013

Thanks,
David Garske, wolfSSL

@RootUp
Copy link
Author

RootUp commented Jan 16, 2019

Vulnerable code in tls_bench.c

    /* Allocate and initialize a packet sized buffer */
    writeBuf = (unsigned char*)malloc(info->packetSize);
    if (writeBuf != NULL) {
        strncpy((char*)writeBuf, kTestStr, info->packetSize);
        *(writeBuf + info->packetSize) = '\0';
    }
    else {
        err_sys("failed to allocate memory");
}

@dgarske
Copy link
Contributor

dgarske commented Jan 17, 2019

Hi RootUp,

Both of these reports have already been resolved in PR #2013, which was merged into our master branch yesterday (1/16/19). I confirmed via fsanitize and scan-build, plus manual testing.

The first issue was resolved, by ensuring the max buffer size is setup correctly. See line 84: #define MEM_BUFFER_SZ ((16 * 1024) + 38 + 32) /* Must be large enough to handle max packet size plus max TLS header MAX_MSG_EXTRA */

The second issue was resolved by using this code starting at line 650:

/* Allocate and initialize a packet sized buffer */
writeBuf = (unsigned char*)XMALLOC(info->packetSize, NULL,
    DYNAMIC_TYPE_TMP_BUFFER);
if (writeBuf != NULL) {
    XMEMSET(writeBuf, 0, info->packetSize);
    XSTRNCPY((char*)writeBuf, kTestStr, info->packetSize);
}

The strncpy will handle info->packetSize smaller than kTestStr.

I am marking this issue closed. Please let me know if you find any other issues.

Thanks,
David Garske, wolfSSL

@dgarske dgarske closed this as completed Jan 17, 2019
@kaleb-himes
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants