Bug#819050: Please leave the severity at serious, this bug is a security issue.
Hi Hilko,
On Fri, Mar 25, 2016 at 07:48:42PM +0100, Hilko Bengen wrote:
> * Salvatore Bonaccorso:
>
> > Can you confirm that the packages at
> > https://people.debian.org/~carnil/tmp/pcre3/jessie/ fix as well the
> > case reported in #819050? The package at above link contain the
> > proposed fixes which I submitted for the next Jessie point release and
> > on top of it r1475 commit from upstream.
>
> After installing libpcre3_8.35-3.3+deb8u3_amd64.deb, pcregrep no longer
> crashes. Thank you very much.
>
> > Can you otherwise provide a complete test case for #819050?
>
> It turns out that this regex does not crash pcre on just any input. The
> following line reproduces the bug for me using an with unpatched
> libpcre3. Is this good enough?
>
> echo /a/eaa | pcregrep
> '\/(?:(?:s(?:ystem\/(?:logs|engine)\/[^\x2f]+?|e(?:rv(?:au|er)|ct)|gau\/.*?|alam|ucks|can|ke)|p(?:lugins\/content\/vote\/\.ssl\/[a-z0-9]|(?:rogcicic|atr)ic|osts?\/[a-z0-9]+)|(?=[a-z]*[0-9])(?=[0-9]*[a-z])(?!setup\d+\.exe$)[a-z0-9]{5,10}|a(?:d(?:min\/images\/\w+|obe)|(?:sala|kee)m|live)|(?:i(?:mage\/flags|nvoice)|xml\/load)\/[^\x2f]+|d(?:o(?:c(?:\/[a-z0-9]+)?|ne)|bust)|m(?:edia\/files\/\w+|arch)|~.+?\/\.[^\x2f]+\/.+?|c(?:onfig|hris|alc)|u(?:swinz\w+|pdate)|Ozonecrytedserver|w(?:or[dk]|insys)|fa(?:cture|soo)|n(?:otepad|ach)|k(?:be|ey|is)|(?:tes|ve)t|ArfBtxz|office|yhaooo|[a-z]|etna|link|\d+)\.exe$|(?:(?=[a-z0-9]*?[3456789][a-z0-9]*?[3456789])(?=[a-z0-9]*?[h-z])[a-z0-9]{3,31}\+|PasswordRecovery|RemoveWAT|Dejdisc|Host\d+|Msword)\.exe)'
Thanks for the testcase, this helps!
I think I will propose the attached debdiff for the SRM, to fix this
case (separate debdiff, since +deb8u3 was already acceted by Adam just
some minutes ago).
But I suspect there is more. Florian suggested/mentioned in his first
reply, if possibly suricata should not explicitly enable the PCRE JIT
compiler at least in jessie.
Regards,
Salvatore
diff -Nru pcre3-8.35/debian/changelog pcre3-8.35/debian/changelog
--- pcre3-8.35/debian/changelog 2016-03-25 17:34:14.0 +0100
+++ pcre3-8.35/debian/changelog 2016-03-25 19:58:37.0 +0100
@@ -1,3 +1,11 @@
+pcre3 (2:8.35-3.3+deb8u4) jessie; urgency=medium
+
+ * Non-maintainer upload.
+ * Add 0001-Fixed-an-issue-with-nested-table-jumps.patch.
+Fixes issue with nested table jumps. (Closes: #819050)
+
+ -- Salvatore Bonaccorso Fri, 25 Mar 2016 19:58:10 +0100
+
pcre3 (2:8.35-3.3+deb8u3) jessie; urgency=medium
* Non-maintainer upload.
diff -Nru
pcre3-8.35/debian/patches/0001-Fixed-an-issue-with-nested-table-jumps.patch
pcre3-8.35/debian/patches/0001-Fixed-an-issue-with-nested-table-jumps.patch
--- pcre3-8.35/debian/patches/0001-Fixed-an-issue-with-nested-table-jumps.patch
1970-01-01 01:00:00.0 +0100
+++ pcre3-8.35/debian/patches/0001-Fixed-an-issue-with-nested-table-jumps.patch
2016-03-25 19:58:37.0 +0100
@@ -0,0 +1,102 @@
+Description: Fixed an issue with nested table jumps
+Origin: upstream, http://vcs.pcre.org/pcre?view=revision=1475
+Bug-Debian: https://bugs.debian.org/819050
+Forwarded: not-needed
+Author: Zoltan Herczeg
+Reviewed-by: Salvatore Bonaccorso
+Last-Update: 2016-03-25
+Applied-Upstream: 8.36
+---
+
+--- a/pcre_jit_compile.c
b/pcre_jit_compile.c
+@@ -200,7 +200,7 @@ typedef struct stub_list {
+
+ typedef struct label_addr_list {
+ struct sljit_label *label;
+- sljit_uw *addr;
++ sljit_uw *update_addr;
+ struct label_addr_list *next;
+ } label_addr_list;
+
+@@ -2070,7 +2070,7 @@ while (list_item)
+ common->stubs = NULL;
+ }
+
+-static void add_label_addr(compiler_common *common)
++static void add_label_addr(compiler_common *common, sljit_uw *update_addr)
+ {
+ DEFINE_COMPILER;
+ label_addr_list *label_addr;
+@@ -2079,10 +2079,9 @@ label_addr = sljit_alloc_memory(compiler
+ if (label_addr == NULL)
+ return;
+ label_addr->label = LABEL();
+-label_addr->addr = common->read_only_data_ptr;
++label_addr->update_addr = update_addr;
+ label_addr->next = common->label_addrs;
+ common->label_addrs = label_addr;
+-common->read_only_data_ptr++;
+ }
+
+ static SLJIT_INLINE void count_match(compiler_common *common)
+@@ -8819,6 +8818,7 @@ pcre_uchar *ccprev;
+ pcre_uchar bra = OP_BRA;
+ pcre_uchar ket;
+ assert_backtrack *assert;
++sljit_uw *next_update_addr;
+ BOOL has_alternatives;
+ BOOL needs_control_head = FALSE;
+ struct sljit_jump *brazero = NULL;
+@@ -8988,8 +8988,10 @@ else if (has_alternatives)
+ if (alt_max > 4)
+ {
+ /* Table jump if alt_max is greater than 4. */
+-sljit_emit_ijump(compiler, SLJIT_JUMP, SLJIT_MEM1(TMP1),
(sljit_sw)common->read_only_data_ptr);
+-add_label_addr(common);
++next_update_addr = common->read_only_data_ptr;
++common->read_only_data_ptr += alt_max;
++sljit_emit_ijump(compiler, SLJIT_JUMP, SLJIT_MEM1(TMP1),
(sljit_sw)next_update_addr);
++add_label_addr(common, next_update_addr++);
+ }
+ else
+ {
+@@ -9121,7 +9123,7 @@ if
Bug#819050: Please leave the severity at serious, this bug is a security issue.
* Salvatore Bonaccorso:
> Can you confirm that the packages at
> https://people.debian.org/~carnil/tmp/pcre3/jessie/ fix as well the
> case reported in #819050? The package at above link contain the
> proposed fixes which I submitted for the next Jessie point release and
> on top of it r1475 commit from upstream.
After installing libpcre3_8.35-3.3+deb8u3_amd64.deb, pcregrep no longer
crashes. Thank you very much.
> Can you otherwise provide a complete test case for #819050?
It turns out that this regex does not crash pcre on just any input. The
following line reproduces the bug for me using an with unpatched
libpcre3. Is this good enough?
echo /a/eaa | pcregrep
'\/(?:(?:s(?:ystem\/(?:logs|engine)\/[^\x2f]+?|e(?:rv(?:au|er)|ct)|gau\/.*?|alam|ucks|can|ke)|p(?:lugins\/content\/vote\/\.ssl\/[a-z0-9]|(?:rogcicic|atr)ic|osts?\/[a-z0-9]+)|(?=[a-z]*[0-9])(?=[0-9]*[a-z])(?!setup\d+\.exe$)[a-z0-9]{5,10}|a(?:d(?:min\/images\/\w+|obe)|(?:sala|kee)m|live)|(?:i(?:mage\/flags|nvoice)|xml\/load)\/[^\x2f]+|d(?:o(?:c(?:\/[a-z0-9]+)?|ne)|bust)|m(?:edia\/files\/\w+|arch)|~.+?\/\.[^\x2f]+\/.+?|c(?:onfig|hris|alc)|u(?:swinz\w+|pdate)|Ozonecrytedserver|w(?:or[dk]|insys)|fa(?:cture|soo)|n(?:otepad|ach)|k(?:be|ey|is)|(?:tes|ve)t|ArfBtxz|office|yhaooo|[a-z]|etna|link|\d+)\.exe$|(?:(?=[a-z0-9]*?[3456789][a-z0-9]*?[3456789])(?=[a-z0-9]*?[h-z])[a-z0-9]{3,31}\+|PasswordRecovery|RemoveWAT|Dejdisc|Host\d+|Msword)\.exe)'
Cheers,
-Hilko
Bug#819050: Please leave the severity at serious, this bug is a security issue.
Hi all, On Fri, Mar 25, 2016 at 08:18:34AM +0100, Pierre Chifflier wrote: > On 03/24/2016 09:38 AM, Yves-Alexis Perez wrote: > > control: affects -1 suricata > > On jeu., 2016-03-24 at 07:20 +0100, Florian Weimer wrote: > >> * Hilko Bengen: > >> > >>> > >>> the original report may not have been 100% clear on this, but the bug is > >>> the main cause of a vulnerability in Suricata (a network IDS/IPS) that > >>> allows for remote denial of service, possibly remote code execution by > >>> simply passing crafted packets by a Suricata installation. > >> Without the complete test case, that's hard to tell. > >> > >> If we cannot reproduce this, perhaps Suricata (at least in stable) > >> should not explicitly enable the PCRE JIT compiler? > > > > Adding Pierre (Suricata maintainer) to the loop then. > > > > Hi, > > Is it the same bug on PCRE that was reported last year ? If so, I have > confirmed that it is reproducible in a mail to security@ > (<564c6de1.9000...@debian.org>) > The bug is in libpcre, see > https://lists.exim.org/lurker/message/20140425.115921.793bec64.en.html > for details, and > http://vcs.pcre.org/pcre?view=revision=1475 > for the upstream fix. > > It indeed affects programs using the JIT feature, that includes suricata. Can you confirm that the packages at https://people.debian.org/~carnil/tmp/pcre3/jessie/ fix as well the case reported in #819050? The package at above link contain the proposed fixes which I submitted for the next Jessie point release and on top of it r1475 commit from upstream. Can you otherwise provide a complete test case for #819050? Regards, Salvatore signature.asc Description: PGP signature
Bug#819050: Please leave the severity at serious, this bug is a security issue.
On 03/24/2016 09:38 AM, Yves-Alexis Perez wrote: > control: affects -1 suricata > On jeu., 2016-03-24 at 07:20 +0100, Florian Weimer wrote: >> * Hilko Bengen: >> >>> >>> the original report may not have been 100% clear on this, but the bug is >>> the main cause of a vulnerability in Suricata (a network IDS/IPS) that >>> allows for remote denial of service, possibly remote code execution by >>> simply passing crafted packets by a Suricata installation. >> Without the complete test case, that's hard to tell. >> >> If we cannot reproduce this, perhaps Suricata (at least in stable) >> should not explicitly enable the PCRE JIT compiler? > > Adding Pierre (Suricata maintainer) to the loop then. > Hi, Is it the same bug on PCRE that was reported last year ? If so, I have confirmed that it is reproducible in a mail to security@ (<564c6de1.9000...@debian.org>) The bug is in libpcre, see https://lists.exim.org/lurker/message/20140425.115921.793bec64.en.html for details, and http://vcs.pcre.org/pcre?view=revision=1475 for the upstream fix. It indeed affects programs using the JIT feature, that includes suricata. Cheers, Pierre
Bug#819050: Please leave the severity at serious, this bug is a security issue.
control: affects -1 suricata On jeu., 2016-03-24 at 07:20 +0100, Florian Weimer wrote: > * Hilko Bengen: > > > > > the original report may not have been 100% clear on this, but the bug is > > the main cause of a vulnerability in Suricata (a network IDS/IPS) that > > allows for remote denial of service, possibly remote code execution by > > simply passing crafted packets by a Suricata installation. > Without the complete test case, that's hard to tell. > > If we cannot reproduce this, perhaps Suricata (at least in stable) > should not explicitly enable the PCRE JIT compiler? Adding Pierre (Suricata maintainer) to the loop then. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#819050: Please leave the severity at serious, this bug is a security issue.
* Hilko Bengen: > the original report may not have been 100% clear on this, but the bug is > the main cause of a vulnerability in Suricata (a network IDS/IPS) that > allows for remote denial of service, possibly remote code execution by > simply passing crafted packets by a Suricata installation. Without the complete test case, that's hard to tell. If we cannot reproduce this, perhaps Suricata (at least in stable) should not explicitly enable the PCRE JIT compiler? I'm not sure if we can keep rebasing PCRE just to fix JIT compiler issues.
Bug#819050: Please leave the severity at serious, this bug is a security issue.
control: tag -1 security control: severity -1 serious Hi Matthew, the original report may not have been 100% clear on this, but the bug is the main cause of a vulnerability in Suricata (a network IDS/IPS) that allows for remote denial of service, possibly remote code execution by simply passing crafted packets by a Suricata installation. Cheers, -Hilko
