Bug 25956 - suricata new security issue(s) fixed upstream in 4.1.5
Summary: suricata new security issue(s) fixed upstream in 4.1.5
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2019-12-26 04:13 CET by David Walser
Modified: 2020-01-19 11:12 CET (History)
4 users (show)

See Also:
Source RPM: suricata-4.1.4-2.mga7.src.rpm
Status comment:


Description David Walser 2019-12-26 04:13:35 CET
Upstream has released Suricata 4.1.5 on September 24:

Some of the issues fixed are security issues (though it doesn't identify which).

They also made bugfix release 4.1.6 on December 13:

Fedora has issued an advisory for this on October 8:
Comment 1 Guillaume Rousse 2020-01-04 22:17:26 CET
I don't see any security issue, nor anything else worth an update here, closing.

Resolution: (none) => WONTFIX

Comment 2 David Walser 2020-01-05 02:26:59 CET
The upstream announcement explicitly says that some of the fixes are security fixes, even if they didn't go out of their way to identify what those are.  I don't see why we can't update it.
Comment 3 r howard 2020-01-05 03:38:08 CET
There are definitely security fixes in sericata 4.1.6. For example https://suricata-ids.org/2019/12/13/suricata-4-1-6-released/ lists a number of security fixes. For example it mentions fixes for:
Bug #3394: TCP evasion technique by overlapping a TCP segment with a fake packet (4.1.x)
Bug #3395: TCP evasion technique by faking a closed TCP session (4.1.x)

By the way sericata 5.0.1 was recently released and is the current stable release. sericata 4.1.6 is considered to be the old stable release.

CC: (none) => rihoward1

Comment 4 David Walser 2020-01-05 04:51:14 CET
Thanks.  Mageia 7 is on the old stable 4.1.x branch, so I'm sure it'll stay there.

Resolution: WONTFIX => (none)

Comment 5 Guillaume Rousse 2020-01-05 09:32:12 CET
False negatives aren't security issues, just bugs. Anyway, I won't lose time myself here, feel free to provide an update if you want.
Comment 6 David Walser 2020-01-05 19:46:25 CET
Guillaume, Fedora adds some security-related options to the systemd service file.  It might be worth taking a look at for Cauldron.  I've got the Mageia 7 update handled.
Comment 7 David Walser 2020-01-05 19:52:19 CET

Updated suricata packages fix security vulnerabilities:

The suricata package has been updated to version 4.1.6, which fixes security
issues and other bugs.  See the upstream announcements for details.


Updated packages in core/updates_testing:

from suricata-4.1.6-1.mga7.src.rpm

Assignee: guillomovitch => qa-bugs

Comment 8 Len Lawrence 2020-01-17 12:38:28 CET
Having a look at this.  There is a lot of background reading to do so it could take a while.  If it goes nowhere shall throw it back.

CC: (none) => tarazed25

Comment 9 Len Lawrence 2020-01-17 22:10:40 CET
Mageia7, x86_64

Installed suricata packages then updated them.
Modified the /etc/suricata/suricata.yaml file according to instructions at https://suricata.readthedocs.io/en/suricata-5.0.1/quickstart.html and ran
# suricata-update
to get the ET Open ruleset.
That failed because module pyyaml was needed.
Installed python-yaml and tried again.  That succeeded in loading the ruleset into /var/lib/suricata/rules/.
Should python-yaml be added as a dependency?

# systemctl enable suricata
# systemctl start suricata
# systemctl status suricata
● suricata.service - Suricata Intrusion Detection Service
   Loaded: loaded (/usr/lib/systemd/system/suricata.service; enabled; vendor pr>
   Active: failed (Result: exit-code) since Fri 2020-01-17 20:49:00 GMT; 9s ago
  Process: 23991 ExecStart=/sbin/suricata -c /etc/suricata/suricata.yaml $OPTIO>
 Main PID: 23991 (code=exited, status=1/FAILURE)

# tail /var/log/suricata/suricata.log
17/1/2020 -- 20:49:00 - <Notice> - This is Suricata version 4.1.6 RELEASE
17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19)
17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19)
17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /var/lib/suricata/rules/suricata.rules
17/1/2020 -- 20:49:00 - <Warning> - [ERRCODE: SC_ERR_NO_RULES_LOADED(43)] - 1 rule files specified, but no rule was loaded at all!

