Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

Hi all, Just found what looks like a bug in Informix ESQL/C... (detected with gcc address sanitizer) With the CONNECT TO instruction, when providing a user name with 16 bytes, I get a heap-buffer-overflow. When user name is 15 or 17 bytes long, no issue... quite strange. Are HCL people watching this forum? Where should I report this today? Attached, the test case. Cheers! Seb ------------------------------ SEBASTIEN SF FLAESCH ------------------------------ #Informix

The code is very simple: EXEC SQL BEGIN DECLARE SECTION; const char * un16 = "abcdefghijklmnop"; // 16 bytes => error const char * up = "password"; EXEC SQL END DECLARE SECTION; EXEC SQL CONNECT TO "testdb1" USER :un16 USING :up; ------------------------------ SEBASTIEN SF FLAESCH ------------------------------

HI SEBASTIEN, Could you share the version of CSDK/ESQL you are using? "esql -V" and/or "esql -version" output. Also compiler version of gcc. Thanks -Shesh ------------------------------ Sheshnarayan Agrawal ------------------------------

Here is my config: sf@toro:/tmp$ uname -a Linux toro 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux sf@toro:/tmp$ cat /etc/debian_version 10.3 sf@toro:/tmp$ gcc --version gcc (GCC) 9.2.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. sf@toro:/tmp$ esql -V IBM Informix CSDK Version 4.50, IBM Informix-ESQL Version 4.50.FC1 sf@toro:/tmp$ dbaccess -V DB-Access Version 14.10.FC1DE BTW I had to unset GL_USEGLU to use the gcc address sanitizer... Seb ------------------------------ SEBASTIEN SF FLAESCH ------------------------------

I tried in my below environment and I correctly get -951 error (User is not known on remote host.) since user/password doesn't exist. Note : I am trying in my development environment of CSDK 4.50.xC4 [which yet to release]. I will try to find 4.50.xC1 environment. At this moment, I am discounting any possible gcc compiler issue!. I am compiling esql program as "esql May15-2020.ec". In my environment GL_USEGLU is not set. shesh@ubuntu:/shesh/esql$ uname -a Linux ubuntu 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux shesh@ubuntu:/shesh/esql$ gcc --version gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. shesh@ubuntu:/shesh/esql$ esql -V IBM Informix CSDK Version 4.50, IBM Informix-ESQL Version 4.50.FC4 $ dbaccess -V DB-Access Version 14.10.FC1DE ------------------------------Sheshnarayan Agrawal ------------------------------

Thanks for you quick reaction, Shesh. In fact I get the error with the GCC ADDRESS SANITIZER. Sorry I should have specified this in the first post. Please try again with: export INFORMIXC="gcc -g -fsanitize=address"As shown in is in the repro.txt file. Seb ------------------------------ SEBASTIEN SF FLAESCH ------------------------------

Hi Sebastein, I tried export INFORMIXC="gcc -g -fsanitize=address", removed the previously compiled binary and intermediate files. Freshly compiled and run the program, I correctly get -951 error code. Will also try 4.50.FC1 which you are using. shesh@ubuntu:/shesh/esql$ echo $INFORMIXC gcc -g -fsanitize=address ------------------------------ Sheshnarayan Agrawal ------------------------------

Sebastian: I tested this with ESQL/C v 14.10.FC3 using gcc with the -f sanitize=address flag using versions 4.8, 5.5, 6.5, 7.5, & 8.4 I don't have gcc v9 or v10 right now. For me this only reports a problem with the v4.8 compiler and there it doesn't matter how long the user id is I get the same report for 15, 16, 17, or 18 characters. Using the other compiler versions there is no problem. Regardless of the length of the ID it either connects or gets a -951 error depending on whether the user id is valid or not. I am testing using the next release of my dbping.ec utility source. Art ------------------------------ Art Kagel ------------------------------

Thanks a lot Art for your testings! Just re-tested with a different gcc version on my Debian 10: I get the same sanitizer error in _iqset2err() with gcc 9.2.0 and with gcc 8.3.0 (the version that comes with system packages) At least if ESQL/C dev team can double check the source code starting from sqli_connect_open() etc... Maybe there is some cleanup code that is not executed when the user/pswd is invalid and CONNECT TO returns error -951 ... Probably less testes as with a valid user/pswd that can connect... Seb ------------------------------ SEBASTIEN SF FLAESCH ------------------------------

Just tested with a valid DB user name with 16 chars that can connect, I get the same sanitizer error. Seb ------------------------------ SEBASTIEN SF FLAESCH ------------------------------

