Suricata

Hey,

We believe we discovered a detection error for the jit support in libpcre.
The consequence is that JIT is always considered enabled by Suricata, even if libpcre is not compiled with the JIT support. This can result in some problems including some unexpected interactions with the grsecurity patch, when Suricata tests support for RWX pages:

https://github.com/OISF/suricata/blob/fc395eb2c588bc1034311105247e7d44c384761f/src/detect-pcre.c#L146-L151

This bug was introduced in https://github.com/OISF/suricata/commit/3d396e8b1e79908e3f759ff297ebd3a939623914, back in September 2011 (!).

The test tries to detect the support of JIT, by compiling two small code snippets, then running one of them and testing the exit code.

https://github.com/OISF/suricata/blob/24806c21024e2f799e1cf4d0355e7e5e718224e3/configure.ac#L700-L707

https://github.com/OISF/suricata/blob/24806c21024e2f799e1cf4d0355e7e5e718224e3/configure.ac#L732-L750

Or, at least, that's the intention, because the AC_TRY_COMPILE autoconf macro is not used properly. Indeed, this macro only tests that the code snippet can compile, but it never links nor runs the resulting program. We can confirm that if the resulting program was run, the code snippet would successfully test the JIT support.

Thus, Suricata configure.ac only tests that the JIT symbols exist in the libpcre library. Unfortunately, even when libpcre is not compiled to support JIT, the symbols seems to be available. This causes Suricata to incorrectly assume JIT support for libpcre.

We believe the correct way of testing would be to use a construct like this one:

AC_RUN_IFELSE(
    AC_LANG_PROGRAM(
        [ #include<pcre.h> ],
        [ the code snippets that are already in configure.ac ]
    ), [ pcre_jit_works=yes ], [:]
)

Just patching between line 732 and 750 would NOT be enough, though, because this test result could contradict the result obtained by the code at lines 700-707. Thus, the code between 700 and 707 should also be modified.

Cheers,
Armature Technologies Dev Team