keyctl commands throw 'undefined symbol: dlopen' errors - centos5

I am running Centos 5.8 on a production server. I have an application that needs to use the keyctl command, but everytime the app calls (or I call) the command, I have some errors.
The first error was this:
root#server [~] keyctl show
segmentation fault
Then, I re-installed the keyutils binaries using yum. These are the keyutils packages I have on the server:
root#server [~]# rpm -qa | grep keyutils
keyutils-libs-1.2-1.el5
keyutils-libs-1.2-1.el5
keyutils-1.2-1.el5
keyutils-libs-devel-1.2-1.el5
And now, I have another different error:
root#server [~]# keyctl show
keyctl: symbol lookup error: /lib64/libkeyutils.so.1: undefined symbol: dlopen
I checked the libraries of keyctl, and libdl is not there.
root#server [~]# ldd /bin/keyctl
linux-vdso.so.1 => (0x00007fffcc5fd000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000033df000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003d7ae00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003d7aa00000)
All libraries that uses are fine.
root#server [~]# ls -al /lib64/libkeyutils*
-rwxr-xr-x 1 root root 9472 Jan 6 2007 /lib64/libkeyutils-1.2.so*
lrwxrwxrwx 1 root root 18 Nov 21 07:56 /lib64/libkeyutils.so.1 -> libkeyutils.so.1.9*
-rwxr-xr-x 1 root root 34584 Jan 6 2007 /lib64/libkeyutils.so.1.9*
root#server [~]# ls -al /lib64/libdl*
-rwxr-xr-x 1 root root 23360 Aug 27 08:59 /lib64/libdl-2.5.so*
lrwxrwxrwx 1 root root 12 Nov 16 02:01 /lib64/libdl.so.2 -> libdl-2.5.so*
root#server [~]#
Have you ever seen this problem before? I tried run the same version on others distros and it works.
I would like to re-install this server, but I can't because it is a production server.
Is there a way I can add or link a shared library to a binary already linked to others .so libraries?

Look at: http://blog.solidshellsecurity.com/2013/02/08/sshd-spam-rootkit-lib64libkeyutils-so-1-9/
It appears that there is no such legitimate file as libkeyutils.so.1.9
It is a rootkit, the latest legitimate version of this library is libkeyutils.so.1.3 on CentOS 6.3 (final).
rm -f /lib64/libkeyutils.so.1.9
ldconfig
/etc/init.d/sshd restart
There's also a suspected (as of now) unpatched user escalation priviledge flaw in all CentOS and RedHat kernels: https://access.redhat.com/security/cve/CVE-2013-0871 and http://blog.configserver.com/index.php?itemid=716
You may also need to reinstall SSH:
https://serverfault.com/questions/476954/remove-shared-library-from-sshd
https://forums.cpanel.net/f185/sshd-rootkit-323962.html

LD_PRELOAD=/lib64/libdl-2.5.so keyctl show

Related

Apache 2.4 start/stop throws "undefined symbol: ber_sockbuf_io_udp" error after configuring it with Shibboleth SP 3.2.0

