Fixed in Cauldron in suricata-2.0.6-1.mga5.

Version: Cauldron => 4
Blocks: 14674 => (none)
Whiteboard: MGA4TOO => (none)

Yet another security issue in libhtp was discovered and fixed.  Looking at Fedora's suricata git, apparently it's called CVE-2015-0928 and is fixed in suricata 2.0.7, which Fedora has updated to in git (update hasn't been released yet).  They've also backported a patch for libhtp in Fedora 20 again:
http://pkgs.fedoraproject.org/cgit/libhtp.git/commit/?h=f20&id=fae73e709ff18e0da02328d0ddbbf207418ac286

Fedora has issued an advisory for this on February 18:
https://lists.fedoraproject.org/pipermail/package-announce/2015-February/150472.html

Blocks: (none) => 14674
Summary: suricata new security issue in embedded libhtp => suricata new security issues in embedded libhtp (including CVE-2015-0928)

RedHat bug for the new issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1190864

suricata-2.0.7-1.mga5 uploaded for Cauldron.  Thanks Guillaume :o)

Version: Cauldron => 4
Blocks: 14674 => (none)
Whiteboard: MGA4TOO => (none)

LWN reference for CVE-2015-0928:
http://lwn.net/Vulnerabilities/636683/

suricata-1.4.7-1.1.mga4 has been submitted in update/testing for mageia 4 since 2015-03-01.

