More on using FreeTDS on a server (was Re: [freetds] Serverdumpscore...)

Mike C. mcbp223 at yahoo.com
Fri Apr 23 03:01:43 EDT 2004


> -----Original Message-----
> From: freetds-bounces at lists.ibiblio.org
> [mailto:freetds-bounces at lists.ibiblio.org]On Behalf Of James K. Lowden
> Sent: Thursday, April 22, 2004 7:22 PM
> To: TDS Development Group
> Subject: Re: More on using FreeTDS on a server (was Re: [freetds]
> Serverdumpscore...)


> OK, thanks. If you happen to have a trace handy sometime, I'd like to have
> a look.

I lost the trace of the header, but default values for channel/window/packet
should work.
Here is a prelogin between ODBC driver for 2k and SQL Server 2k. In here the
server accepts the dialog.

*** from client
TDS::0x12, length = 8 + 33
 |0000| 00 00 15 00  06 01 00 1b  00 01 02 00  1c 00 01 03
|................|
 |0010| 00 1d 00 04  ff 08 00 01  55 00 00 00  00 ac 0d 00
|........U.......|
 |0020| 00                                                   |.
|


*** from server
TDS::0x04, length = 8 + 29
 |0000| 00 00 15 00  06 01 00 1b  00 01 02 00  1c 00 01 03
|................|
 |0010| 00 1d 00 00  ff 08 00 03  32 00 00 02  00            |........2....
|

Forget what I said earlier about the done token that ends the response, I
was thinking about the SQL Server 6.5 nack response.
Note that the query and the response seem to be identical until offset 0017.

Please refer to the exploit analysis published by xfocus.org (copyright by
benjurry), there are 5 pages of structures that won't fit in this posting. I
try to summarize below:

0000: 00         - CNETLIBVERNO,     always zero
0001: 00 15      - CNETLIBVEROFFSET, offset to CNETLIBVER
0003: 00 06      - CNETLIBVERLEN,    length of CNETLIBVER

0005: 01         - CENYFLAGNO,       always 1, flag of client encryption
0006: 00 1B      - CENYFLAGOFFSET,   offset to CENYFLAG
0008: 00 01      - CENYFLAGLEN,      length of CENYFLAG

000A: 02         - SINSTNAMENO,      number of server instance name
000B: 00 1C      - SINSTNAMEOFFSET,  offset of SINSTNAME
000D: 00 01      - SINSTNAMELEN,     length of SINSTNAME

000F: 03         - CTHREADIDNO,      always 3, number of the client process
0010: 00 1D      - CTHREADIDOFFSET,  offset of CTHREADID
0012: 00 04      - CTHREADIDLEN,     length of CTHREADID

0014: FF         - FILEDEND,         end of header, information follows

CNETLIBVEROFFSET
    : 08 00 01 55 00 00               (if its 08 00 02 10 00 00
                 - CNETLIBVER,         means version 80.528.00)


CENYFLAGOFFSET
    : 00         - CENYFLAG,         0 = encrypt, 1 = don't encrypt

SINSTNAMEOFFSET                      (in my test there was
    : 00         - SINSTNAME          the default instance)


CTHREADIDOFFSET
    : AC 0D 00 00
                 - CTHREADID         id of client process, host byte order


I guess the response follows the same rules, the difference is in
CNETLIBVER, and CTHEREADIDLEN is zero.

The nack response to an 0x12 from a 6.5 server looks like this:

TDS::0x04, length(8 + 59), packet(1), last
 |0000| aa 00 00 00  2f 0f a2 01  0e 0a 03 20  4c 6f 67 69   |..../......
Logi|
 |0010| 6e 20 66 61  69 6c 65 64  0d 0a 14 4d  69 63 72 6f   |n
failed...Micro|
 |0020| 73 6f 66 74  20 53 51 4c  20 53 65 72  76 65 72 00   |soft SQL
Server.|
 |0030| 00 00 fd 00  fd 00 00 00  00 00 02                   |...........
|

it starts with an error token.

> If you need access to a Sybase server, I can arrange it.
I would be curious if the MS client talks to the Sybase server, and what
they say.

Mike




More information about the FreeTDS mailing list