Bug 3978

Hi, thanks for reporting this bug.
As there is no maintainer for this package I added the committers in CC.

(Please set the status to 'assigned' if you are working on it)

CC: (none) => arnaud.patard, dmorganec, guillomovitch, mageia, mageia, mageia, misc

Ping ?

Ping ?

What should we do with this?  The upstream commit to fix this is here:
http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=1ca6cc236d1dabf1633238b873fb1c057e52f95e

Should we patch this, or update to newest stable (now 5.8.7) as MDV did for 2011?

Quoting upstream:
"in general it is less secure to run outdated versions"

http://www.rsyslog.com/potential-dos-with-malformed-tag/

AFAIK our policy is to patch if it's possible. And only upgrade to new version if patching is not possible or it's way too much work.

CC: (none) => sander.lepik

That is our policy generally I agree, but looking at Mandriva and Fedora (for both F15 and F16), they've both gone with newer versions wholesale. As there is no maintainer for rsyslog I'd be willing to push a newer version if no one has a massive objection?

Picking out the patches seems a bit of a pain.

(In reply to comment #6)
> That is our policy generally I agree, but looking at Mandriva and Fedora (for
> both F15 and F16), they've both gone with newer versions wholesale. As there is
> no maintainer for rsyslog I'd be willing to push a newer version if no one has
> a massive objection?
> 
> Picking out the patches seems a bit of a pain.

Exactly.  Of course I know our policy, but I asked because of what others did, including Mandriva, who has the same policy we do.  Also, being that others have pushed the newer version, the software itself should be sufficiently well tested.

Please proceed Colin :o)   Thanks.

Thanks Colin.  Just one minor note, new versions should have release 1 and no subrel:
https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29

OK, I've updated to the latest rsyslog as per the other distros. Works fine on
my mga1 box.

Please can other folk test for regressions and make sure it still works etc.
etc. If you can test the CVE then great but as it's the upstream version, I
think checking to make sure it works OK generally is enough.

I did forget about the whole subrel thing (and actually just put rel as 0.1 as per what I usually do locally... silly me!). Anyway, it can get bumped to 1 before pushing if no issues are found.

Fair enough.  Can we assign to QA?

Not much point assigning the bug report to qa when a new rpm has to
be built for the version/release number, as we have to re-test the
new rpm anyway (to ensure package is signed, installs cleanly, etc.).

Anyway, the update installed cleanly, rsyslog restarted and is working
fine here, on my i586 system.

CC: (none) => davidwhodgins

Thanks Dave.  I talked to Colin on IRC and we'll let this get some "informal" testing for a while this week before rebuilding and assigning to QA for final release.  This version actually just hit Cauldron yesterday, so it'll get some testing there too.

Writing the advisory (sans packages list, which will be posted once the final packages are made with the correct release tag).

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

Updated rsyslog packages fix security vulnerabilities:

Stack-based buffer overflow in the parseLegacySyslogMsg function
in tools/syslogd.c in rsyslogd in rsyslog 4.6.x before 4.6.8 and
5.2.0 through 5.8.4 might allow remote attackers to cause a denial of
service (application exit) via a long TAG in a legacy syslog message
(CVE-2011-3200).

rsyslog has been updated to version 5.8.7 which is not vulnerable to this issue.

References:
http://www.rsyslog.com/potential-dos-with-malformed-tag/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3200
http://www.mandriva.com/en/support/security/advisories/?dis=2011&name=MDVSA-2011:134-1

Not had any issues on my box, so I guess it's time to push out for proper QA. Bumped rel to 1 and submitted.

OK, assigning to QA.

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

Updated rsyslog packages fix security vulnerabilities:

Stack-based buffer overflow in the parseLegacySyslogMsg function
in tools/syslogd.c in rsyslogd in rsyslog 4.6.x before 4.6.8 and
5.2.0 through 5.8.4 might allow remote attackers to cause a denial of
service (application exit) via a long TAG in a legacy syslog message
(CVE-2011-3200).

rsyslog has been updated to version 5.8.7 which is not vulnerable to this
issue.

References:
http://www.rsyslog.com/potential-dos-with-malformed-tag/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3200
http://www.mandriva.com/en/support/security/advisories/?dis=2011&name=MDVSA-2011:134-1
========================

Updated packages in core/updates_testing:
========================
rsyslog-5.8.7-1.mga1
rsyslog-dbi-5.8.7-1.mga1
rsyslog-docs-5.8.7-1.mga1
rsyslog-gssapi-5.8.7-1.mga1
rsyslog-mysql-5.8.7-1.mga1
rsyslog-pgsql-5.8.7-1.mga1
rsyslog-relp-5.8.7-1.mga1
rsyslog-snmp-5.8.7-1.mga1

from rsyslog-5.8.7-1.mga1.src.rpm

Assignee: bugsquad => qa-bugs

Testing on i586 complete for the srpm
rsyslog-5.8.7-1.mga1.src.rpm

As the latest change was just a version number change, and the
packages install cleanly, I've been running the updated
version for three days without any problems.

Looking at https://bugzilla.redhat.com/show_bug.cgi?id=727644
it seems they've chosen to keep the "reproducer" private,
so we can't actually test the fix.

No regression noticed x86_64 with updated packages so I think we can validate this.

As Dave says, the details have not been made public and even they themselves were saying it is difficult to reproduce so I think regression checking is sufficient.

Update validated.

Please see comment 15 for advisory etc.

Could sysadmin please push from core/updates_testing to core/updates

Thankyou!

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs
Hardware: i586 => All

update pushed

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