Modsecurity: configure flags that do not work or are missing

[drmuey]

Describe the bug

We have some libraries that are in non-standard locations we want to build with.

So for example, I can have --with-libxml=<PATH> and ./configure uses it correctly and make has it as well.

Other flags have issues:

1. --with-libcurl=… is ok in ./configure but then make does not have it and then fails w/ can’t find curl/curl.h even though the path output by configure does contain curl/curl.h
2. other things don’t have documented flags and when trying various incantations of --with-XYZ=… ./configure errors out about not knowing them.
   
   
   
   • the ones we want to specify are libnghttp2, brotli, and openssl 1.1
   
   

Logs and dumps

# ./configure --prefix=… --with-libxml=<LIBXML2 PATH> --with-curl=<CURL PATH> --with-brotli=<BROTLI PATH>`
…
configure: WARNING: unrecognized options: --with-brotli
…
   + LibCURL                                       ....found v7.71.1 
      -L<CURL PATH>/lib64 -lcurl, -I<CURL PATH>/include -DWITH_CURL_SSLVERSION_TLSv1_2 -DWITH_CURL
…
   + LibXML2                                       ....found v2.9.7
      -L<LIBXML2 PATH>/lib64 -lxml2 -lz -llzma -lm -ldl, -I<LIBXML2 PATH>/include/libxml2 -DWITH_LIBXML2
…
# make
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -std=c++11 -I.. -g -I../others -fPIC -O3 -I../headers -DWITH_GEOIP -I/usr/include/ -DWITH_YAJL -DPCRE_HAVE_JIT -I<LIBXML2 PATH>/include/libxml2 -DWITH_LIBXML2 -g -O2 -MT libmodsecurity_la-modsecurity.lo -MD -MP -MF .deps/libmodsecurity_la-modsecurity.Tpo -c modsecurity.cc  -fPIC -DPIC -o .libs/libmodsecurity_la-modsecurity.o
modsecurity.cc:29:23: fatal error: curl/curl.h: No such file or directory
 #include <curl/curl.h>
                       ^
compilation terminated.
make[3]: *** [libmodsecurity_la-modsecurity.lo] Error 1
…
# ls -l <CURL PATH>/include/curl/curl.h
<CURL PATH>/include/curl/curl.h

_Notice:_ Be carefully to not leak any confidential information.

To Reproduce

Steps to reproduce the behavior:

1. ./configure --prefix=… --with-libxml=… --with-curl=…--with-brotli=…
2. make

Expected behavior

A clear and concise description of what you expected to happen.

custom curl path should work, other libraries it uses should have flags for custom paths

Server (please complete the following information):

• libModSecurity version (and connector): [e.g. ModSecurity v3.0.4 with nginx-connector N/A haven’t gotten that far yet]
• WebServer: N/A haven’t gotten that far yet
• OS (and distro): CentOS 7 and 8

Rule Set (please complete the following information):

• N/A haven’t gotten that far yet

Additional context

N/A

[zimmerle]

libModSecurity _configure_ script is meant to configure the build options for the libModSecurity only. Things that aren't dependencies or options for ModSecurity are labeled as unrecognized option. That is the case for the option --with-brotli. Internally, libModSecurity does not make usage of _brotoli_, therefore configure does not recognize it as a valid option. The same is also true for _libnghttp2_ and _libnghttp2_. You can get the full list of options and descriptions with ./configure --help.

The curl detection seems to be buggy indeed. Sometimes the detection of the library is based on the existence of a file, which is prone to errors. I will have a look.

[drmuey]

Thanks @zimmerle 👍

[drmuey]

looking a bit deeper on the non-curl ones:

If I ldd libmodsecurity.so.3.0.4 I get this:

C7:

• libcrypto.so.10 and libssl.so.10 comes from openssl-libs-1:1.0.2k
• indeed does not have nghttp or brotli

C8:

• has libcrypto.so.1.1 and libssl.so.1.1 from openssl-libs-1.1.1
• has libnghttp2.so.14 from libnghttp2
• has libbrotlidec.so.1 and libbrotlicommon.so.1 from brotli

So what we need is:

1. a way to build libmodsecurity w/ our own openssl ➜ looking more into that now (grep of ./configure --help and the source din’t indicate anything obvious)
   
   
   
   • are you aware of a way to do that by chance?
   
   
2. the C8 brotli/nghttp2 issue _may_ go away once we can specify our curl because it builds against them ➜ I will verify that once that bit is fixed 👍

[drmuey]

Actually I wonder if the openssl issue would go away too w/ the libcurl option being fixed since our libcurl also builds against our openssl 🤔

[zimmerle]

Yes, the _OpenSSL_ is a dependency that came from _libcurl_ the ldd is not only showing the dependencies form ModSecurity but also the dependencies of the dependencies. At run time, as the process resides in the same memory space, the _OpenSSL_ needs to be the same for ModSecurity, libcurl, and the webserver.

Compile with one version and use another one in run time can get you in unpredicted problems. That is also true for every other dependency.

[drmuey]

Yeah thanks, that is inline with me thinking that if --with-curl worked the rest would fall in place 👍

[zimmerle]

Can you paste here the content of the folder: <CURL PATH>/include ?

[drmuey]

Can you paste here the content of the folder: /include ?

you bet @zimmerle !

# ls -l include/
total 0
drwxr-xr-x 2 root root 159 Aug 18 13:20 curl
# ls -l include/curl/
total 220
-rw-r--r-- 1 root root 114460 Jul  8 00:36 curl.h
-rw-r--r-- 1 root root   3040 Jul  8 00:36 curlver.h
-rw-r--r-- 1 root root   3985 Jul  8 00:36 easy.h
-rw-r--r-- 1 root root   2074 Jul  8 00:36 mprintf.h
-rw-r--r-- 1 root root  17071 Jul  8 00:36 multi.h
-rw-r--r-- 1 root root   1344 Jul  8 00:36 stdcheaders.h
-rw-r--r-- 1 root root  19033 Jul  8 00:36 system.h
-rw-r--r-- 1 root root  42343 Jul  8 00:36 typecheck-gcc.h
-rw-r--r-- 1 root root   4491 Jul  8 00:36 urlapi.h
# 

[martinhsv]

Hi @drmuey ,

The configure file runs

curl-config --cflags

within whatever directory prefix you specified.

It is counting on the output of that to supply any -I that is necessary for compilation.

However, 'curl-config --cflags' may return a blank line if it doesn't think you need any special flags -- and if it is an irregular install of curl, then one can see how a problem might occur.

Would you mind running 'curl-config --cflags' to confirm that that seems to be your use case?

If it is, it shouldn't be too troublesome to add a bit of extra code to the configure script, to address that scenario.

[drmuey]

@martinhsv thanks! I think that is the problem.

When I rely on $PATH ➜ curl-config --cflags is empty, because its the system one

When I call the one from --with-curl=<CURL PATH> ➜

# <CURL PATH>/bin/curl-config --cflags
-I<CURL PATH>/include
#

So yeah looks like whatever calls curl-config --cflags needs to factor in --with-curl=… 👍