Bug 181994

Summary: net-im/ejabberd crashes with openssl+zlib
Product: Ports & Packages Reporter: Vick Khera <vivek>
Component: Individual Port(s)Assignee: Ashish SHUKLA <ashish>
Status: Closed Not Accepted    
Severity: Affects Only Me CC: cs
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description Vick Khera 2013-09-10 17:30:01 UTC
	

I'm *really* not sure who's "fault" this is... but when ejabberd is built with
openssl 1.0.1e from ports, it drops core every time it attempts to make a TLS
s2s connection to proxy.eu.jabber.org. My reading of the gdb output shows it
croaks in some function inside libz.so.

I rebuilt openssl without support for zlib, and the problem went away.
Comparing the configuration to the base system openssl, I see that zlib is
also disabled there, so I feel confident that this is an acceptable solution.

That said, none of my other applications had any problems with zlib support in
openssl:  apache, subversion, postfix, openvpn, opendkim, nrpe2, etc. but I
don't know if they even tried to use compression.

Fix: 

rebuild openssl port without zlib support.
How-To-Repeat: 	

Here's what GDB had to say about the core dump (program exited signal 11)

(gdb) where
#0  0x0000000807faac62 in deflateCopy () from /usr/lib/libz.so
#1  0x0000000807fab455 in deflateSetDictionary () from /usr/lib/libz.so
#2  0x0000000807fabe97 in deflate () from /usr/lib/libz.so
#3  0x000000080747dbae in zlib_stateful_compress_block ()
   from /usr/local/lib/libcrypto.so.8
#4  0x000000080747ce22 in COMP_compress_block ()
   from /usr/local/lib/libcrypto.so.8
#5  0x0000000807939eee in ssl3_do_compress () from /usr/local/lib/libssl.so.8
#6  0x000000080793a0b4 in do_ssl3_write () from /usr/local/lib/libssl.so.8
#7  0x000000080793a5ec in ssl3_write_bytes () from /usr/local/lib/libssl.so.8
#8  0x000000080793cb1d in ssl3_do_write () from /usr/local/lib/libssl.so.8
#9  0x0000000807936420 in ssl3_connect () from /usr/local/lib/libssl.so.8
#10 0x0000000807da2d93 in tls_drv_control ()
   from /usr/local/lib/erlang/lib/ejabberd-2.1.13/priv/lib/tls_drv.so
#11 0x000000000048641f in erts_port_control ()
#12 0x00000000004fd0cf in port_control_3 ()
#13 0x000000000052dd1e in process_main ()
#14 0x0000000000498b5c in erts_test_next_pid ()
#15 0x0000000000594ce9 in ethr_thr_join ()
#16 0x00000008010840a4 in pthread_getprio () from /lib/libthr.so.3
#17 0x0000000000000000 in ?? ()
Cannot access memory at address 0x7fffff7ed000
(gdb)
Comment 1 Ruslan Makhmatkhanov freebsd_committer freebsd_triage 2013-09-10 23:01:17 UTC
Responsible Changed
From-To: freebsd-ports-bugs->ashish

Over to maintainer.
Comment 2 Ashish SHUKLA freebsd_committer freebsd_triage 2013-09-10 23:48:44 UTC
Hi Vivek,

This is a known issue[1] from quite sometime. I'm not sure about the fix
either, though the workaround you already posted.

Probably a bug needs to be filed upstream, if not already in all these
years.

I can file one by the end of the week, if you've not already reported it
upstream.

References:
[1]  http://lists.jabber.ru/pipermail/ejabberd/2007-March/002604.html

Thanks
-- 
Ashish SHUKLA      | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
Sent from my Emacs
Comment 3 Vick Khera 2013-09-11 13:04:50 UTC
Wow. Thanks for the followup. I searched google but nothing like this came
up. I'm shocked that 6 years later it sill crashes like that!

I don't think it is such a big deal, since current security thinking is
that compression on encrypted streams is a bad idea anyway, at least for
HTTPS.
Comment 4 Ashish SHUKLA freebsd_committer freebsd_triage 2013-09-16 07:46:45 UTC
Hi,

Filed an upstream bug report EJAB-1663[1].

References:
[1]  https://support.process-one.net/browse/EJAB-1663

-- 
Ashish SHUKLA      | GPG: F682 CDCC 39DC 0FEA E116  20B6 C746 CFA9 E74F A4B0
Sent from my Emacs
Comment 5 Carlo Strub freebsd_committer freebsd_triage 2014-09-15 05:06:32 UTC
Is this PR still relevant?
Comment 6 Ashish SHUKLA freebsd_committer freebsd_triage 2014-09-15 10:26:55 UTC
(In reply to Carlo Strub from comment #5)
> Is this PR still relevant?

It's still not fixed AFAIK, and is being tracked upstream.

Ashish
Comment 7 Carlo Strub freebsd_committer freebsd_triage 2014-09-15 11:22:09 UTC
Closing PR because it was reported upstream.