Operating System: Red Hat Enterprise Linux Server 7.9 (Maipo)
Apache version: Apache/2.4.46 (Unix)
Shibboleth version: 3.2.0
Error when trying to stop Apache (apachectl stop):
httpd: Syntax error on line 528 of <Apache>/conf/httpd.conf: Syntax error on line 13 of <Apache>/conf/myshib.conf: Cannot load /usr/lib64/shibboleth/mod_shib_24.so into server: /usr/lib64/libldap_r-2.4.so.2: undefined symbol: ber_sockbuf_io_udp
Line 528 of <Apache>/conf/httpd.conf:
Include conf/myshib.conf
Line 13 of <Apache>/conf/myshib.conf:
LoadModule mod_shib /usr/lib64/shibboleth/mod_shib_24.so
Attempted - https://superuser.com/questions/1283252/slappasswd-symbol-lookup-error-undefined-symbol-ber-sockbuf-io-udp
But running "export LD_LIBRARY_PATH=/lib64:$LD_LIBRARY_PATH" did not resolve the issue.
Output of "ldd /usr/lib64/libldap_r-2.4.so.2" command:
linux-vdso.so.1 => (0x00007ffd1c76e000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f5b3e87d000)
libresolv.so.2 => /usr/lib64/libresolv.so.2 (0x00007f5b3e663000)
libsasl2.so.3 => /usr/lib64/libsasl2.so.3 (0x00007f5b3e446000)
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f5b3e1d4000)
libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f5b3dd71000)
libssl3.so => /usr/lib64/libssl3.so (0x00007f5b3db14000)
libsmime3.so => /usr/lib64/libsmime3.so (0x00007f5b3d8ec000)
libnss3.so => /usr/lib64/libnss3.so (0x00007f5b3d5b8000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f5b3d388000)
libplds4.so => /usr/lib64/libplds4.so (0x00007f5b3d184000)
libplc4.so => /usr/lib64/libplc4.so (0x00007f5b3cf7f000)
libnspr4.so => /usr/lib64/libnspr4.so (0x00007f5b3cd41000)
libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f5b3cb25000)
libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f5b3c921000)
libc.so.6 => /usr/lib64/libc.so.6 (0x00007f5b3c553000)
libcrypt.so.1 => /usr/lib64/libcrypt.so.1 (0x00007f5b3c31c000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00007f5b3c0cf000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00007f5b3bde6000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00007f5b3bbb3000)
libcom_err.so.2 => /usr/lib64/libcom_err.so.2 (0x00007f5b3b9af000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00007f5b3b79f000)
libz.so.1 => /usr/lib64/libz.so.1 (0x00007f5b3b589000)
librt.so.1 => /usr/lib64/librt.so.1 (0x00007f5b3b381000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5b3eceb000)
libfreebl3.so => /usr/lib64/libfreebl3.so (0x00007f5b3b17e000)
libkeyutils.so.1 => /usr/lib64/libkeyutils.so.1 (0x00007f5b3af7a000)
libselinux.so.1 => /usr/lib64/libselinux.so.1 (0x00007f5b3ad53000)
libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007f5b3aaf1000)
Then attempted - https://unix.stackexchange.com/questions/193320/yum-corrupted-on-rhel-6
Output of "for lib in /lib64/.so.; do if nm -D $lib|grep ber_sockbuf_io_udp; then echo $lib; fi; done" command:
000000000020e020 D ber_sockbuf_io_udp
/lib64/liblber-2.4.so.2
000000000020e020 D ber_sockbuf_io_udp
/lib64/liblber-2.4.so.2.10.7
U ber_sockbuf_io_udp
/lib64/libldap-2.4.so.2
U ber_sockbuf_io_udp
/lib64/libldap-2.4.so.2.10.7
U ber_sockbuf_io_udp
/lib64/libldap_r-2.4.so.2
U ber_sockbuf_io_udp
/lib64/libldap_r-2.4.so.2.10.7
Output of "rpm -qf /lib64/liblber-2.4.so.2" command:
openldap-2.4.44-22.el7.x86_64
Tried to install 'openldap' but it already existed
yum install openldap-2.4.44-22.el7.x86_64
Loaded plugins: langpacks, product-id, search-disabled-repos
Package openldap-2.4.44-22.el7.x86_64 already installed and latest version
Nothing to do
Restarted entire server and re-installed 'openldap' using "yum reinstall openldap.x86_64" command but no luck.
Apache starts and returns a response when accessing https://hostname.domain.com but downloading the Shib Metadata XML file via Apache using URL https://hostname.domain.com/Shibboleth.sso/Metadata fails.
Apologies if I missed adding anything obvious.
Update:
Works when using older Shibboleth version 3.1.0
similar thread here: https://unix.stackexchange.com/questions/193320/yum-corrupted-on-rhel-6
In my case (RHEL7.8 + Apache 2.4 + Shibboleth 3.2) I was able to resolve the issue by replacing the /usr/lib64/libldap_r-2.4.so.2 library with the one from the Apache directory: <APACHE_ROOT>/HTTPServer/openldap/lib/libldap_r-2.4.so.2
Run:
locate libldap_r-2.4.so.2
to find the location of the library.
In my case I got:
/app/ptc/Windchill_12.0/HTTPServer/openldap/lib/libldap_r-2.4.so.2
/app/ptc/Windchill_12.0/HTTPServer/openldap/lib/libldap_r-2.4.so.2.10.12
/usr/lib/libldap_r-2.4.so.2
/usr/lib/libldap_r-2.4.so.2.10.7
/usr/lib64/libldap_r-2.4.so.2
/usr/lib64/libldap_r-2.4.so.2.10.7
I noticed that the lib used in the error was in /usr/lib64 dir.
I replaced it and now ./apachectl -t reports
"Syntax OK"
I don't know enough about Linux to explain what is going on here or what the correct fix is.
This was my observation and resolved the issue, I believe my steps are a hack though.
Anyone with a more elegant, upgrade proof solution?
Reference: https://groups.google.com/g/repmgr/c/TS7QfYEoNoY
cd /usr/lib64/
ll | grep libldap
lrwxrwxrwx. 1 root root 21 Feb 11 16:42 libldap-2.4.so.2 -> libldap-2.4.so.2.10.7
-rwxr-xr-x. 1 root root 352512 Jun 6 2020 libldap-2.4.so.2.10.7
lrwxrwxrwx. 1 root root 23 Feb 11 16:42 libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.10.7
-rwxr-xr-x. 1 root root 381328 Jun 6 2020 libldap_r-2.4.so.2.10.7
It does seem like /usr/lib64/libldap_r2.4.so.2 is just a symlink to libldap_r-2.4.so.2.10.7.
I wonder if there are missing or deprecated symbols in 2.10.7...
Is there any way to tell the diff in the 2 versions?
UPDATE
I noticed that you can make use of the LoadFile command in the Apache conf.
Adding LoadFile <APACHE_ROOT>/HTTPServer/openldap/lib/libldap_r-2.4.so.2 in my 00-shib.conf file before the LoadModule mod_shib /usr/lib64/shibboleth/mod_shib_24.so entry resolved the issue.
This still seems like a workaround / hack to me and there may be an underlying issue with the libraries / different versions.

How to define the lua module path in nifi Processor ExecuteScript?

I am new to Lua.
Several days ago, I complished using python in ExecuteScript of NIFI. I set Python Module path to /usr/local/lib/python2.7/dist-packages. Everything goes well.
But doing the same thing with Lua is so difficult for me. Always Error of cannot find the Module!!!
I use Luarock to install modules.
Could you please tell me how to set the lua module path or some useful infomation about it?
Here comes some info of my Luarocks setting:
lbh#es-2:~/install/nifi-1.1.1/lua_modules$ luarocks list
Installed rocks:
----------------
lua-cjson
2.1.0-1 (installed) - /usr/local/lib/luarocks/rocks
luasocket
3.0rc1-2 (installed) - /usr/local/lib/luarocks/rocks
redis-lua
2.0.4-1 (installed) - /usr/local/lib/luarocks/rocks
An example of lua-cjson.
lbh#es-2:~/install/nifi-1.1.1/lua_modules$ luarocks show lua-cjson
lua-cjson 2.1.0-1 - A fast JSON encoding/parsing module
The Lua CJSON module provides JSON support for Lua. It features: - Fast,
standards compliant encoding/parsing routines - Full support for JSON with
UTF-8, including decoding surrogate pairs - Optional run-time support for
common exceptions to the JSON specification (infinity, NaN,..) - No
dependencies on other libraries
License: MIT
Homepage: http://www.kyne.com.au/~mark/software/lua-cjson.php
Installed in: /usr/local
Modules:
cjson
lua2json
json2lua
cjson.util
Directory info of /usr/local/lib/luarocks/rocks
lbh#es-2:~/install/nifi-1.1.1/lua_modules$ ls -l /usr/local/lib/luarocks/rocks
total 16
drwxr-xr-x 3 root root 4096 Mar 17 11:13 lua-cjson
drwxr-xr-x 3 root root 4096 Mar 17 11:18 luasocket
-rw-r--r-- 1 root root 3653 Mar 17 11:18 manifest
drwxr-xr-x 3 root root 4096 Mar 17 11:18 redis-lua

embedding mono sample: error while loading shared libraries: libmonoboehm-2.0.so.1

