Informix

 View Only
Expand all | Collapse all

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

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

    Posted Fri May 15, 2020 06:24 AM
      |   view attached
    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

    Attachment(s)

    7z
    test004.7z   1 KB 1 version


  • 2.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 06:30 AM
    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
    ------------------------------



  • 3.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 06:34 AM
    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
    ------------------------------



  • 4.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 06:49 AM
    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
    ------------------------------



  • 5.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 07:23 AM
    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
    ------------------------------



  • 6.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 07:45 AM
    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
    ------------------------------



  • 7.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 08:08 AM
    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
    ------------------------------



  • 8.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    IBM Champion
    Posted Fri May 15, 2020 11:26 AM

    Sebastian:

    I tested this with ESQL/C v 14.10.FC3 using gcc with the -fsanitize=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
    ------------------------------



  • 9.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 12:03 PM
    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
    ------------------------------



  • 10.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Fri May 15, 2020 12:12 PM
    Just tested with a valid DB user name with 16 chars that can connect, I get the same sanitizer error.
    Seb

    ------------------------------
    SEBASTIEN SF FLAESCH
    ------------------------------



  • 11.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Mon May 18, 2020 06:58 AM
    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
    ------------------------------



  • 12.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Mon May 18, 2020 09:44 AM
    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
    ------------------------------



  • 13.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Mon May 18, 2020 12:07 PM
    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
    ------------------------------



  • 14.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Tue February 21, 2023 11:13 AM

    Any news on this?????



    ------------------------------
    Sebastien FLAESCH
    ------------------------------



  • 15.  RE: Informix client address sanitizer heap-buffer-overflow with 16 bytes in user name of CONNECT TO

    Posted Mon May 18, 2020 04:13 AM
    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
    ------------------------------



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

    Posted Mon August 07, 2023 10:51 AM

    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 20210110
    Copyright (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 -V
    IBM 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
    ------------------------------