> -----Original Message-----
> From: Rafal Somla [mailto:rafal.somla@stripped]
> Sent: Dienstag, 10. Mai 2011 12:02
> To: Vladislav Vaintroub
> Cc: commits@stripped; Georgi Kodinov
> Subject: Re: bzr commit into mysql-5.5 branch (rafal.somla:3477)
> Bug#11879051
>
> Hi Wlad,
>
> On 09/05/2011 21:37, Vladislav Vaintroub wrote:
>
> > I think the analysis is not completely correct here.
> >
> > The way Windows authentication works is such that0) Server sends
> > welcome packet. 1) client sends client authentication packet that
> > contains authentication method but without payload. 2) then server
> > sends UPN to client 3) then client puts UPN into
> > InitializeSecurityContext() and sends the resulting blob to server.
> > (following steps omitted)
> >
> > The 255 limit is would be a limit in step 1). But since payload is
> > not used in this step , there is also no limit.
> My understanding is different. Basically, the UPN sent first by server
> is wrapped in the welcome packet already and then the first
> authentication payload from client is wrapped inside the normal client
> authentication packet (in hope that all will be settled during this
> standard, 2 packet sequence).
When server sends welcome packet (and this is the first packet ever sent in
client-server communication), it does not send UPN, because it does not yet
know that client wants Windows authentication.
UPN comes attached to change_plugin "packet", as described in
http://bugs.mysql.com/bug.php?id=57442
Client, in theory, can send some plugin specific payload in scramble_buff in
client authentication packet. In this case 255 limit would apply .
But in Windows authentication case, client does not do send anything in
scramble_buff. To create the plugin specific payload
(InitializeSecurityContext blobs), it needs to know the UPN, which server
has not yet sent.
> I included my analysis in bug#11878962 -
> please review it to see if I made some mistakes. So far Joro, who wrote
> the code, has confirmed that it is a problem so I assumed my analysis is
> correct.
> Rafal
>
>
> ---- analysis from bug#11878962 ----------
>
> A client which uses authentication plugin can send arbitrary data to the
> server-side plugin using
>
> MYSQL_PLUGIN_VIO::write_packet(vio, ucchar *buf, int buf_len).
>
> When this method is called first time (see client_mpvio_write_packet()
> in client.c:2680), the data is wrapped into a client authentication
> packet (send_client_reply_packet() in client.c:2450).
>
> In the client authentication packet, the data payload is represented as
> a length coded string of bytes with the first byte containing length.
> Thus length of the payload is limited to 255 bytes. However, there are
> no checks in the code which would prevent client from trying to send
> more than 255 bytes using MYSQL_PLUGIN_VIO::write_packet().
>
> If client tries to do so, then send_client_reply_packet() will execute
> the following code (where end points at the end of the constructed
packet):
>
> if (data_len)
> {
> if (mysql->server_capabilities & CLIENT_SECURE_CONNECTION)
> {
> *end++= data_len;
> memcpy(end, data, data_len);
> end+= data_len;
> }
> ...
>
> Since the size field is 1 byte, the length stored in the packet will be
> different from data_len, if data_len > 256. Nevertheless, all the data
> will be appended to the packet without noticing this. A receiver of such
> a packet will interpret it wrongly which can lead to unpredictable
> behavior (probably crash).
>
> --
> MySQL Code Commits Mailing List
> For list archives: http://lists.mysql.com/commits
> To unsubscribe:
> http://lists.mysql.com/commits?unsub=1
