bugtraq - Off-by-one in Sybase Advantage Server 10.0.0.3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20110627124437.a47b2bbc.aluigi@autistici.org>
Date: Mon, 27 Jun 2011 12:44:37 +0100
From: Luigi Auriemma <aluigi@...istici.org>
To: bugtraq@...urityfocus.com
Subject: Off-by-one in Sybase Advantage Server 10.0.0.3


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

                             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@...istici.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.


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


--- 
Luigi Auriemma
http://aluigi.org