- 本文是针对MySQL 5.5.9写的。MySQL协议是向老版本兼容的。老版本的MySQL Client可能不理解下面的某些字段而忽略掉。
- 实际使用的时候，服务器的协议版本应当大于等于客户端。遗憾的是，MySQL并没有对每一次协议变动标一个数字。
- 本文中所说的”字节”一词，英文是Byte。遵循C语言中定义，即char的大小。注意：没有规定1字节一定等于8位。所以如果你准备在1字节不等于8位的环境中使用mysql，那是给自己找事。
- 我祈祷你的char是有符号的。
参考http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol（我也参与这个页面的编辑）
一、客户端连接服务器的流程
请参见sql-commonclient.c的CLI_MYSQL_REAL_CONNECT函数。
- 使用系统的socket函数建立一个socket，然后连接服务器。
- 使用这个socket初始化一个vio对象
net-vio= vio_new(sock, VIO_TYPE_TCPIP, VIO_BUFFERED_READ); - 使用vio初始化net对象
my_net_init(net, net-vio) - 并对vio设置为keep alive
vio_keepalive(net-vio,TRUE); - 然后设置各种参数
客户端接下来的流程可分为三个阶段：
- Connection established, read and parse first packet
- invoke the plugin to send the authentication data to the server
- authenticated, finish the initialization of the connection
二、服务器处理连接
服务器启动的时候是在sql/mysqld.cc的network_init函数建立socket，然后bind。
服务器专门有一个线程（可称为Connection Manager）处理新来的网络连接。这个线程的主函数是sql/mysqld.cc的handle_connections_sockets_thread，主要的逻辑在sql/mysqld.cc的handle_connections_sockets。handle_connections_sockets的逻辑就是典型的select()/accept()/dispatch。每个客户端连接最终会对应着一个线程以及一个THD对象。THD类不是一个通用的描述任意线程的类，它就是专门为处理客户端的的TCP连接而设计的。这个类非常大，在sql/sql_class.h中定义。
每个worker线程的入口函数是在sql/sql_connect.cc中的handle_one_connection。sql/sql_parse.cc的do_command从网络连接上读一个command，并执行。handle_one_connection函数是以while循环的方式执行do_command。
三、协议
客户端发给服务器的包可分为两种：登录时的一个auth包，以及身份验证结束后的command包。
服务器发给客户端的包可分为四种：登录时的握手包、数据包、数据流结束包、成功包(OK Packet)、错误信息包。
所有的包都具有统一的格式，由统一的函数(sql/net_serv.cc:my_net_write(…))写入buffer等待发送。
| 长度 | 描述 |
| 3 | 包长度（单位：字节）。按低字节低址的规则存放。因为一共就3个字节，所以单个包的最大长度是(2的16次方-1)字节，约等于16MB。最小长度是0。 |
| 1 | 序号。第一个是0。 |
| n | data。 |
实际上，包长等于 2的16次方-1的包也会被拆成2个包发送。因为Mysql最初没有考虑突破16M，也没有预留任何字段做标志这个包的数据不完整。所以只好把长度为2的16次方-1的包视做不完整的包，直到后面收到一个长度小于2的16次方-1的包，然后拼起来。所以最后一个包的长度有可能是0。
登录
服务器在每收到一个新的连接的时候，会使用sql/sql_connect.cc的login_connection函数作身份验证。先根据IP做acl，然后才进入用户名密码验证阶段。
mysql的登录协议是经典的CHAP协议，sql/sql_acl.cc的native_password_authenticate函数的注释简单了解释了这个协议：
- the server sends the random scramble to the client.
- client sends the encrypted password back to the server.
- the server checks the password.
random scramble在4.1之前的版本中是8字节整数，在4.1以及后续版本是20字节整数。它是由password.c的create_random_string函数生的，因为它采用的是rand()%94+33这样的方式生的，所以scramble的每个字节一定是[33,127)之间的ASCII字符，在协议中发送时，是加上’ ’之后发的(这个后面会详细解释）。
命令—答复
在身份验证之后，服务器和客户端之间处于一问一答的模式。 截至到Mysql 5.5.9，mysql server一共支持30种command，sql/sql_parse.cc的 dispatch_command函数写了一个大大的switch…case来处理它们。
- COM_SLEEP
- COM_QUIT
- COM_INIT_DB
- COM_QUERY
- COM_FIELD_LIST
- COM_CREATE_DB
- COM_DROP_DB
- COM_REFRESH
- COM_SHUTDOWN
- COM_STATISTICS
- COM_PROCESS_INFO
- COM_CONNECT
- COM_PROCESS_KILL
- COM_DEBUG
- COM_PING
- COM_TIME
- COM_DELAYED_INSERT
- COM_CHANGE_USER
- COM_BINLOG_DUMP
- COM_TABLE_DUMP
- COM_CONNECT_OUT
- COM_REGISTER_SLAVE
- COM_STMT_PREPARE
- COM_STMT_EXECUTE
- COM_STMT_SEND_LONG_DATA
- COM_STMT_CLOSE
- COM_STMT_RESET
- COM_SET_OPTION
- COM_STMT_FETCH
- COM_DAEMON
四、服务器的握手包
客户端执行recv，会收到一个来自server的包，其中第一个字节是协议的版本号。
其它的重要信息还有connection id、scramble
41 00 00 00
0A 35 2E 30 2E 32 30 2D 73 74 61 6E 64 61 72 64 2D 6C 6F 67 00 44 8E 4E 00 5A 66 72 2A 79 43 24 27 00 2C A2 08 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 36 7B 29 58 5E 50 56 41 21 7C 73 4C 00
其格式如下：（来自sql_acl.cc的send_server_handshake_packet函数的注释）
| 长度 | 说明 |
| 1 | 协议的版本号 (0x0A) |
| n | 以0结尾的字符串。描述服务器版本 |
| 4 | thread id |
| 8 | scramble的前8个字节 |
| 1 | 0x00。也就是说让scramble看起来是一个以0结尾的字符串 |
| 2 | server capabilities的低两个字节。 |
| 1 | server character set |
| 2 | server status |
| 2 | server capabilities的高两个字节。 |
| 1 | scramble的总长度 |
| 10 | 保留。必须以0填充。 |
| n(至少12） | scramble的剩余部分。（不包含’ ’） |
| 1 | 0x00。也就是说让scramble看起来是一个以0结尾的字符串 |
server capabilities表：
| 名字 | 从右往左数第几位 | 说明 |
| CLIENT_LONG_PASSWORD | 1 | new more secure passwords |
| CLIENT_FOUND_ROWS | 2 | Found instead of affected rows |
| CLIENT_LONG_FLAG | 3 | Get all column flags |
| CLIENT_CONNECT_WITH_DB | 4 | One can specify db on connect |
| CLIENT_NO_SCHEMA | 5 | Don’t allow database.table.column |
| CLIENT_COMPRESS | 6 | Can use compression protocol |
| CLIENT_ODBC | 7 | Odbc client |
| CLIENT_LOCAL_FILES | 8 | Can use LOAD DATA LOCAL |
| CLIENT_IGNORE_SPACE | 9 | Ignore spaces before ‘(‘ |
| CLIENT_PROTOCOL_41 | 10 | New 4.1 protocol |
| CLIENT_INTERACTIVE | 11 | This is an interactive client |
| CLIENT_SSL | 12 | Switch to SSL after handshake |
| CLIENT_IGNORE_SIGPIPE | 13 | IGNORE sigpipes |
| CLIENT_TRANSACTIONS | 14 | Client knows about transactions |
| CLIENT_RESERVED | 15 | Old flag for 4.1 protocol |
| CLIENT_SECURE_CONNECTION | 16 | New 4.1 authentication |
| CLIENT_MULTI_STATEMENTS | 17 | Enable/disable multi-stmt support |
| CLIENT_MULTI_RESULTS | 18 | Enable/disable multi-results |
| CLIENT_PS_MULTI_RESULTS | 19 | Multi-results in PS-protocol |
| CLIENT_PLUGIN_AUTH | 20 | Client supports plugin authentication |
| CLIENT_SSL_VERIFY_SERVER_CERT | 31 | |
| CLIENT_REMEMBER_OPTIONS | 32 |
五、然后客户端将密码等发送过去
客户端根据服务器发给的scramble对原始密码进行散列，然后和其它参数一起发给服务器
发送登录数据:
00000000 3A 00 00 01 85 A6 03 00 00 00 00 01 08 00 00 00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020 00 00 00 00 72 6F 6F 74 00 14 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| 长度 | 说明 |
| 4 | client capabilities |
| 4 | max packet size |
| 1 | charset number |
| 23 | 保留。必须以0填充。 |
| n | user name。以0结尾的字符串 |
| n | hash过的密码。length (1 byte) coded |
| n | database name,以0结尾的字符串。只有client capabilities中有CLIENT_CONNECT_WITH_DB时，此字段才有效。 |
| n | client auth plugin name。以0结尾的字符串。只有client capabilities中有CLIENT_PLUGIN_AUTH时，此字段才有效。如果使用mysql默认的auth机制，此处应该为mysql_native_password |
sql-common/client.c的send_client_reply_packet函数构造这个答复包然后发送。散列算法的实现在password.c的scramble(char *to, const char *message, const char *password)函数。
四、再度发送scrambled password （可选）
授权信息已经发送过去了，服务器可以会回答说OK（发回一个OK_PACKET)，也有可能会要求再度发送scrambled password。
如果要再度发送，服务器会返回一个1字节的包，如果第一个字节是0xFE且mysql.server_capabilities设置了CLIENT_SECURE_CONNECTION，那么
就需要再度发送scrambled password
这个似乎是为了和以前老版本兼容，这次需要使用3.23版的scramble对password进行加密然后发送。
scramble_323(buff, mysql->scramble, passwd);
如：
0x8059000: 0x09 0x00 0x00 0x03 0x4d 0x45 0x46 0x4c
0x8059008: 0x4f 0x44 0x4b 0x4b 0x00
这个包的格式很简单，包头，然后是9个字节的scramble(其中最后一个字节必须是0x00)
不过要注意，此处包头的第4个字节是0x03,因为这是认证过程是双方来回发送的第三个包了。
五、命令
0x20,0x00,0x00,0x00, 包头
0x03 //命令的类型，COM_QUERY
select * from xxx where xxx //arg
========================================================
MYSQL认证漏洞：
1、构造0长度的scramble绕过密码校验
这几乎可以算是mysql目前发现的危害性最严重的安全漏洞了。
出问题的代码：
改正后的 （多加了一句 if (pos-scrambled != SCRAMBLE_LENGTH_323) return 1）
2、构造一个足够长的passwd让strlen溢出。
出问题的代码：
uint passwd_len= thd->client_capabilities & CLIENT_SECURE_CONNECTION ?
*passwd++ : strlen(passwd);
db= thd->client_capabilities & CLIENT_CONNECT_WITH_DB ?
db + passwd_len + 1 : 0;
uint db_len= db ? strlen(db) : 0;
修正后：
char *passwd= strend(user)+1;
。。。。
uint passwd_len= thd->client_capabilities & CLIENT_SECURE_CONNECTION ?
(uchar)(*passwd++) : strlen(passwd);
db= thd->client_capabilities & CLIENT_CONNECT_WITH_DB ?
db + passwd_len + 1 : 0;
/* strlen() can’t be easily deleted without changing protocol */
uint db_len= db ? strlen(db) : 0;
设想，客户端发来的包中，如果client_capabilities 指定 CLIENT_SECURE_CONNECTION和 CLIENT_CONNECT_WITH_DB 两个位的值
且passwd的第一个字节大于0x80，那么*passwd作为一个char值将是负的，在其再被转为uint的时候，将会是一个很大的uint。然后db这个指针就会被指向别处，从而对一段意外的内存进行strlen。这时可能会引发内存的读错误。从而造成拒绝服务攻击。但是这个不太容易，因为passwd_len的有效范围在[-128,127]之间，所以所能造成的危害很小。
如果passwd_len不等于-1,而是一个更大的负数，那么strlen函数至多会读到username后的那么’ ’就会终止。这样做的好处是可以借助前面那段填充区来设置db name以供后面用，缺点是此处无法引发内存错误。
如果passwd_len恰好设置为-1,且passwd_len后面的那些字节（SCRAMBLE）全部用非0值填充，那么strlen就会一直朝后面读下去直到找到0。但是由于db指针指向的是堆上，而且在很多操作系统下，如Freebsd，都会把在堆上分配的内存在交给用户使用前都初始化成0，所以……想让strlen读越界也很难。
而接下来的一个关于边界的检查
if (passwd + passwd_len + db_len > (char *)net->read_pos + pkt_len) …
也因为整数溢出而导致失效。
然后程序会一直向下执行到check_user,如果编译的时候定义了NO_EMBEDDED_ACCESS_CHECKS，那么万事大吉，此时的db指针会被立即传递给mysql_change_db函数，哦……………………否则的话，将会有一处关于password_len的检查
if (passwd_len != 0 &&
passwd_len != SCRAMBLE_LENGTH &&
passwd_len != SCRAMBLE_LENGTH_323)
DBUG_RETURN(ER_HANDSHAKE_ERROR);
server会立刻给客户端报告一个handshare error而终止连接。
（完）
This article is from:https://www.sunchangming.com/blog/post/4631.html