Hi Paulo,Hi Ohad,
as promised, a fix is available on SVN trunk. Here is the commit log,
describing the bug:
fixed bug when the ssl library you compiled against uses kerberos. Kerberos
implementation is faulty when comes to memory management as it always use the
libc malloc/free (for the kerberos context). And the SSL structure is kept in
shm memory and moved across processes, so the link from SSL to krb_ctx will
become broken (point into private memory of another process).
The fix is to immediately free the krb_ctx (if kerberos is compiled in) to
avoid the broken mem reference.
At compile time, the kerberos presnece is tested (OPENSSL_NO_KRB5) to see if
the fix should be activated or not.
At runtime, the code performs a check to see if the library you are running
against is the same as the one you compiled against (from kerberos presence
point of view). This prevents crashes like: compile openser against an openssl
with no kerberos (so the fix will not be activated) and later run it against
an openssl with kerberos.
If differences are detected, openser will not start and you probably need to
recompile it locally.
please update and let me know if work for you now. Also many thanks for
the report and help in troubleshooting this issue.
regards,
bogdan
Bogdan-Andrei Iancu wrote:
Hi,
I found the bug - it is in the openssl, int kerberos part (using wrong
malloc functions in openssl and kerberos leads to inconsistent date in
multiprocess environment).
The problem showed up so rear as openssl in most of the distros is
compiled without kerberos support. On FC, it is included.
I will come back tomorrow with more info and a patch to fix this.
regards,
Bogdan
Bogdan-Andrei Iancu wrote:
> Hi Paulo,Hi Ohad,
>
> could you please send me the output of
>
> >\ openssl ciphers
>
> from your machines?
>
>
> regards,
> bogdan
>
> Paulo Angonese wrote:
>> My version of krb5-libs is krb5-libs-1.4.1-5. The newest for FC4...
>>
>>
>> Paulo Angonese escreveu:
>>> Bogdan, here is the bt:
>>>
>>> $ gdb /usr/local/sbin/openser core.9999
>>>
>>> ....
>>>
>>> #0 0x00c63b87 in strchr () from /lib/libc.so.6
>>> #1 0x0033dc53 in krb5_kt_resolve () from /usr/lib/libkrb5.so.3
>>> #2 0x003cf5a0 in kssl_keytab_is_available () from /lib/libssl.so.5
>>> #3 0x003bbc4c in ssl3_choose_cipher () from /lib/libssl.so.5
>>> #4 0x003b73c0 in ssl3_accept () from /lib/libssl.so.5
>>> #5 0x003c4eba in SSL_accept () from /lib/libssl.so.5
>>> #6 0x080e1dc9 in tls_accept (c=0xb616b490) at tls/tls_server.c:236
>>> #7 0x080e35cc in tls_fix_read_conn (c=0xb616b490) at
>>> tls/tls_server.c:872
>>> #8 0x0809c428 in tcp_read_req (con=0xb616b490,
>>> bytes_read=0xbfad8448) at tcp_read.c:411
>>> #9 0x0809c7a7 in handle_io (fm=0x814e1b0, idx=-1) at tcp_read.c:772
>>> #10 0x0809dbf3 in io_wait_loop_epoll (h=0x8113020, t=Variable "t"
>>> is not available.
>>> ) at io_wait.h:722
>>> #11 0x0809df67 in tcp_receive_loop (unix_sock=17) at tcp_read.c:893
>>> #12 0x08093969 in tcp_init_children (chd_rank=0x810dcd4) at
>>> tcp_main.c:1745
>>> #13 0x0806ce1e in main_loop () at main.c:1009
>>> #14 0x0806e8cb in main (argc=1, argv=0xbfad86f4) at main.c:1477
>>>
>>>
>>>