[stunnel-users] Bad Magic

[Peter Pentchev]

On Tue, Feb 21, 2017 at 11:23:02PM +0100, Michał Trojnara wrote:
> On 21.02.2017 16:04, Melzer, Jacob wrote:
> > 2017.02.21 09:31:25 LOG5[ui]: stunnel 5.40 on powerpc-ibm-aix6.1.0.0
> > platform
> > 2017.02.21 09:31:25 LOG5[ui]: Compiled/running with OpenSSL 1.0.2j  26
> > Sep 2016
> [cut]
> > INTERNAL ERROR: Bad magic at OpenSSL, line 0
> 
> This is the way stunnel detects heap corruption.  Something is very
> wrong with your deployment.  This could either be caused by stunnel or
> by OpenSSL.  I suspect the latter, as your client works fine.  There is
> very little architecture-dependent code in stunnel, so a bug in stunnel
> would likely cause it to fail miserably also in the client mode.
> 
> > mem.CRYPTO_free() at 0xd97dd8d8
> > bn_lib.bn_expand2 at AF37_5() at 0xd97e8da4
> > bn_mont.BN_mod_mul_montgomery() at 0xd981e150
> > ecp_mont.ec_GFp_mont_field_mul() at 0xd9837a18
> > ecp_smpl.ec_GFp_simple_point_get_affine_coordinates() at 0xd9839890
> > ec_lib.EC_POINT_get_affine_coordinates_GFp() at 0xd9a81dfc
> > ecp_oct.ec_GFp_simple_point2oct() at 0xd9acc0d4
> > ec_oct.EC_POINT_point2oct() at 0xd9acb754
> > ssl3_send_server_key_exchange() at 0xd99e7c28
> > ssl3_accept() at 0xd99e9950
> > SSL_accept() at 0xd99c0b98
> 
> It may be an issue in big number implementation.  It is hard to be sure,
> because your heap was already corrupted before the CRYPTO_free() call.

Hmm, I wonder if this might be the same bug I chased down
a month ago, but... well, yeah, if it is, I'm sorry that
I did not complete my analysis and let you know about it :(

In short, if the crypto negotiation fails very early, e.g.
there are no common ciphers between the two sides of the TLS
connection, there is a double free in the stunnel cleanup code.
You may see more details about this in the Debian bug discussion:
https://bugs.debian.org/850292 ... I'll have to look at the code
to remember exactly what happened, but basically stunnel tried
to free the SSL session structure that had already been freed by
the OpenSSL code.  The Debian patch that seemed to fix the problem
may be found at:
https://anonscm.debian.org/cgit/collab-maint/stunnel.git/tree/debian/patches/08-session-free.patch

I didn't tell you then because I thought I'd take a couple more
days to look at the OpenSSL code, because it seemed that there is
no real way for stunnel to determine whether OpenSSL has 1. initialized,
and/or 2. already freed the SSL session structure when an error
handler is called :(  I tried to follow the OpenSSL code, seemed to
come to this conclusion (that there's no way to tell), then looked at
the code some more, got lost in it, and something else came up and
I put it off.

This might be a genuine problem with OpenSSL; however, the removal of
the SSL_SESSION_free() call seemed to fix the problem both for
the original reporter and in my attempts to reproduce the issue
(it may be reproduced easily by running OpenSSL in server mode and
connecting to it with a GnuTLS client after supplying gnutls-cli with
a priority string instructing it to disable all key exchange algos and
only enable one that is not supported by the stunnel/OpenSSL config...
or so I remember, I'll give it a try tomorrow and let you know in more
detail).  I'll look at the OpenSSL code again tomorrow to try to
remember where I got lost in it :)

Once again, sorry I didn't let you know back then and sorry I gave
up on the analysis :(

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at FreeBSD.org pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20170222/3017cab5/attachment.sig>