[openssl-users] In ssl3_write_bytes, some checks related to hanlding write failure are missing

[Raja ashok]

Hi All,

In ssl3_write_bytes, if (len < tot) we are returning failure with SSL_R_BAD_LENGTH error. In this place I hope we should set “tot” back to “s->s3->wnum”. Otherwise when application calls back SSL_write with correct buffer, it causes serious problem (“tot” is 0 and iLeft is not NULL). I hope we should do like below.

    if (len < tot) {
        s->s3->wnum = tot;
        SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
       return (-1);
    }

And also we should do one additional check for “len” as mentioned in my previous mail.

    if ((len < tot) || ((tot != 0) && (len < (tot + s->s3->wpend_tot)))){
        s->s3->wnum = tot;
        SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
       return (-1);
    }

Regards,
Ashok

________________________________
[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: Raja ashok
Sent: 27 March 2017 13:55
To: 'openssl-users at openssl.org'; 'openssl-dev at openssl.org'
Subject: In ssl3_write_bytes, some checks related to hanlding write failure are missing

Hi,

I feel there is a check missing in ssl3_write_bytes, in case of handling write failure.

Consider SSL_write is called with 20000 bytes buffer, then internally in ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send failed for the second record then we store the states internally (wnum, wpend_tot and wpend_buf) and return back the result.

Later application has to call SSL_write with same buffer, if it calls with different buffer of length 100 byte then we fail that in ssl3_write_bytes using the check (len < tot).

But consider application calls with buffer of size 18000 bytes and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not succeed as tot is 16384. Then it will call ssl3_write_pending to send the remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now tot will have 20000.

Later there is a check (tot == len), this will not succeed. Then directly we are doing n = (len - tot), this will overflow and store a value close to 2^32 in n. Then it will cause out of bound access to the application buffer "buf".

I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before calling ssl3_write_pending.

    if ((len < tot) || (len < (tot + s->s3->wpend_tot))){
        SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
        return (-1);
}

Note : I am referring 1.0.2k version of OpenSSL.

Regards,
Ashok

________________________________
[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170331/689b72fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 6737 bytes
Desc: image002.jpg
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170331/689b72fa/attachment-0001.jpg>