7724272 2001-12-28 01:25 -0500 /54 rader/ Chris Gragsone <maetrics@realwarp.net> Sänt av: joel@lysator.liu.se Importerad: 2001-12-28 19:37 av Brevbäraren Extern mottagare: bugtraq <bugtraq@securityfocus.com> Mottagare: Bugtraq (import) <20298> Ärende: Vim backup Source Disclosure Vulnerability ------------------------------------------------------------ From: Chris Gragsone <maetrics@realwarp.net> To: bugtraq <bugtraq@securityfocus.com> Message-ID: <3C2C1055.3040801@realwarp.net> Vim backup Source Disclosure Vulnerability by Chris Gragsone Foot Clan Date: December 27, 2001 Advisory ID: Foot-20011227 Impact of vulnerability: Source Disclosure Exploitable: Remote Maximum Risk: Moderate Affected Software: Vim Vulnerability Description: Vim is an improved version of the editor "vi", one of the standard text editors on UNIX systems. Vim includes a 'backup' option, that once set Vim renames the original file before it is overwritten. A malicous user can request the backup name for the script bypassing the server side processing and disclouse the script's source code. In Vim 3.0 and earlier, the 'backup' option is set by default, and the originial file is renamed to a filename appended with '.bak'. This option is disabled by default in Vim 4.0 and later. However, if enabled the original file is renamed to a filename appended with '~'. In each case the backup file keeps the original permissions This is not a software bug rather a misconfiguration or administrative oversight. The specific request involved with this vulnerability cannot belong to a legitimate connection. This vulnerability has been tested with PHP4 on Apache, but should affect all other scripts which are routinely edited in the manner. Vulnerability Reproduction: with Vim 4.0 and later: http://footclan.realwarp.net/passwd.php~ with Vim 3.0 and earlier: http://footclan.realwarp.net/passwd.php.bak References: http://www.vim.org/ Contact: http://footclan.realwarp.net/ Chris Gragsone (maetrics@realwarp.net) Disclaimer: The contents of this advisory are copyright (c)2001 Foot Clan and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. (7724272) /Chris Gragsone <maetrics@realwarp.net>/(Ombruten) Kommentar i text 7725315 av Peter W <peterw@usa.net> 7725315 2001-12-28 14:15 -0500 /72 rader/ Peter W <peterw@usa.net> Sänt av: joel@lysator.liu.se Importerad: 2001-12-29 03:53 av Brevbäraren Extern mottagare: bugtraq <bugtraq@securityfocus.com> Extern kopiemottagare: Chris Gragsone <maetrics@realwarp.net> Mottagare: Bugtraq (import) <20304> Kommentar till text 7724272 av Chris Gragsone <maetrics@realwarp.net> Ärende: Re: Vim backup Source Disclosure Vulnerability ------------------------------------------------------------ From: Peter W <peterw@usa.net> To: bugtraq <bugtraq@securityfocus.com> Cc: Chris Gragsone <maetrics@realwarp.net> Message-ID: <20011228141541.G6947@usa.net> On Fri, Dec 28, 2001 at 01:25:25AM -0500, Chris Gragsone wrote: > Vim backup Source Disclosure Vulnerability > Affected Software: > Vim Bah! > This is not a software bug rather a misconfiguration or administrative > oversight. > This vulnerability has been tested > with PHP4 on Apache, but should affect all other scripts which are > routinely edited in the manner. ...and which reside in the doc root. Stuff your application code inside ScriptAlias directories and any backup copies will either be executed, or generate errors, depending on their permission bits. > Vulnerability Reproduction: > with Vim 4.0 and later: http://footclan.realwarp.net/passwd.php~ > with Vim 3.0 and earlier: http://footclan.realwarp.net/passwd.php.bak There's not really anything new here, and *absolutely no reason* to name this "advisory" as if it's a problem with 'vim'. Many text editors, including vim's supposed nemesis emacs, have similar behaviors. As a friend of mine likes to say, if there's a problem here, it lies between the chair and keyboard. :-) If you want to be helpful, suggest a real fix, eh? The basic problem here is that some fool is saving new files to the document root, and the httpd has been configured to publish anything it can find and read in its document root. One way to guard against accidental leakage like this is to configure the httpd to only serve objects whose extensions (and, therefore, MIME types) are recognized. Here's how you can easily do it for Netscape Enterprise Server/iPlanet Web Server (in obj.conf): # *replace* your current "force-type" ObjectType directive with one # that flags unrecognized extensions with a special MIME type ObjectType fn="force-type" type="magnus-internal/unknown" # Now we tell the httpd to error out for unrecognized extensions; # the "path" should *not* exist; this will make the server respond with # a 404/Not Found error for any unrecognized extension; this needs to # come before any other Service directives whose "type" arguments # would match "magnus-internal/unknown" Service fn="send-error" type="magnus-internal/unknown" path="/bogus" I'm not sure how much work would be required to do similar things for Apache, AOLServer, or other httpds. Of course if your text editor saves with a suffix that's listed in your MIME type configuration, or uses a prefix (Allaire HomeSite, anyone?), or perhaps if your httpd tries to "magically" determine an object's MIME type, or the backup file is in a CGI directory and the editor saves the backup w/ the execute bits on, well, this approach won't save you from that. I mean, the underlying problem lies with how the content is managed and updated. Bottom line is you shouldn't put anything on a public httpd that you don't want, umm, public. -Peter Happy holidays & new year to all, especially Harlan (7725315) /Peter W <peterw@usa.net>/------(Ombruten)