lib/43828: openssl lib in 5.0.2 SEGV during SSL_accept

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

>Number:         43828
>Category:       lib
>Synopsis:       openssl lib in 5.0.2 SEGV during SSL_accept
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Sep 02 15:30:00 +0000 2010
>Originator:     Wolfgang Stukenbrock
>Release:        NetBSD 5.0.2
>Organization:
Dr. Nagler & Company GmbH
        
>Environment:
        
        
System: NetBSD s051 5.0.2 NetBSD 5.0.2 (NSW-S051) #2: Thu Aug 12 18:30:48 CEST 
2010 wgstuken@s051:/usr/src/sys/arch/amd64/compile/NSW-S051 amd64
Architecture: x86_64
Machine: amd64
>Description:
        The openssl-lib included in the NetBSD-5.0.2 distribution will SEGV in 
SSL_accept when
        the latest Firefox connects to pkgsrc-apache22 server - serving an 
open-Xchange application.
        (remark: the open-Xchange entries in apache are only some proxy entries)

        The problem does not show up with older versions of Firefox and not 
with the pkgsrc-2010Q2
        openssl-0.9.8 version. I cannot say what the latest Firefox makes in a 
different wya as before,
        but I'm shure it gets widely distributed soon ...
        I've debugged the openssl-lib by adding some debug prints to it in 
order to find the cause of the problem.

        The analyses follows:

        The firefox sends the following information as greeting:


        11 bytes - first read of the lib
        16 03 01 01 ac 01 00 01 a8 03 01 

        422 bytes - second read of the lib
        4c 7e 32 1f 5b cc aa 55 61 8b 89 71 38 c6 5a ff 48 e6 65 16 f7 57 51 06 
5a 9b 39 e5 8d 70 4a 52
        20 3f a0 3e fa 01 aa aa 6c 02 24 4a 7e f2 00 de 2b 70 b3 74 e3 16 2c 38 
43 b2 58 cb bd 2b 29 4b
        c6 00 48 00 ff c0 0a c0 14 00 88 00 87 00 39 00 38 c0 0f c0 05 00 84 00 
35 c0 07 c0 09 c0 11 c0
        13 00 45 00 44 00 33 00 32 c0 0c c0 0e c0 02 c0 04 00 96 00 41 00 04 00 
05 00 2f c0 08 c0 12 00
        16 00 13 c0 0d c0 03 fe ff 00 0a 01 00 01 17 00 00 00 1d 00 1b 00 00 18 
78 6e 30 31 31 2e 6e 61
        67 6c 65 72 2d 63 6f 6d 70 61 6e 79 2e 63 6f 6d 00 0a 00 08 00 06 00 17 
00 18 00 19 00 0b 00 02
        01 00 00 23 00 e0 ff 29 e6 33 3b 35 d1 c4 2d 4e 63 8e 63 f7 f4 96 19 03 
aa ea a1 22 1f f0 90 0f
        89 65 ce 29 11 b4 79 70 e1 03 3f fa 3f 30 3a 01 59 97 a4 08 bc 5f a8 a7 
01 bc a6 e6 64 63 cd 26
        86 cb 5b 6d fa 93 91 59 e9 d0 11 e6 91 6d e4 37 58 20 eb 57 82 ad 17 76 
58 07 3e 5e 29 69 77 52
        2f 9b b7 a9 46 4b ae 3a 17 cd fd 16 89 d0 91 9b dd 93 3d ed 40 b1 2d d9 
99 14 09 d4 dc e0 66 c1
        ae c2 a2 ab aa cc 5c b3 a1 a4 ec 5f 2b 3e 26 16 3f f0 5e 1b 52 0f 5f 31 
14 00 2b d6 bf 4e b4 74
        2a 2a 15 36 fb 74 48 67 df 0d 59 47 cd 70 c1 7c 9d 53 d9 ce b8 0d 1c 20 
b6 88 4d e8 93 ef 86 e0
        b9 99 7c 70 72 18 4b bc f9 f3 cb 4e 82 64 fb 1e 95 77 65 20 a6 3a 16 4b 
26 c9 75 5f 2b 3b cf 33
        e7 8b 35 b5 39 03 

        The SSL is setup to accept SSLv23 connection by apache.
        The accept-stuff of the SSLv23 code reads in the first 11 bytes (shown 
above) and switches to
        TLSv1 mode. It re-injects the 11 bytes into the input again and starts 
the accept stuff from
        the choosen method - in this case ssl3_accept().
        There it starts with the state SSL3_ST_SR_CLNT_HELLO_A, switches to 
SSL3_ST_SW_SRVR_HELLO_A,
        SSL3_ST_SW_CHANGE_A and SSL3_ST_SW_FINISHED_A.
        There it calls ssl3_send_finished() that will call ssl3_do_write().
        ssl3_do_write() calls ssl3_finish_mac(). The comment there says, that 
this makes not realy sence
        for HELLO processing, but the result will be ignored in this case -- OK 
- not the best way, but ..
        In ssl3_finish_mac() "s->s3->handshare_buffer" is not set, so it starts 
looking for entries in
        "s->s3->handshake_dgst", but this is still a NULL pointer -> SEGV

        I've added a check for a NULL pointer here in oder to go on, because it 
sounds reasonable to ignore
        this problem here and assume no entry in "s->s3->handshake_dgst" is set.
        But this does not solve the problem. The communication continues a 
little bit and again a SEGV
        happens due to a missing "s->s3->handshake_dgst" at another place - 
still withing SSL_accept().

        Here I stop debugging, because I do no know much about the internals of 
openssl and the SSL communication
        during startup. I don't know if it is a legal stat to to from HELLO to 
CHANGE without setting up
        the (required) buffers, or if it is just a bug that there are some NULL 
checks missing.

        Conclusion:
          The currently integrated version of openssl in the 5.0.2 distribution 
is broken.

        But I'm not shure about the version number of it.
        The name of the changelog-file "ChangeLog.0_9_7-stable_not-in-head" 
contains change information
        for the 0.9.7 version, but the "CHANGES" file contains change 
information from 0.9.8g to 0.9.9
        and there are some version strings with 0.9.9-dev in the source code.
        I cannot find any version named 0.9.9 on the openssl webside - so I'm 
confused about version it is.
        This is the reasone why I cannot report this problem to the 
openssl-people.

        The version 0.9.8o from pkgsrc-2010Q2 works fine, so as a workaround 
for apache22 I've added
        "PREFER.openssl?=pkgsrc" to the Makefile.
        Neverless all other components of the 5.0.2 distribution using the 
openssl library are affected
        and may SEGV during SSL_accept() - eg. sshd - if a client uses a 
connect method as the latest
        Firefox does.
>How-To-Repeat:
        Install 5.0.2, install apache22 from pkgsrc. Get open-Xchange server 
and install it on a
        supported system. Move the apache-proxy configuration entries from that 
system to the 5.0.2.
        Get latest Firefox for Linux or Windows (still alpha-version) and try 
to use it.
        You can see lots of SEGV reports in the logfile of apache.
>Fix:
        As a workaround for apache you can use the pkgsrc-openssl-version also 
on NetBSD by adding
        "PREFER.openssl?=pkgsrc" to the apache makefile. I'm shure there is 
also a way to add this
        to all packages useing openssl in pkgsrc, but I do not know it - sorry

        As fix I recommend to switch to working verions (e.g. 0.9.8o) in the 
distribution.

>Unformatted: