Project

General

Profile

Bug #2739

Incorrect detection of the jit support of libpcre

Added by Armature Technologies 6 months ago. Updated 23 days ago.

Status:
New
Priority:
Normal
Target version:
Difficulty:
Label:

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 6 months ago

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

#2

Updated by Victor Julien 6 months ago

  • Affected Versions deleted (4.0.7)
#3

Updated by Armature Technologies 6 months 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.

#4

Updated by Victor Julien 4 months ago

Friendly ping.

#5

Updated by Andreas Herz 23 days ago

  • Assignee set to Community Ticket
  • Target version set to TBD

Did you have time to discuss this in your company?

#6

Updated by Armature Technologies 23 days ago

Andreas Herz wrote:

Did you have time to discuss this in your company?

I am hearing that we are still struggling to sign the legal papers with the OISF :(
That's unfortunate.

Also available in: Atom PDF