Support #3415
closedSuricata 5.0.1 broken (undefined symbol: htp_connp_req_close)
Description
Suricata 5.0.1 seems to be broken, throwing the following error message:
suricata: symbol lookup error: suricata: undefined symbol: htp_connp_req_close
Installation:
git clone https://github.com/OISF/suricata.git cd suricata git clone https://github.com/OISF/libhtp cd libhtp sh autogen.sh cd .. ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-luajit --enable-geoip make sudo make install
Start Suricata:
/usr/bin/suricata -c /etc/suricata/suricata.yaml
Suricata does not start:
/usr/bin/suricata: symbol lookup error: /usr/bin/suricata: undefined symbol: htp_connp_req_close
OS: Ubuntu 18.04.3 LT
Updated by Roman Gugelhupf almost 6 years ago
Not sure, but maybe this problem is related to the latest libhtp commit?
Can anyone verify this?
Updated by Victor Julien almost 6 years ago
What is the output of 'ldd /usr/bin/suricata' ?
Updated by Victor Julien almost 6 years ago
- Priority changed from Urgent to Normal
Updated by Roman Gugelhupf almost 6 years ago
$ ldd /usr/bin/suricata
linux-vdso.so.1 (0x00007ffc76fda000)
libhtp.so.2 => /usr/local/lib/libhtp.so.2 (0x00007f5dd1fcc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5dd1dc8000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5dd1bc0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5dd1822000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f5dd1606000)
libmaxminddb.so.0 => /usr/lib/x86_64-linux-gnu/libmaxminddb.so.0 (0x00007f5dd1400000)
libluajit-5.1.so.2 => /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2 (0x00007f5dd1187000)
libmagic.so.1 => /usr/lib/x86_64-linux-gnu/libmagic.so.1 (0x00007f5dd0f65000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f5dd0d60000)
libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f5dd0b1f000)
libnet.so.1 => /usr/lib/x86_64-linux-gnu/libnet.so.1 (0x00007f5dd0905000)
libjansson.so.4 => /usr/lib/x86_64-linux-gnu/libjansson.so.4 (0x00007f5dd06f7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5dd04d8000)
libyaml-0.so.2 => /usr/lib/x86_64-linux-gnu/libyaml-0.so.2 (0x00007f5dd02ba000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f5dd0048000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5dcfe2b000)
libhs.so.4 => /usr/lib/x86_64-linux-gnu/libhs.so.4 (0x00007f5dcf326000)
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x00007f5dcefe2000)
libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x00007f5dceda5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5dceb8d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5dce79c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5dd2968000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5dce413000)
libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x00007f5dce1e4000)
libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x00007f5dcdfdf000)
libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x00007f5dcdddb000)
Updated by Victor Julien almost 6 years ago
libhtp is taken from /usr/local:
libhtp.so.2 => /usr/local/lib/libhtp.so.2 (0x00007f5dd1fcc000)
The new libhtp should have been installed in /usr/lib instead. Can you check if there is a more recent libhtp there? I suspect the /usr/local/lib version is a left over from an older install. If you remove that, it should pick up the correct one.
Updated by Roman Gugelhupf almost 6 years ago
Thanks Victor. I've removed /usr/local/lib/libhtp*, re-compiled it and it seems to work now. However, I'm a bit confused because my unterstanding was that suricata would take the bundled libhtp version:
Non-bundled htp: no
So, --enable-non-bundled-htp would take the libhtp version that is currently installed by the system, while per default suricata uses the one that is bundled. No?
Updated by Victor Julien almost 6 years ago
During compilation this is how it works. After Suricata is installed however, it will use the libhtp from your library paths (configured in ld.so.conf). I think in your case /usr/local/lib took precedence over /usr/lib.
Not sure if we can lock the path at which suri looks for libhtp somehow.
Updated by Roman Gugelhupf almost 6 years ago
Ok, thanks Victor for your assistance!
Updated by Victor Julien almost 6 years ago
- Tracker changed from Bug to Support
- Status changed from New to Closed
You're welcome!