Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 18:41:17 +0200
From: Rainer Gerhards <rgerhards@...adiscon.com>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: vulnerability in rsyslog

2014-09-30 18:28 GMT+02:00 Solar Designer <solar@...nwall.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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.