Re: Found a buffer-overflow defect in asynchronous database connection API PQconnectPoll - Mailing list pgsql-bugs

On 23-Jun-2021, at 7:03 PM, Sudheer H R <sudheer.hr@tekenlight.com> wrote:

Thanks for the response

I am running this on a MacBook Pro Big Sur OSX 11.4 , the database server is running in another process. I build the executable and run them on the command line

Attached are the source code files and make file (quite simple and trivial)

Pasted below is the AddressSanitizer report (which gets produced upon any buffer overflow, when compiled and linked with -fsanitize=address)

Sudheer

<a.c>

<b.c>

<makefile>

Upon running program ./a

open_connection_finalize[1]

=================================================================

==94769==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60700001abd6 at pc 0x0001099618f4 bp 0x7ffee631b910 sp 0x7ffee631b0d0

READ of size 71 at 0x60700001abd6 thread T0

    #0 0x1099618f3 in wrap_strlen+0x183 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x198f3)

    #1 0x1099127ea in dopr+0xe4 (libpq.5.dylib:x86_64+0x1c7ea)

    #2 0x1099126e2 in pg_vsnprintf+0x52 (libpq.5.dylib:x86_64+0x1c6e2)

    #3 0x10990ae91 in appendPQExpBufferVA+0x3e (libpq.5.dylib:x86_64+0x14e91)

    #4 0x10990afae in appendPQExpBuffer+0xc4 (libpq.5.dylib:x86_64+0x14fae)

    #5 0x10990db64 in pg_GSS_error_int+0x5b (libpq.5.dylib:x86_64+0x17b64)

    #6 0x10990daf3 in pg_GSS_error+0x66 (libpq.5.dylib:x86_64+0x17af3)

    #7 0x10990e4fe in pqsecure_open_gss+0x334 (libpq.5.dylib:x86_64+0x184fe)

    #8 0x1098fc40d in PQconnectPoll+0xac9 (libpq.5.dylib:x86_64+0x640d)

    #9 0x1098e5a2c in main+0x46c (a:x86_64+0x100003a2c)

    #10 0x7fff20563f5c in start+0x0 (libdyld.dylib:x86_64+0x15f5c)

0x60700001abd6 is located 0 bytes to the right of 70-byte region [0x60700001ab90,0x60700001abd6)

allocated by thread T0 here:

    #0 0x109990460 in wrap_malloc+0xa0 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x48460)

    #1 0x7fff2d8f7396 in _gss_mg_get_error+0x96 (GSS:x86_64+0x9396)

    #2 0x7fff2d8f71e6 in gss_display_status+0x176 (GSS:x86_64+0x91e6)

    #3 0x10990db4b in pg_GSS_error_int+0x42 (libpq.5.dylib:x86_64+0x17b4b)

    #4 0x10990daf3 in pg_GSS_error+0x66 (libpq.5.dylib:x86_64+0x17af3)

    #5 0x10990e4fe in pqsecure_open_gss+0x334 (libpq.5.dylib:x86_64+0x184fe)

    #6 0x1098fc40d in PQconnectPoll+0xac9 (libpq.5.dylib:x86_64+0x640d)

    #7 0x1098e5a2c in main+0x46c (a:x86_64+0x100003a2c)

    #8 0x7fff20563f5c in start+0x0 (libdyld.dylib:x86_64+0x15f5c)

SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x198f3) in wrap_strlen+0x183

Shadow bytes around the buggy address:

  0x1c0e00003520: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd

  0x1c0e00003530: fd fd fd fd fd fd fa fa fa fa fd fd fd fd fd fd

  0x1c0e00003540: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd

  0x1c0e00003550: fd fa fa fa fa fa fd fd fd fd fd fd fd fd fd fa

  0x1c0e00003560: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fa fa

=>0x1c0e00003570: fa fa 00 00 00 00 00 00 00 00[06]fa fa fa fa fa

  0x1c0e00003580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e00003590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e000035a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e000035b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e000035c0: 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

  Shadow gap:              cc

==94769==ABORTING

Abort

Upon running program ./b

==94780==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60700001abd6 at pc 0x0001007e08f4 bp 0x7ffeef49c8a0 sp 0x7ffeef49c060

