[Megoldva] apache/openssl -- valami baj van a certificate-tel

2018.04.05. 10:08
És a 11-es InstantClient-ben is. Legjobban a PHP-val tudok nyomozni:

dump -X64 -Tv /usr/local/libexec64/apache2/libphp7.so | grep libclntsh

Ami itt nem OCI***, az nagyjából biztosan kalózakció.

2017.02.26. 13:13
Elnézést kérek az InstantClient-től, én tévedtem. Igazából 'rendes' 12-es kliensben is megvan ez a hiba, nem csak az Instant-ban.

2017.02.23. 15:33
Bónusz a libclntsh.so-tól: BZ2_bzCompress* és BZ2_bzDecompress*
Meg nyilván még jó sok minden, amit nem látok...

2017.02.23. 15:17
Akkor most így néz ki az InstantClient-relinkelő Makefile releváns része:

DONT_EXPORT_THESE_YOU_JERK := ^(BIO_|ERR_|SSLv23_|SSLv3_|TLSv1_|ssl23_|ssl3_|ssl_|tls1_)

%.exp_64: ../lib64/%.so.orig
        explist $< >$@.to_prune
        egrep -v '${DONT_EXPORT_THESE_YOU_JERK}' $@.to_prune >$@

%.exp_32: ../lib32/%.so.orig
        explist $< >$@.to_prune
        egrep -v '${DONT_EXPORT_THESE_YOU_JERK}' $@.to_prune >$@

2017.02.23. 13:27
Szóval az Ora instaclient tartalmaz egy openssl-szerűséget, emiatt a linkelés kavarossá válik. Most éppen a PHP-n látszik a legjobban:

grep BIO libphp7.so.imports 
[375]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.12 BIO_printf
[376]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.12 BIO_free
[377]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.12 BIO_new
[378]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.12 BIO_write
[379]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.12 BIO_ctrl
[380]   0x00000000    undef      IMP     DS EXTref /opt/lib64/libclntsh.so.12 BIO_free_all
[484]   0x00000000    undef      IMP     DS EXTref /usr/local/lib64/libcrypto.so.1.0.2 BIO_puts
[485]   0x00000000    undef      IMP     DS EXTref /usr/local/lib64/libcrypto.so.1.0.2 BIO_s_mem
[486]   0x00000000    undef      IMP     DS EXTref /usr/local/lib64/libcrypto.so.1.0.2 BIO_new_mem_buf
[487]   0x00000000    undef      IMP     DS EXTref /usr/local/lib64/libcrypto.so.1.0.2 BIO_new_file

2017.02.23. 13:18
Asszem az őrülési folyamatban kellőképpen előrehaladtam:

(gdb) bt
#0  0x0900000001eb9900 in BIO_new () from /opt/lib64/libclntsh.so.12
#1  0x0900000012d3e370 in SSL_CTX_use_certificate_chain_file (ctx=0x11014b110, 
    file=0x110120358 "/usr/local/etc/ssl_keys/bmkh.cert.pem") at ssl_rsa.c:694
#2  0x0900000012d9a188 in ?? ()
#3  0x0900000012d9bf40 in ?? ()
#4  0x0900000012d9c84c in ?? ()
#5  0x0900000012d96fc8 in ?? ()
#6  0x0000000100007784 in ap_run_post_config (pconf=0x900000012d99cd0, plog=0x1b4766f500000020, ptemp=0x900000012d8822c, s=0x11014a060)
    at config.c:106
#7  0x00000001000024d0 in main (argc=2, argv=0xffffffffffff4b0) at main.c:702

Namostakkor a libssl.so-ból valahogy átszédültünk a libclnstsh.so-ba?!

2017.02.23. 13:08
Végülis úgy vált debuggolhatóvá, hogy a httpd.exe-nek függőségévé tettem a libphp7.so-t, akinek függősége a libssl.so.1.0.2, tehát mindezek eleve betöltődnek induláskor.
Ezzel még nem oldottam meg semmit, csak meg lehet kezdeni a debuggolást...

2017.02.23. 12:22
Csak hogy tudjam:

#define AP_IMPLEMENT_HOOK_RUN_ALL(ret,name,args_decl,args_use,ok,decline) \
        APR_IMPLEMENT_EXTERNAL_HOOK_RUN_ALL(ap,AP,ret,name,args_decl, \
                                            args_use,ok,decline)

valamint

#define APR_IMPLEMENT_EXTERNAL_HOOK_RUN_ALL(ns,link,ret,name,args_decl,args_use,ok,decline) \
APR_IMPLEMENT_EXTERNAL_HOOK_BASE(ns,link,name) \
link##_DECLARE(ret) ns##_run_##name args_decl \
    { \
    ns##_LINK_##name##_t *pHook; \
    int n; \
    ret rv = ok; \
    APR_HOOK_INT_DCL_UD; \
\
    APR_HOOK_PROBE_ENTRY(ud, ns, name, args_use); \
\
    if(_hooks.link_##name) \
        { \
        pHook=(ns##_LINK_##name##_t *)_hooks.link_##name->elts; \
        for(n=0 ; n < _hooks.link_##name->nelts ; ++n) \
            { \
            APR_HOOK_PROBE_INVOKE(ud, ns, name, (char *)pHook[n].szName, args_use); \
            rv=pHook[n].pFunc args_use; \
            APR_HOOK_PROBE_COMPLETE(ud, ns, name, (char *)pHook[n].szName, rv, args_use); \
            if(rv != ok && rv != decline) \
                break; \
            rv = ok; \
            } \
        } \
\
    APR_HOOK_PROBE_RETURN(ud, ns, name, rv, args_use); \
\
    return rv; \
    }

Ezt mondjuk magamtól is kitalálhattam volna...

2017.02.23. 10:05
Megint fennakadtam a gdb-vel az OpenSSL Altivec-testjén.
(gdb) handle SIGILL nostop noprint

2017.02.23. 07:06
Most jön a meglepő hír: ugyanez elsőre megy linuxon.

Mindegy, vissza AIX-ra, most fordul a httpd debug-gal (-g).
No nem mintha az olyan könnyű lenne. Mondom neki, hogy CFLAGS='-g ...', LDFLAGS='-g ...'; a configure bólogat, hogy persze, érti, csak éppen semmilyen Makefile-ba vagy *.mk fájlba nem került bele az a -g.
Mondjuk erre való a 'sed_repl'

2017.02.22.
De rendes, mert el is magyarázza:

error:140DC007:SSL routines:SSL_CTX_use_certificate_chain_file:BUF lib

Ha nem tévedek nagyot, ez azt jelenti, hogy valami baj van a certificate-tel. Mondjuk más kontextusban már be tudtam tölteni ezt a valami.cert.pem fájlt ugyanezzel a SSL_CTX_use_certificate_chain_file függvénnyel, saját programban, de könnyen lehet, hogy a mod_ssl-ben valami másképp van. Előre a nyomozás útján!

Megj: úgy vélem látnia truss kimenetéből, hogy a certificate-fájlt igazából nem nyitja meg, csak stat-olja (kstatx) párszor. Egyébként 0400 a jogosultsága, a tartalmazó könyvtáré 0500, owner=root. Na majd még nézelődöm.

Kieg: Azt hiszem, a "BUF lib" ugyanaz, mint az ERR_R_BUF_LIB=0x07; a "SSL routines" pedig az ERR_LIB_SSL=0x14. Ez is hasznos adalék.