Hello! Just tested with following ESQL/C and GCC versions, I get the same sanitizer issue: sf@toro:~/dbvendors/informix/problems$ esql -V IBM Informix CSDK Version 4.10, IBM Informix-ESQL Version 4.10.FC9 Software Serial Number AAA#B000000 sf@toro:~/dbvendors/informix/problems$ gcc --version gcc (Debian 8.3.0-6) 8.3.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. sf@toro:~/dbvendors/informix/problems$ gcc --version gcc (GCC) 9.2.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I will compile gcc 10.1.0 and test with that version. Seb ------------------------------ SEBASTIEN SF FLAESCH ------------------------------

Hi Sebastein, I tried on CSDK 4.50.FC1 (earlier I tried was CSDK 4.50.FC4 yet to release version) and I can see the program returns proper error code -951. To me this appears to be related to compiler/OS version! Following is the environment (posting again) where I tried. I will explore compiler option of "sanitize" to understand why presence of this option causes issue, basically how this option impacts the layout of binary! shesh@ubuntu:/shesh/esql$ uname -a Linux ubuntu 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux shesh@ubuntu:/shesh/esql$ esql -V IBM Informix CSDK Version 4.50, IBM Informix-ESQL Version 4.50.FC1 shesh@ubuntu:/shesh/esql$ echo $INFORMIXC gcc -g -fsanitize=address shesh@ubuntu:/shesh/esql$ gcc --version gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. shesh@ubuntu:/shesh/esql$ cat May15-2020.ec #include <stdio.h> int main() { EXEC SQL BEGIN DECLARE SECTION; const char * un16 = "abcdefghijklmnop"; // 16 bytes => error const char * up = "password"; EXEC SQL END DECLARE SECTION; printf("User length 16 bytes/chars connection test \\n"); EXEC SQL CONNECT TO "sheshdb" USER :un16 USING :up; printf("Connect returned %d\\n", SQLCODE); return(0); } shesh@ubuntu:/shesh/esql$ shesh@ubuntu:/shesh/esql$ esql May15-2020.ec shesh@ubuntu:/shesh/esql$ ls a.out May15-2020.c May15-2020.ec shesh@ubuntu:/shesh/esql$ ./a.out User length 16 bytes/chars connection test Connect returned -951 shesh@ubuntu:/shesh/esql$ ------------------------------ Sheshnarayan Agrawal ------------------------------

Thank you Shesh for your tests... Guess what? The issue is gone after restarting my Informix IDS 14 (ESQL/C 4.50) (I stopped that one to make tests with IDS 12 + ESQL/C 4.10 which also reported the problem)... Very strange. Anyway if someone reading these lines has access to the code, you should have a look to the functions reported by the address sanitizer. Maybe some specific conditions make this happen. Other colleagues here has tested and could not repro. Can also be a gcc / address sanitizer bug, but I prefer to report, instead of being silent. Cheers! Seb ------------------------------ SEBASTIEN SF FLAESCH ------------------------------

Hi Sebastein, Good to know its working, while root cause yet to be found out. As you already indicated, kindly do open case with gcc compiler. I will investigate the ESQL/C side and if any issue found will open case as well. Thanks & Regards -Shesh ------------------------------ Sheshnarayan Agrawal ------------------------------

Any news on this????? ------------------------------ Sebastien FLAESCH ------------------------------