READ of size 71 at 0x60700001abd6 thread T0

    #0 0x1007e08f3 in wrap_strlen+0x183 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x198f3)

    #1 0x1007937ea in dopr+0xe4 (libpq.5.dylib:x86_64+0x1c7ea)

    #2 0x1007936e2 in pg_vsnprintf+0x52 (libpq.5.dylib:x86_64+0x1c6e2)

    #3 0x10078be91 in appendPQExpBufferVA+0x3e (libpq.5.dylib:x86_64+0x14e91)

    #4 0x10078bfae in appendPQExpBuffer+0xc4 (libpq.5.dylib:x86_64+0x14fae)

    #5 0x10078eb64 in pg_GSS_error_int+0x5b (libpq.5.dylib:x86_64+0x17b64)

    #6 0x10078eaf3 in pg_GSS_error+0x66 (libpq.5.dylib:x86_64+0x17af3)

    #7 0x10078f4fe in pqsecure_open_gss+0x334 (libpq.5.dylib:x86_64+0x184fe)

    #8 0x10077d40d in PQconnectPoll+0xac9 (libpq.5.dylib:x86_64+0x640d)

    #9 0x10077b0f1 in connectDBComplete+0x11f (libpq.5.dylib:x86_64+0x40f1)

    #10 0x10077ac61 in PQconnectdbParams+0x23 (libpq.5.dylib:x86_64+0x3c61)

    #11 0x100764a84 in main+0x3a4 (b:x86_64+0x100003a84)

    #12 0x7fff20563f5c in start+0x0 (libdyld.dylib:x86_64+0x15f5c)

0x60700001abd6 is located 0 bytes to the right of 70-byte region [0x60700001ab90,0x60700001abd6)

allocated by thread T0 here:

    #0 0x10080f460 in wrap_malloc+0xa0 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x48460)

    #1 0x7fff2d8f7396 in _gss_mg_get_error+0x96 (GSS:x86_64+0x9396)

    #2 0x7fff2d8f71e6 in gss_display_status+0x176 (GSS:x86_64+0x91e6)

    #3 0x10078eb4b in pg_GSS_error_int+0x42 (libpq.5.dylib:x86_64+0x17b4b)

    #4 0x10078eaf3 in pg_GSS_error+0x66 (libpq.5.dylib:x86_64+0x17af3)

    #5 0x10078f4fe in pqsecure_open_gss+0x334 (libpq.5.dylib:x86_64+0x184fe)

    #6 0x10077d40d in PQconnectPoll+0xac9 (libpq.5.dylib:x86_64+0x640d)

    #7 0x10077b0f1 in connectDBComplete+0x11f (libpq.5.dylib:x86_64+0x40f1)

    #8 0x10077ac61 in PQconnectdbParams+0x23 (libpq.5.dylib:x86_64+0x3c61)

    #9 0x100764a84 in main+0x3a4 (b:x86_64+0x100003a84)

    #10 0x7fff20563f5c in start+0x0 (libdyld.dylib:x86_64+0x15f5c)

SUMMARY: AddressSanitizer: heap-buffer-overflow (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x198f3) in wrap_strlen+0x183

Shadow bytes around the buggy address:

  0x1c0e00003520: fd fd fd fd fd fd fd fd fa fa fa fa fd fd fd fd

  0x1c0e00003530: fd fd fd fd fd fd fa fa fa fa fd fd fd fd fd fd

  0x1c0e00003540: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fd

  0x1c0e00003550: fd fa fa fa fa fa fd fd fd fd fd fd fd fd fd fa

  0x1c0e00003560: fa fa fa fa fd fd fd fd fd fd fd fd fd fd fa fa

=>0x1c0e00003570: fa fa 00 00 00 00 00 00 00 00[06]fa fa fa fa fa

  0x1c0e00003580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e00003590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e000035a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e000035b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa

  0x1c0e000035c0: 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

  Shadow gap:              cc

==94780==ABORTING

Abort

On 23-Jun-2021, at 6:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Sudheer H R <sudheer.hr@tekenlight.com> writes:

While trying to sanitise the code for heap buffer overflows I compiled and linked the executable with clang -fsanitize=“address” option. The connection library indicates a buffer over flow in an internal source code of the module.

Hm, interesting.  Our code is expecting that gss_display_status() returns
a null-terminated string, but this trace suggests that the string is
not necessarily null-terminated.  The documentation I found on the net
is unclear on the point, and the code I could find is split as to how
the string is treated.  If it's not supposed to be null-terminated,
we're hardly the only ones making that mistake.

In any case, you wouldn't get here unless we'd run into some kind of
problem trying to make a GSS connection.  Could you maybe explain the
conditions you're running this under, and/or print out the failure message
it constructs?

regards, tom lane