Re: Found a buffer-overflow defect in asynchronous database connection API PQconnectPoll

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

From: Sudheer H R <sudheer.hr@tekenlight.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2021-06-23T13:41:20Z
Lists: pgsql-bugs
Further to this.

I downloaded the source from the listing (version 13.3) and build the targets.

With the built version this worked fine.

Sudheer



> 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 <mailto:tgl@sss.pgh.pa.us>> wrote:
>> 
>> Sudheer H R <sudheer.hr@tekenlight.com <mailto: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
> 

Commits

  1. Don't assume GSSAPI result strings are null-terminated.