Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Mar 2011 13:14:51 -0500
From: Dan Rosenberg <>
Cc: "Steven M. Christey" <>, Florian Zumbiehl <>, 
	Stefan Fritsch <>, Jan Kaluza <>, Paul Martin <>, 
	Petr Uzel <>, Thomas Biege <>, Jan Lieskovsky <>
Subject: Re: CVE Request -- logrotate -- nine issues

>> It felt wrong, say, to blame a text editor for being unsafe to use on
>> files in untrusted directories when such unsafety was the typical and
>> expected situation for text editors in general.
> Some items can be assigned a CVE without deep thought about the larger
> context.  This may happen due to volume, time constraints, or an
> under-specified attack scenario by the requester.  That may be the case with
> the case you're talking about here, but I don't remember it.

Just to chime in here about parallels to the GNU nano case you're
referring to.  I agree with you that a CVE for those issues may have
been unnecessary, but it depends on your expectations of what
guarantees a text editor provides.  If I try to open an untrusted file
with a text editor, and an attacker replaces that file before I open
it, resulting in me making edits to the wrong file, then of course
that's not a security issue, because the text editor did exactly what
it was told to do: open the file, which happened to be different by
the time it got around to opening it.  There would also be visual
feedback in the text editor to alert the user as to which file was
being edited.  However, if I open a file to edit, and someone changes
that file out from under me while I'm making edits, and a resulting
save overwrites the new underlying file, including following symlinks,
that's slightly different, since one might argue that some feedback or
warning from the editor would be expected (this is the case with
almost all other text editors).  But this is subtle, and I understand
both sides of the argument - personally, I don't think it's a serious
enough attack vector to warrant splitting hairs over.

The logrotate case is even more subtle, since it's even less clear
what constitute reasonable expectations with regards to the security
guarantees of the application.


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.