Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 Jul 2011 17:23:58 -0400 (EDT)
From: "Steven M. Christey" <>
Subject: Re: Apache symlink issue: can documented behavior be
 a security problem and hence get a CVE?

Very rarely, we will cover "documented behavior" if there is sufficient 
evidence of widespread abuse/misuse of that behavior by admins, in which 
case the CVE description would emphasize the fact that it is the admin's 
"fault" or "misconception."  I generally try to stay away from edge cases 
(such as this one) that could have a "snowball effect" of setting a 
precedent that could ultimately be used to argue for assigning too many 
low-priority CVEs to many issues.  I would be inclined to avoid assigning 
a CVE for this issue unless someone can provide a realistic, relatively 
common scenario under which this would pose a significant security 

Speaking of Apache, the well-known double-extension handling issue that 
enables arbitrary upload/execution of dangerous files like abc.php.gif 
also doesn't have a CVE [I don't think] for similar reasons, that it is 
well-documented behavior.

- Steve

On Tue, 12 Jul 2011, Josh Bressers wrote:

> I'm going to leave this one for MITRE.
> Thanks.
> --
>    JB
> ----- Original Message -----
>> Hash: SHA1
>> Hello List,
>> Is it possible to assign a CVE for documented behavior? Communication
>> with apache security showed, that following symlinks to arbitrary
>> locations is a documented feature, even when "-FollowSymLink" option
>> is
>> in place. This allows any user with, that can modify some content
>> served
>> by apache to access any content accessible by the apache process, also
>> content not visible to the user (e.g. outside the ftp-upload directory
>> or forbidden like /proc/http-pid/maps). Due to the small window of
>> opportunity, this might be relevant mostly when user can already
>> execute
>> code on the machine, so it is not a big issue. /proc/<pid>/mem is
>> protected, when apache is running with setuid, so key material cannot
>> be
>> extracted using range headers. PUT was not tested so far.
>> See also
>> - --
>> PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
>> Version: GnuPG v1.4.6 (GNU/Linux)
>> iD8DBQFOHC4exFmThv7tq+4RAooyAJ9Vh7F49em+AVT1HosEquCPS+olqQCfdVCO
>> PDcCdoHHWTCHe53U+XTzefY=
>> =fVzn
>> -----END PGP SIGNATURE-----

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.