FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

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

Mike you provided a very useful information !!!
This was one of the (few) hole in our reverse.

> *** 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                                                   |.
> |
> 

If I understood this 0x12 is build with some structures like

struct data {
 byte type;
 word offset;
 word length
};

where
type = 0 netlib version (6 bytes)
       1 encryption flag (1 boolean byte)
       2 instance (always null terminated, usually MSSQLServer)
       3 threadid (DWORD in machine order... I don't understand the
reason to send this information)
       0xff end (no more data, no offset/length given)

followed by data (pointed by structures)

> 
> *** 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....
> |
> 

This has the same format!

> 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)
> 

I still don't understand where this version came...

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

This cause mssql 6.5 do not support this type of packet and close
connection. Even 7.0 give error and close, only mssql2k support this
packet.

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

No, they don't talk to Sybase.

> Mike

bye
  freddy77