Date: Fri, 11 Mar 2011 00:03:38 +0300 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com, Florian Zumbiehl <florz@...rz.de> Cc: Josh Bressers <bressers@...hat.com>, "Steven M. Christey" <coley@...us.mitre.org>, Stefan Fritsch <sf@...itsch.de>, Petr Uzel <petr.uzel@...e.cz>, Thomas Biege <thomas@...e.de>, Jan Kalu??a <jkaluza@...hat.com> Subject: Re: CVE Request -- logrotate -- nine issues Florian, all - I'm sorry I failed to find time to comment on many postings in this thread, and also in the thread about a possible vendor-sec alternative. On Thu, Mar 10, 2011 at 07:08:38PM +0100, Florian Zumbiehl wrote: > What about these?: > > | However, I think that still #6 (shell injection) and #7 (logrotate > | DoS with strange characters in file names) should be considered > | vulnerabilities in logrotate: It would be reasonable to assume that you > | can use user input that's a valid (slash-less) filename as a (part of a) > | log file name (assuming that the program is running as the same user that > | inspects and rotates the logs, so the log directory being writable by > | the program would not be insecure per-se) without that file name being > | interpreted by a shell or causing logrotate to stop functioning, > | respectively. Based on the description above only (I have not looked at the code), it appears that on one hand the program might behave unexpectedly, but on the other no privilege boundary is crossed. My understanding is that these issues would need to be treated as vulnerabilities (and assigned CVE ids) only if they can be demonstrated to have security impact (as in: someone manages to do more than they were supposed to be able to) in an otherwise sane setup. I guess this could be the case if logrotate config files, including log filename patterns, are generated based on input from another user (different than the service pseudo-user and not root) - e.g., via a web-based administration interface with its own access control. However, even if so (which already feels somewhat unrealistic) I have difficulty imagining a web-based admin user who would be permitted to configure log rotation (including filename patterns) yet would not otherwise have access to the service pseudo-user account (perhaps the person would be the server admin, including full root access). To summarize, it feels like in theory a privilege boundary could exist here and be crossed on certain systems with extra software, but in practice this is unlikely and it would indicate poor design of another piece of software or/and false sense of security put into that privilege boundary. I don't know what this means for CVE id assignment per the current "rules". Once again, I am relying on the description posted in here only (and moreover on my interpretation of it), so maybe the actual situation is different. I usually don't care much about CVE ids being assigned or not. I cared about that for the majority of these logrotate issues because it felt like it could affect whether other packages will be fixed or not. This concern does not apply in the case of these two issues. Thus, I have no objections to CVE ids being assigned for them, even though we're not going to treat them as vulnerabilities (based on info available so far). Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