Re: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow
Hi Salz, I raised a PR for this change. Already got some comments from Kurt. Requesting you also to check and provide your suggestions on it. https://github.com/openssl/openssl/pull/3255 Currently raised PR on only 1.0.2. Once its reviewed, I can raise on other branches (1.1.0 and Master). 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! -Original Message- From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, Rich via openssl-dev Sent: 17 April 2017 22:02 To: openssl-dev@openssl.org Subject: Re: [openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow >??? memset(&str->data[str->length], 0, len - str->length); The intent is to blank out everything from what was currently written. This "covers up" possible pointer over-runs. We could do just from the old max. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Doubt about memory realloc logic in BUF_MEM_grow_clean and BUF_MEM_grow
Hi All,
I am having a doubt BUF_MEM_grow and BUF_MEM_grow_clean. After reallocation of
buffer we are memsetting the buffer from “str->length” index.
} else {
str->data = ret;
str->max = n;
memset(&str->data[str->length], 0, len - str->length);
str->length = len;
}
I feel we should memset from “str->max”.
1) One usage of this BUF_MEM is init buffer (s->init_buf) in SSL handshake
for storing peer’s message and framing response message.
2) Initially in ssl3_connect and ssl3_accept we are creating this
s->init_buf of size 16348 bytes.
3) Later in ssl3_get_message we are using this buffer for receiving peer’s
handshake message of length “l”. Here we are calling BUF_MEM_grow_clean with
“(l + 4 + 16)” as length. If (l + 4 +16) is lesser than 16348, then
“init_buf->length” is set to that.
4) After parsing the received msg and we are framing the response message
on the same s->init_buf. For example consider ssl3_send_certificate_request,
here we are copying Cert types and sign hash algorithm, after that we are
calling mem grow before copying X509 name of CA cert.
5) Here, if the data (cert types and sign hash alg) copied before calling
mem grow is more than (l + 4 + 16) of previously received msg, then it will
leads to some data loss inside BUF_MEM_grow_clean we are memsetting from
“data[str->length]”.
In OpenSSL, BUF_MEM is used in many modules like ASN, PEM and SSL. So as per my
understanding better we should memset from “max” index in case of realloc, like
below pseudocode.
} else {
str->data = ret;
memset(&str->data[str->max], 0, n �C str->max);
str->max = n;
str->length = len;
}
This we should not do for OPENSSL_malloc, in that case we can memset complete
buffer.
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!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing
Hi Matt,
I created a Pull request for the second change on master, 1.0.2 and 1.1.0. I am
creating PR in github for the first time, so if anything else I missed please
update me.
https://github.com/openssl/openssl/pull/3124
https://github.com/openssl/openssl/pull/3123
https://github.com/openssl/openssl/pull/3122
Regards,
Ashok
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!
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt
Caswell
Sent: 03 April 2017 14:40
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding
write failure are missing
On 31/03/17 18:54, Raja ashok wrote:
> 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);
>
> }
This is 1.0.2 code. The check appears to be earlier in master/1.1.0 (before
wnum is reset) and so this isn't an issue there. Really, if an application
passes a bad len value, then this is an application bug and shouldn't ever
happen in a well-behaved application. I'm not sure you could really describe
this as an OpenSSL bug (its a bit border line) so I'm not sure it justifies a
patch to 1.0.2 (which only takes bug fixes).
>
> 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);
>
> }
Please could you raise a github pull request for this suggestion? You will
probably need two versions: one targeting master and one targeting
1.0.2 as the the code looks a little different in this area.
Matt
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing
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-us...@openssl.org'; 'openssl-dev@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 2 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 2.
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!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] 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 2 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 2.
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!
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] DTLS is not sending alert in case of BAD CCS
Hi All, Looks like there is a typo mistake in dtls1_read_bytes, because of this alert is not send for bad CCS. In dtls1_read_bytes, incase of bad change cipher spec we are setting alert code (SSL_AD_ILLEGAL_PARAMETER) to variable “i” and doing “goto err”. I feel we are trying to send alert in this case, so we need to set the alert in “al” and do “goto f_err”. In case of TLS we are sending alert. Note : I am referring 1.0.2.k 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! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Doubt regarding Export keying material
Hi All, I am having a doubt in usage of Exporting keying material API (SSL_export_keying_material) in OpenSSL. Please provide your suggestions. As per Section 4 in RFC 5705, context length should be passed as uint16_t to PRF function. In that case we should allow only upto max of 2^16 (65535). So user should not pass more than 65535 value to “plen” in SSL_export_keying_material right ? Please provide your valuable suggestion on this. I am referring 1.0.2k version of OpenSSL. Thanks & 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! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Doubt regarding process of invalid [D]TLS record
Hi All, In dtls1_get_record(), we are calling ssl3_read_n to get 13 bytes of DTLS record header from socket and then based on the length in record header, we again call ssl3_read_n to get record payload from socket. Here we are handling invalid record, like length less 13 bytes or invalid version in record header or invalid epoch etc. If such invalid record comes then we are dropping that record and going to read again from socket, by calling ssl3_read_n again. If a peer is continuously sending invalid DTLS record, then our execution will be just running inside dtls1_get_record function. It wont come out of that function. So if a malicious peer wants to block our DTLS connection thread, then it can do by simply sending invalid DTLS record continuously. This behaviour would be same for both synchronous and asynchronous UDP sockets. This will simply block the application for long time, for the API SSL_connect, SSL_accept or SSL_read. I feel here we should not block the application call for long time, we should have some mechanism to fail the connection and inform application if we get invalid DTLS record continuously. For example, if we receive around 100 invalid DTLS record continuously, then we should come out of this "goto" in dtls1_get_record and return failure to application. And also we can send alert to peer and close the DTLS connection. For similar issue in ssl3_get_record(), we are having a max limit(MAX_EMPTY_RECORDS) for the received empty record. I feel similar limit should be there for invalid DTLS record in dtls1_get_record. Similarly in ssl3_get_message and dtls1_get_message_fragment, if we receive Hello request message continuously, then we are just dropping and continuously going back to read on socket. This also may cause a long time block to application, for the API SSL_connect if malicious peer is continuously sending Hello request msg. I feel blocking of application call for a long time should be avoided. Please check this and clarify me, if my understanding is wrong. Note : I am referring openssl-1.0.2k and asking this doubt. 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! -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
