Re: syslogd: patch for CVE-2014-3634
On Sun, Oct 12, 2014 at 4:12 AM, Tobias Stoeckmann tob...@stoeckmann.org wrote: our syslogd is also vulnerable to rsyslog's CVE-2014-3634. The CVE is about parsing the priority from network clients. The priority boundary isn't properly checked, which could lead to out of bounds access later on. Have you actually managed to make it crash? I've already committed a check for this when this first came out, mapping out of bounds pri values to LOG_USER, and at that time no one was able to crash the code without the check... Thoughts? Okays? Meh, seems like overkill. Philip Guenther
Re: syslogd: patch for CVE-2014-3634
On Sun, Oct 12, 2014 at 11:47:36AM -0700, Philip Guenther wrote: Have you actually managed to make it crash? I've already committed a check for this when this first came out, mapping out of bounds pri values to LOG_USER, and at that time no one was able to crash the code without the check... I see your change now in revision 1.126. Yeah, that one is enough. Thanks for clarifying, my diff is useless then. Tobias
Re: syslogd: patch for CVE-2014-3634
On 2014/10/12 11:47, Philip Guenther wrote: On Sun, Oct 12, 2014 at 4:12 AM, Tobias Stoeckmann tob...@stoeckmann.org wrote: our syslogd is also vulnerable to rsyslog's CVE-2014-3634. The CVE is about parsing the priority from network clients. The priority boundary isn't properly checked, which could lead to out of bounds access later on. Have you actually managed to make it crash? I've already committed a check for this when this first came out, mapping out of bounds pri values to LOG_USER, and at that time no one was able to crash the code without the check... The bigger problem with rsyslog and the reason for the crash possibility was that it used the priority as an index to lookup a human-readable string for the priority name (one of the options in the log entry format string is to include the *name* of the priority in log lines). So the bad values caused a read past the end of the array.
