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

 ( NevemTeve | 2017. február 22., szerda - 19:14 )

2018.04.06. 04:06
Ezt most minek néztem meg?!

[308]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 __tab
[309]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 __itab
[310]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 guesses
[311]   0x00000000    undef      IMP     RW EXTref /opt/lib64/libclntsh.so.10 tantab

Szerk: relax, én bénáztam, a 10-es még gyárilag oké, 11-től jött be a '-bexpall', ezt a tizest én rontottam el. A hibát érzékeltetendő ezt a kettőt nézzük össze: explist explist_so

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

innen lehet észrevenni, hogy már az alapötlet is hibás volt :(

Miert nem eroszakolod statikusan a linkelest? Vagy AIX-en nem mukodik a

gcc -o httpd httpd.o /usr/local/lib64/libcrypto.so.1.0.2

cimu fekete magia? Linuxon igy ki lehet eroszakolni, hogy mit hova linkeljen, es ebbol asszem ugyanugy statik linkeles lesz, mint a -lcrypto kapcsoloval.

Bar az az igazsag, hogy fura nekem ez az egesz. Elvben a libclntsh.so.12 csak akkor kerulhetne kepbe, ha a httpd Ora fuggoseggel fordulna (mondjuk egy imaginarius mod_auth_oracle modul okan). Ettol eltekintve a Makefile-oknak -lcrypto -lssl kapcsolokkal kellene operalniuk. Hogy ebbol hogy lesz -lclntsh... hacsak valahol valaki nem symlinkeli a libcrpyto.so -t a libclntsh.so.12-re akkor sehogy.
--
Blog | @hron84
Üzemeltető macik

Hát, szerintem ha egyvalamit érdemes lenne megnézni, az az, hogy Linuxon egy Oracle Instant Client 12.1 -beli libclntsh.so is exportálja-e mindezeket a szimbóleumokat:

^(BIO_|ERR_|SSLv23_|SSLv3_|TLSv1_|ssl23_|ssl3_|ssl_|tls1_|BZ2_|inflate|deflate)

Gondolom, hogy nem, mert akkor már kitört volna a parasztlázadás;)

Nem tort volna ki, ugyanis az AIX-szal ellentetben Linuxon a Oracle Instant Client nem resze az alaptelepitesnek, es forditaskor sosincs jelen a gepen. Vagyis eselytelen ahhoz linkelni a linker, futaskor meg azert van az a kis dictionary az ELF-ben, hogy tudja melyik fuggvenyt melyik libbol kell kikeresni.

Raadasul Linuxon a libclntsh.so szinte sosincs rajta a standard linker utvonalakon, az mindig kulon mokolas, hogy egyaltalan mukodjenek az ezt hasznalo stuffok.
--
Blog | @hron84
Üzemeltető macik

Szerintem ez a dinamikus linkelés fordítva van: AIX-on lehet (és szokás) beleírni a binárisba azt, hogy melyik shared objectből jöjjenek az egyes szimbóleumok; linuxon viszont az 'ahogy esik, úgy puffan' elv érvényesül, ezért lehet LD_PRELOAD-változókkal haxorkodni... akarom mondani, wrappereket készíteni (pl. runsocks)

>"static" link expertizing

kys

Inkabb segits.
--
Blog | @hron84
Üzemeltető macik