Project

General

Profile

Actions

Bug #2739

closed

Incorrect detection of the jit support of libpcre

Added by Gatewatcher Dev Team over 5 years ago. Updated 5 months ago.

Status:
Rejected
Priority:
Normal
Target version:
Affected Versions:
Effort:
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

Actions #1

Updated by Victor Julien over 5 years ago

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

Actions #2

Updated by Victor Julien over 5 years ago

  • Affected Versions deleted (4.0.7)
Actions #3

Updated by Gatewatcher Dev Team over 5 years 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.

Actions #4

Updated by Victor Julien about 5 years ago

Friendly ping.

Actions #5

Updated by Andreas Herz almost 5 years ago

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

Did you have time to discuss this in your company?

Actions #6

Updated by Gatewatcher Dev Team almost 5 years 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.

Actions #7

Updated by Victor Julien over 4 years ago

  • Affected Versions 4.1.1, 4.1.2, 4.1.3, 4.1.4, 5.0beta1, 4.1.5, 5.0rc1 added
  • Affected Versions deleted (4.0beta1, 4.0.0, 4.0.1, 3.2.5, 4.0.2/4.0.3, 4.0.4, 4.1beta1, 4.0.5, 4.1rc1, 4.1rc2, 4.0.6)
Actions #8

Updated by Philippe Antoine 5 months ago

  • Status changed from New to Rejected

suricata now uses libpcre2, feel free to open a new ticket if there is still a problem with libpcre2

Actions

Also available in: Atom PDF