i've installed mono on centos 6 via make && make install from source
when i tried this sample:
https://github.com/mono/mono/blob/master/samples/embed/teste.c
no error occured during the compilation, but when i run i got this:
[root#WOH_Test t01]# gcc -o teste teste.c `pkg-config --cflags --libs mono-2` -lm
[root#WOH_Test t01]# mcs test.cs
[root#WOH_Test t01]# ./teste test.exe
./teste: error while loading shared libraries: libmonoboehm-2.0.so.1: cannot open shared object file: No such file or directory
i can't figure where the problem is, any clue?
What do you have in /usr/local/lib? If you didn't use the --prefix option while running autogen.sh before the command make the libraries should be localed in /usr/local/lib. You should see in that directory something like this:
me#mypc:/usr/local/lib$ ls -lah libmono-2.0.*
lrwxrwxrwx. 1 me me 18 dic 19 00:38 libmono-2.0.a -> libmonoboehm-2.0.a
lrwxrwxrwx. 1 me me 19 dic 19 00:38 libmono-2.0.la -> libmonoboehm-2.0.la
lrwxrwxrwx. 1 me me 19 dic 19 00:38 libmono-2.0.so -> libmonoboehm-2.0.so
lrwxrwxrwx. 1 me me 21 dic 19 00:38 libmono-2.0.so.1 -> libmonoboehm-2.0.so.1
lrwxrwxrwx. 1 me me 25 dic 19 00:38 libmono-2.0.so.1.0.0 -> libmonoboehm-2.0.so.1.0.0
If you can see the above libraries in /usr/local/lib your problem is related to where is ld searching for libraries. From this question: CentOS /usr/local/lib system wide $LD_LIBRARY_PATH I guess Centos6 does not have by default configuration for /usr/local/lib. If it is your case, just use the provided solutions in that question (any of them) and your program should work fine.
EDIT
From your comment if you want libmonoboehm-2.0.so.1 in the same path as the teste program and you do not want to touch anything else in your Centos6 you could do something like the following:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/teste/binary
./teste test.exe
But I wonder what output do you have when you run this command: pkg-config --cflags --libs mono-2 (it seems as if you already had a mono installation in your Centos6)
Anyhow, if you can modify your Centos6 the best is this answer: CentOS /usr/local/lib system wide $LD_LIBRARY_PATH. You do that once and you will be able to run any mono program without having to mess with the LD_LIBRARY_PATH environment variable. In your case you should do the following:
1. Edit /etc/ld.so.conf
2. Write this: /opt/mono/lib
3. Run ldconfig -v as root
4. Your Centos6 is ready to run your mono programs whenever you wish (even if you restart your Centos6 machine)
END EDIT

LLVm clang , Error: Invalid file format (bad magic) with -fprofile-instr-use

Flag "-fprofile-instr-use" generates error given below.
This issue occurs even if we build llvm,clang and compiler-rt using cmake or configure.
Please let me know your inputs to resolve this issue
error: Could not read profile: Invalid file format (bad magic)
Thanks,
Steps to reproduce this issue:
$ clang -O2 -fprofile-instr-generate hello.c -o c1.out
$ ls -rlt
-rw-r--r-- 1 root root 70 Jul 11 10:10 hello.c
-rwxr-xr-x 1 root root 15793 Jul 11 10:10 c1.out
-rw-r--r-- 1 root root 12203204 Jul 11 10:10 gmon.out
$ ./c1.out
Hello world
$ ls -rlt
-rw-r--r-- 1 root root 70 Jul 11 10:10 hello.c
-rwxr-xr-x 1 root root 15793 Jul 11 10:10 c1.out
-rw-r--r-- 1 root root 12203204 Jul 11 10:10 gmon.out
-rw-r--r-- 1 root root 104 Jul 11 10:10 default.profraw
$ clang -O2 -fprofile-instr-use=default.profraw hello.c -o c2.out
error: Could not read profile: Invalid file format (bad magic)
1 error generated.
Clang version (July 10th-2014 build from stage):
$ clang -v
clang version 3.5.0 (llvm.org/git/clang.git 5f9d646cba20f309bb69c6c358996d71912c54cd) (llvm.org/git/llvm.git dc90a3ab8ffc841a442888940635306de6131d2f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;#m64
Candidate multilib: 32;#m32
Selected multilib: .;#m64
OS: Ubuntu 14.04
LLVM configure: ../llvm/configure --enable-profiling --enable-optimized --enable-shared --disable-debug-runtime --enable-targets=x86
It turns out that step 3 outlined here: http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
is required even if you only have 1 output file you are using. "Combine profiles from multiple runs and convert the “raw” profile format to the input expected by clang" makes it sound like you should only do this if you have multiple profiles, but you need to do it unconditionally.

libcurl Invalid ELF header in new Arch Install

So I just installed Arch and most things are working fine, but when I try to use pacman or curl, I get the error:
pacman: error while loading shared libraries: /usr/lib/libcurl.so.4: invalid ELF header
Also, I can't seem to run anything pacman-related for now... not even a pacman --help
Not sure if useful, but ls -l /usr/lib | grep libcurl gives:
-rw-r--r-- 1 root root 594016 Jun 22 12:21 libcurl.a
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so -> libcurl.so.4.3.0
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so.4 -> libcurl.so.4.3.0
-rwxr-xr-x 1 root root 408324 Jun 22 12:21 libcurl.s0.4.3.0
Thanks in advance!
Update: running ./curl-config gives the error, "cannot execute binary file". This makes me wonder if maybe I have a 64 bit version, whilst I'm running Arch i686. What is the best way to handle this?
maybe I have a 64 bit version, whilst I'm running Arch i686
That would do it. Run file ./curl-config. If it says ELF 64-bit LSB executable,... reinstall curl from correct packages.