In suricata.yaml eth0 is enp3s0.  The log implies that no rule file can be found.  There is a suricata.rules in /var/lib/suricata and no other.  All the other rules files live in /etc/suricata/rules

The tutorial does not  give any help at this stage.  It expects the commands to work.  So there is something missing - no idea what.  Off to cogitate.
Comment 10 Len Lawrence 2020-01-18 11:00:03 CET
The update command (comment 9) placed a new directory /var/lib/suricata/update and a cache subdirectory in that containing a tar.gz file with dozens of "emerging" rules in it.  Don't know what to do with that.  Copy them to the rules directory?
Comment 11 David Walser 2020-01-18 16:22:09 CET
It does look like a python-yaml dependency should be added.  Does using documentation for the correct version help figure out what to do with it?
Comment 12 Len Lawrence 2020-01-18 17:20:18 CET
Thanks for the link David.  No quickstart guide but there are commandline options as root.

# suricata -T
18/1/2020 -- 15:40:09 - <Info> - Running suricata under test mode
18/1/2020 -- 15:40:09 - <Notice> - This is Suricata version 4.1.6 RELEASE
18/1/2020 -- 15:40:22 - <Notice> - Configuration provided was successfully loaded. Exiting.

Made sure that suricata was not running and started it in daemon mode but not using systemd.
# suricata -D -i enp3s0
18/1/2020 -- 15:50:15 - <Notice> - This is Suricata version 4.1.6 RELEASE
In another terminal:
# ps aux | grep suricata
root     11557  6.7  1.0 1223188 330156 ?      Ssl  15:50   0:15 suricata -D -i enp3s0
# cat /var/run/suricata.pid
# suricata --dump-config
mpipe.stack.size10386 = 0
mpipe.stack.size16384 = 0
default-rule-path = /var/lib/suricata/rules
rule-files = (null)
rule-files.0 = suricata.rules
classification-file = /etc/suricata/classification.config
reference-config-file = /etc/suricata/reference.config
# ls /var/lib/suricata/rules
# ls /etc/suricata/
classification.config  rules/         suricata.yaml.rpmnew
# tail /var/log/suricata/suricata.log
18/1/2020 -- 15:50:15 - <Notice> - This is Suricata version 4.1.6 RELEASE
18/1/2020 -- 15:50:28 - <Notice> - all 8 packet processing threads, 4 management threads initialized, engine started.

That all seems to hang together but no clue as to how to proceed from there.

# head /var/log/suricata/stats.log
Date: 1/18/2020 -- 15:45:05 (uptime: 0d, 00h 00m 21s)

That quotes a time earlier than the current invocation - probably not important.
Continues with a long list of attributes and their values.

I would guess that it is working but am unable to go any further with the tests.
Comment 13 Len Lawrence 2020-01-18 17:23:47 CET
Monitoring the log:-
# tail -f /var/log/suricata/fast.log
01/18/2020-15:45:12.929572  [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} ->
01/18/2020-16:00:09.934604  [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} ->
01/18/2020-16:03:20.092538  [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} ->
01/18/2020-16:11:29.420259  [**] [1:2012647:5] ET POLICY Dropbox.com Offsite File Backup in Use [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} ->

I do have a dropbox account.
Comment 14 Len Lawrence 2020-01-18 17:28:13 CET
Found this in the quickstart guide:

# curl http://testmyids.com/
uid=0(root) gid=0(root) groups=0(root)

The fast.log showed:
01/18/2020-16:24:39.699034  [**] [1:2013028:4] ET POLICY curl User-Agent Outbound [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} ->
01/18/2020-16:24:39.722979  [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} ->

Within the limits of my ignorance this appears to be working as expected so it gets a pass.

Whiteboard: (none) => MGA7-64-OK

Thomas Backlund 2020-01-19 10:24:12 CET

Keywords: (none) => advisory, validated_update
CC: (none) => tmb, sysadmin-bugs

Comment 15 Mageia Robot 2020-01-19 11:12:14 CET
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.