Security Audit Notes: OpenSSL d1_srvr.c Overflow - Advanced Information Security

["Nicholas Lemonias." <lem.nikolas () googlemail com>]

-=[ Advanced Information Security Corporation ]=-

 ------------------------------------------------------------------------

 Author: Nicholas Lemonias
 Type: Security Audit Notes
 Date: 17/3/2015
 Email: lem.nikolas (at) gmail (dot) com
 Audit: OpenSSL v1.0.2 (22nd of January, 2015 Release)
 ------------------------------------------------------------------------


 Introduction
 ==========
 During a source-code audit of the OpenSSL v1.0.2 implementation for
 Linux; conducted internally by the Advanced Information Security
 Group, instances of deprecated function use, were observed.
 An insecure memcpy() is utilized; where a destination buffer, a
source buffer, and the number of bytes to copy are accepted by the
called function.

 It is pertinent to note, that the memcpy() function does not check
for a potential overflow of the receiving memory area in this
instance, and no custom security validation controls are in place. [1]
[2]

 Software Overview
 ===============
 OpenSSL is an open-source implementation of the SSL and TLS protocol.
 The core library is written in the C Language, and implements basic
 cryptographic functions, and
 also provides various utility functions. Implementation versions are
 available for most UNIX-like operating systems (including
Solaris,Linux, Mac OS X and the various open-source BSD operating
systems), OpenVMS and Microsoft Windows. IBM provides a port for the
System i (OS/400). OpenSSL is based on SSLeay by Eric Andrew Young and
Tim Hudson, development of which unofficially ended on December 17,
1998, when Young and Hudson both started to work for RSA Security.

 Vulnerability
 ===============

  (1) Deprecated function use / Insecure memcpy() utilization.


 The insecurity stems from the lack of any bounds-checking of the
called memcpy function.  The memcpy function permits the "peer's"
cookie length, to overlap buffers.

 The provided  buffer (s->d1->cookie) is for the user-app to fill in;
however, a custom user application could provide an overlong cookie to
exceed it's buffer, and to overflow beyond and into other volatile
memory locations.

Therefore any security is purely on the basis of trust that the remote
peer will not act contrary to protocol, and that the user app  is
trusted not to abuse functionality.


 PoC - Code Snippet
 ========================
 (.../openssl/ssl/d1_srvr.c)

 { Lines 918 - 942 }


int dtls1_send_hello_verify_request(SSL *s)
{
    unsigned int msg_len;
    unsigned char *msg, *buf, *p;

    if (s->state == DTLS1_ST_SW_HELLO_VERIFY_REQUEST_A) {
        buf = (unsigned char *)s->init_buf->data;

       msg = p = &(buf[DTLS1_HM_HEADER_LENGTH]); //buf is equal to 12
        /* Always use DTLS 1.0 version: see RFC 6347 */
        *(p++) = DTLS1_VERSION >> 8;
        *(p++) = DTLS1_VERSION & 0xFF;

        if (s->ctx->app_gen_cookie_cb == NULL ||
            s->ctx->app_gen_cookie_cb(s, s->d1->cookie,
                                      &(s->d1->cookie_len)) == 0) {
            SSLerr(SSL_F_DTLS1_SEND_HELLO_VERIFY_REQUEST,
                   ERR_R_INTERNAL_ERROR);
            return 0;
        }

        *(p++) = (unsigned char)s->d1->cookie_len;
        memcpy(p, s->d1->cookie, s->d1->cookie_len);
// Cookie_len is provided by a callback function above - and where,
input is  // provided by the user-app.

        p += s->d1->cookie_len;
        msg_len = p - msg;


 Appendices
 ==========
 Sincere Thanks to the OpenSSL team for their feedback.


 References
 ==========
[1] Oracle (2015). Basic Library Functions - Title: memcpy() man pages [Online]
 Available at: https://docs.oracle.com/cd/E19683-01/816-0213/6m6ne386d/index.html
[Last Accessed 17 Mar. 2015]

[2] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press