Hello, Just installed IDS 14.10.FC10 and CSDK 4.50.FC10 on my Linux Debian 11. Again I have got an address sanitizer error and after restarting the server, it is gone. $ uname -a Linux toro 5.16.0-0.bpo.4-amd64 #1 SMP PREEMPT Debian 5.16.12-1~bpo11+1 (2022-03-08) x86_64 GNU/Linux $ gcc --version gcc (Debian 10.2.1-6) 10.2.1 20210110Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ esql -VIBM Informix CSDK Version 4.50, IBM Informix-ESQL Version 4.50.FC10 I don't know if I can reproduce with a simple ESQL/C program, so the address sanitizer output I provide here is when using our fglrun DVM. Still, you can spot the Informix client APIs that are involved: ================================================================= ==1053101==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000026d00 at pc 0x7f74ec774541 bp 0x7ffdac31d2b0 sp 0x7ffdac31ca60 READ of size 33 at 0x603000026d00 thread T0 #0 0x7f74ec774540 in __interceptor_memmove ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:789 #1 0x7f74e80df0f0 in _iqset2err (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/esql/libifsql.so+0x330f0) #2 0x7f74e80be749 in proc_srvrresp (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/esql/libifsql.so+0x12749) #3 0x7f74e80bf725 in asf_connect (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/esql/libifsql.so+0x13725) #4 0x7f74e80bfd06 in sqli_connect_open (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/esql/libifsql.so+0x13d06) #5 0x7f74e8d7a158 in ODI_connect /home/sf/genero/devel/fgl/fgl/src/sqldriver/informix/ifx91.ec:597 #6 0x7f74ec227cdf in fglsql_connect ../base/fglsql.c:1562 #7 0x7f74ec21675b in rts_sql_connect ../base/Sql.c:498 #8 0x7f74ec1d716b in callFu0 /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:320 #9 0x7f74ec1d7311 in invoke /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:345 #10 0x7f74ec1de035 in vm_interprete_impl /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:1050 #11 0x7f74ec1ae5f3 in fdb_debug /home/sf/genero/devel/fgl/fgl/src/vm/fdb.c:3545 #12 0x7f74ec1d2f45 in vm_main /home/sf/genero/devel/fgl/fgl/src/vm/vm.c:929 #13 0x563eeb9d81bb in main /home/sf/genero/devel/fgl/fgl/src/vm/fglrun.c:5 #14 0x7f74ebf2ed09 in __libc_start_main ../csu/libc-start.c:308 #15 0x563eeb9d80c9 in _start (/home/sf/genero/devel/fgl/fgl/opt/fgl/bin/fglrun+0x10c9) 0x603000026d00 is located 0 bytes to the right of 32- byte region [0x603000026ce0,0x603000026d00) allocated by thread T0 here: #0 0x7f74ec7e5037 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x7f74e79dd9c9 in meAlloc (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/esql/libifos.so+0x139c9) #2 0x7f74e7e76021 in ascOptBin (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/libifasf.so+0x28021) #3 0x7f74e7e7025a in ascBinary (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/libifasf.so+0x2225a) #4 0x7f74e7e71bd5 in pfConReq (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/libifasf.so+0x23bd5) #5 0x7f74e7e6b517 in cmReqSync (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/libifasf.so+0x1d517) #6 0x7f74e7e6bfb8 in cmConReq (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/libifasf.so+0x1dfb8) #7 0x7f74e7e610d7 in ascRequest (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/libifasf.so+0x130d7) #8 0x7f74e7e63675 in ASF_Call (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/libifasf.so+0x15675) #9 0x7f74e80bf707 in asf_connect (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/esql/libifsql.so+0x13707) #10 0x7f74e80bfd06 in sqli_connect_open (/opt3/dbs/ifx/CSDK-4.50.FC10/lib/esql/libifsql.so+0x13d06) #11 0x7f74e8d7a158 in ODI_connect /home/sf/genero/devel/fgl/fgl/src/sqldriver/informix/ifx91.ec:597 #12 0x7f74ec227cdf in fglsql_connect ../base/fglsql.c:1562 #13 0x7f74ec21675b in rts_sql_connect ../base/Sql.c:498 #14 0x7f74ec1d716b in callFu0 /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:320 #15 0x7f74ec1d7311 in invoke /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:345 #16 0x7f74ec1de035 in vm_interprete_impl /home/sf/genero/devel/fgl/fgl/src/vm/vm_interp.c:1050 #17 0x7f74ec1ae5f3 in fdb_debug /home/sf/genero/devel/fgl/fgl/src/vm/fdb.c:3545 #18 0x7f74ec1d2f45 in vm_main /home/sf/genero/devel/fgl/fgl/src/vm/vm.c:929 #19 0x563eeb9d81bb in main /home/sf/genero/devel/fgl/fgl/src/vm/fglrun.c:5 #20 0x7f74ebf2ed09 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:789 in __interceptor_memmove Shadow bytes around the buggy address: 0x0c067fffcd50: 01 fa fa fa fd fd fd fd fa fa 00 00 02 fa fa fa 0x0c067fffcd60: 00 00 02 fa fa fa fd fd fd fd fa fa fd fd fd fa 0x0c067fffcd70: fa fa 00 00 00 04 fa fa 00 00 00 fa fa fa 00 00 0x0c067fffcd80: 00 fa fa fa 00 00 00 fa fa fa 00 00 00 00 fa fa 0x0c067fffcd90: 00 00 00 fa fa fa fd fd fd fd fa fa 00 00 00 00 =>0x0c067fffcda0:[fa]fa 00 00 00 05 fa fa fa fa fa fa fa fa fa fa 0x0c067fffcdb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffcdc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffcdd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffcde0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fffcdf0: 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 ==1053101==ABORTING BR ------------------------------ Sebastien FLAESCH ------------------------------