(In reply to Guillaume Rousse from comment #6)
> suricata-1.4.7-1.1.mga4 has been submitted in update/testing for mageia 4
> since 2015-03-01.

It only contains a patch for the first of the two issues mentioned in this bug.

The code in the old embedded libhtp looks very different.
Looking into it, connp->out_tx->response_content_encoding can only be set to COMPRESSION_GZIP if connp->out_decompressor is not NULL:

            connp->out_decompressor = (htp_decompressor_t *) htp_gzip_decompressor_create(connp);
            if (connp->out_decompressor != NULL) {
                connp->out_tx->response_content_encoding = COMPRESSION_GZIP;
                connp->out_decompressor->callback = htp_connp_RES_BODY_DECOMPRESSOR_CALLBACK;
            } 

The patch checks that both out_decompressor is not NULL and out_decompressor->decompress (the function pointer) is not NULL.

I don't see how the second one could be NULL is the first one is not as it is a field in the struct that is always set to point to a function (htp_gzip_decompressor_decompress) if the first allocation had succeeded.

So I think CVE-2015-0928 does not apply to the old version which is embedded.

Thanks Pascal!

Advisory:
========================

Updated suricata packages fix security vulnerability:

It was reported that libhtp handling of streams in error state could lead to
NULL pointer dereference, leading to caller crash. Suricata (Intrusion
Detection System) embeds libhtp, and is one of the affected components.

References:
https://github.com/OISF/libhtp/pull/82
https://redmine.openinfosecfoundation.org/issues/1272
https://lists.fedoraproject.org/pipermail/package-announce/2015-January/148322.html
========================

Updated packages in core/updates_testing:
========================
suricata-1.4.7-1.1.mga4
libhtp0.2-1.4.7-1.1.mga4
libhtp-devel-1.4.7-1.1.mga4

from suricata-1.4.7-1.1.mga4.src.rpm

CC: (none) => guillomovitch
Assignee: guillomovitch => qa-bugs

Sorry for this long comment, as I did not find any testing procedure for suricata, I put it down here for it to be reviewed by more expert testers.

Testing on Mageia 4x64, real hardware

From current packages :
- - - - - - - - - - -

suricata-1.4.7-1.mga4
lib64htp0.2-1.4.7-1.mga4

Configured suricata.yaml :
------------------------
#nano /etc/suricata/suricata.yaml

Added in "linux" my lan IPs (192.168.0.10/20)

# Make the default policy windows.
  windows: [0.0.0.0/0]
  bsd: []
  bsd-right: []
  old-linux: []
  linux: [10.0.0.0/8,192.168.0.10/20, 192.168.1.100, "8762:2352:6241:7245:E00$
  old-solaris: []
  solaris: ["::1"]
  hpux10: []
  hpux11: []
  irix: []
  macos: []
  vista: []
  windows2k3: []
  
Verified address-groups had my lan IPs in HOME_NET but not the machine which I would later use to ping suricata (192.168.0.18) :

address-groups:

    HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"

Gave the good path to magic-file :

# Magic file. The extension .mgc is added to the value here.
#magic-file: /usr/share/file/magic
magic-file: /usr/share/misc/magic.mgc

(the .mgc extension was missing)


From /etc/suricata, downloaded some rules for suricata :
------------------------------------------------------
As I could not find rules in mageia package, nor classification.config and reference.config that suricata requires, I downloaded some :

# cd /etc/suricata
# curl -O https://rules.emergingthreatspro.com/open/suricata/emerging.rules.tar.gz
# tar xzvf emerging.rules.tar.gz
# ln -s /etc/suricata/rules/reference.config /etc/suricata/reference.config
# ln -s /etc/suricata/rules/classification.config /etc/suricata/classification.config

In /etc/suricata/rules, added a test rule :
-----------------------------------------
# nano test.rules
alert ip any any -> any any (msg:"ICMP detected"; sid:2; rev:1;)
To be able to test ping.

Added that rule in suricata.yaml at the end of section rule-files :

# nano /etc/suricata/suricata.yaml

# Set the default rule path here to search for the files.
# if not set, it will look at the current working dir
default-rule-path: /etc/suricata/rules
rule-files:
 - botcc.rules
 - ciarmy.rules
(...)
 - smtp-events.rules    # available in suricata sources under rules dir
 - test.rules

Finally, launched suricata on my network interface (enp3s0)
-----------------------------------------------------------
# suricata -c /etc/suricata/suricata.yaml -i enp3s0
23/3/2015 -- 23:41:47 - <Info> - This is Suricata version 1.4.7 RELEASE
23/3/2015 -- 23:41:47 - <Info> - CPUs/cores online: 4
23/3/2015 -- 23:41:47 - <Info> - Found an MTU of 1500 for 'enp3s0'
(...)
23/3/2015 -- 23:42:09 - <Info> - all 7 packet processing threads, 3 management threads initialized, engine started.

There were some warnings and an error about some rules but suricata was running.

From another machine in my virtual lan, pinged suricata host machine :
--------------------------------------------------------------------

$ ping -c 3 192.168.0.11

And in host, verified I could find these pings in /var/log/suricata/fast.log :

03/23/2015-23:47:00.767905  [**] [1:2:1] ICMP detected [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.0.18:8 -> 192.168.0.11:0
03/23/2015-23:47:00.767944  [**] [1:2:1] ICMP detected [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.0.11:0 -> 192.168.0.18:0
03/23/2015-23:47:01.767750  [**] [1:2:1] ICMP detected [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.0.18:8 -> 192.168.0.11:0
03/23/2015-23:47:01.767781  [**] [1:2:1] ICMP detected [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.0.11:0 -> 192.168.0.18:0
03/23/2015-23:47:02.766920  [**] [1:2:1] ICMP detected [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.0.18:8 -> 192.168.0.11:0
03/23/2015-23:47:02.766953  [**] [1:2:1] ICMP detected [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.0.11:0 -> 192.168.0.18:0


Did the same with updated testing packages :
- - - - - - - -- - - - - - - - - - - - - - 

suricata-1.4.7-1.1.mga4
lib64htp0.2-1.4.7-1.1.mga4

Which seemed to work fine.

I don't know if that is a proper test or if it is enough, so I do not OK it myself.

CC: (none) => olchal

Adding the OK for comment 10 testing. Well done for finding your way through that Olivier!

Whiteboard: (none) => has_procedure mga4-64-ok

validating. advisory uploaded.

Keywords: (none) => validated_update
Whiteboard: has_procedure mga4-64-ok => has_procedure mga4-64-ok advisory
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2015-0135.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED

LWN created this duplicate entry.  I let them know, so they should combine it with the one in the URL:
http://lwn.net/Vulnerabilities/639969/