[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] vulnerability in rsyslog
From:       Rainer Gerhards <rgerhards () hq ! adiscon ! com>
Date:       2014-09-30 16:41:17
Message-ID: CADk+mPDpm2MaV4pfo7sBGoYpS2q+zCfNxjaOu78nvQgkABJ-yg () mail ! gmail ! com
[Download RAW message or body]


2014-09-30 18:28 GMT+02:00 Solar Designer <solar@openwall.com>:

> On Tue, Sep 30, 2014 at 01:55:12PM +0200, Sven Kieske wrote:
> > I don't understand the following statement in the
> > pri-vuln.txt in section "Patches":
> >
> > "Version 7.4.6, while no longer being project
> > supported received a patch and is also not vulnerable."
> >
> > What was patched when this version is not vulnerable?
> > Or do you mean it is not vulnerable after the patch got applied?
>
>
My apologies, this is a type that skipped past all proof-reading. It should
say "7.6.6", which is the v7 version released today. v7.4.x is not only
non-project supported, it's also heavily outdated and missing many other
patches as well (just to point this out).


> I think Rainer is not subscribed to oss-security.  I've just added him
> to CC on this reply.  Rainer - please address Sven's questions above.
>

yes, not subscribed, please CC me for follow-up questions.


>
> All - please note that the bug is likely present in many other syslog
> services.  It likely dates back all the way to Eric Allman's syslog,
> although I have not checked to make sure yet.
>
> pri-vuln.txt in the tarball attached to Rainer's message specifically
> mentions sysklogd as "mildly affected":
>
> | Affected
> | --------
> | - rsyslog, most probably all versions (checked 5.8.6+)
> | - sysklogd (checked most recent versions)
> | - potentially others (see root cause)
>
> [...]
>
> | sysklogd
> | ~~~~~~~~
> | Sysklogd is mildly affected. Having a quick look at the current git
> master
> | branch, the wrong action may be applied to messages with invalid
> facility.
> |
> | A segfault seems unlikely, as the maximum misadressing is 104 bytes of
> the
> | f_pmask table, which is always within properly allocated memory (albeit
> to
> | wrong data items). This can lead to triggering invalid selector lines and
> | thus wrongly writing to files or wrongly forwarding to other hosts.
>
>
I also wouldn't outrule that other *applications* fell into the the same
trap of the delta between the defines for NFACILITIES and the facility
mask. If an app processes syslog messages based on facility/severity
values, it probably is a good idea to check how it does that.

Thanks for the follow-up and cc'ing!
Rainer


[prev in list] [next in list] [prev in thread] [next in thread]