Project

General

Profile

Bug #2739

Incorrect detection of the jit support of libpcre

Added by Armature Technologies about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Difficulty:

Description

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

History

#1 Updated by Victor Julien about 1 month ago

Thanks for your report. Are you interested in doing a pull request?

#2 Updated by Victor Julien about 1 month ago

  • Affected Versions deleted (4.0.7)

#3 Updated by Armature Technologies about 1 month ago

Victor Julien wrote:

Thanks for your report. Are you interested in doing a pull request?

Sure! We have a planned meeting in January with some of your core team members. We will surely have the time to squeeze in a discussion about the contribution agreement signature as a company. Once the paperwork done, we will submit the merge request.

Also available in: Atom PDF