Date: Fri, 4 Mar 2011 20:05:03 +0300 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Cc: "Steven M. Christey" <coley@...us.mitre.org>, Stefan Fritsch <sf@...itsch.de>, Jan Kaluza <jkaluza@...hat.com>, Florian Zumbiehl <florz@...rz.de>, Paul Martin <pm@...ian.org>, Petr Uzel <petr.uzel@...e.cz>, Thomas Biege <thomas@...e.de> Subject: Re: CVE Request -- logrotate -- nine issues On Fri, Mar 04, 2011 at 04:35:03PM +0100, Jan Lieskovsky wrote: > For issue #5: > > If the mail configuration directive is used, an attacker can trick > logrotate into sending arbitrary files by mail, by creating > appropriate hard or soft links. > > Hope that's enough, let me know if not. I can definitely figure this out by looking at the code, but the description alone looks insufficient to me. It does not say what directory those links would need to be created in. If it's the log files' directory, which I suspect is the case, then this issue falls in the same controversial category as most of the rest. If it's /tmp, then this is in fact a vulnerability in logrotate, without a doubt. > >The rest, as described, appear to rely on sysadmin error and to assume > >security properties that logrotate never advertised it had. Specifically, > >logrotate was never declared to be safe to use on untrusted directories, > >and it was an error for a sysadmin to make such an assumption. > > We don't mind documenting of this behavior in appropriate places. Do you mean the fact that logrotate is not meant for use on untrusted directories? Or, on the contrary, claim that it is safe for that after the hardening changes to be made now? I prefer the former. > Wouldn't like to condescend further into particulars, what is and what > is not a security issue (as this is beyond this post), but according > to our opinion even non-documented incorrect behavior, allowing > malicious actions to be performed on the system, should be considered > a security flaw (regardless if it's advertised or not). Because by applying > your above approach, most of the open source project could just say > 'this software is not intended to be run like that.' Like I wrote in my reply to Florian, this is about expectations. You say "incorrect behavior", which makes sense to me. For example, "cp" is also unsafe in untrusted directories, but its behavior is nevertheless "correct" (because it is documented), so you would not call it a security flaw for that reason. Fair enough. However, then there are things such as text editors, which are also unsafe for use on files in untrusted directories. Is it "incorrect behavior" that they are? To me, this has always been the historically expected unsafety. However, Dan Rosenberg managed to get a CVE id for such an issue in an editor. I was surprised. The issue did not affect us (we were not packaging the editor), but if it did we would not call it a vulnerability. Just wrong/flawed expectations by the user. Again, as I wrote to Florian, maybe the expectations here are changing over the years. However, if so, wouldn't it be right to have hardening introduced into the relevant programs first, the expectations "officially" changed (although I'd rather not do that), and only if/when that hardening is later determined to be insufficient start saying "vulnerability" and assigning CVE ids? Speaking of issues where a more or differently privileged process accesses files in a directory writable by another process, these are surprisingly difficult to "fully" deal with, and the majority of programs are "affected". Of the common Unix commands, only a handful are safe to use in untrusted directories (with possible impact of attacks being a mere DoS against the command itself) - such as "ln". Yes, I actually use "ln" like this: # su - user1 $ cp some/dir/file . # hopefully the ~/file name was not taken $ exit # ln ~user1/file . # ls -ld file # sanity check that we were not raced # chown user2: file # ln file ~user2/ # rm file # su - user2 $ mv file target/dir/ $ exit # su - user1 $ rm file when I need to copy a file from one untrusted user to another. Yes, this is complicated and it has limitations (same fs). Maybe we need a special tool for this task (I had some ideas on this - "give" and "take" commands). But that's the current situation. Almost all other commands and programs are unsafe on untrusted directories. In my opinion, that's the only correct assumption for a sysadmin to make, and any other assumption is naive. Unfortunately, most sysadmins don't fully realize this (in my experience), but that does not make those programs any safer, nor does it prompt us to assign CVE ids against almost all Unix programs. > Not trying to argue, I also primarily mean to share some info/understanding/reasoning rather than to argue. > just saying the disclination like the above doesn't help anyone. I think it does. But I am willing to shut up. ;-) I sure am not going to post stuff that people don't want to receive/read. ;-) > Either the software has the issues, and they should be fixed, > or it has the issues, and they can't be fixed. Then the software > should not be used and an alternative one should be found. No software is perfect, and almost any piece of software can be improved endlessly. But that's mere rhetoric. I don't mind logrotate being hardened against these issues. We do a lot of hardening in other areas, so why not here. I just don't blame logrotate for the issues. I blame improper service packages and insufficient sysadmin education. Hardening logrotate and not fixing those other truly broken packages sounds plain wrong to me. The latter part of it (not fixing), not the former. As to CVE ids against logrotate, I don't care much; it's just that we're not going to say our logrotate update fixes 9 vulnerabilities. We may say it fixes one (the #8 issue). > This is not you would shoot yourself into the foot by accident > (by performing some action). This is about local users', aware > of the deficiencies, ability to conduct such actions on the system, > so they would reach some higher privilege, damage or different > kind of benefit for them. Sorry, your desired meaning of the above escapes me... Nevermind. Thank you for your response! 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