Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

1. Summary

Product  : Vim -- Vi IMproved
Versions : 5.0--current, possibly older; 4.6 and 3.0 not vulnerable
Impact   : Arbitrary code execution
Wherefrom: Local
Original : http://www.rdancer.org/vulnerablevim-configure.in.html
           http://www.rdancer.org/vulnerablevim-configure.in.patch

Insecure temporary file creation during the build process is vulnerable
to symbolic link attacks, and arbitrary code execution.  Patch provided.

2. Background

``Vim is an almost compatible version of the UNIX editor Vi.  Many new
features have been added: multi-level undo, syntax highlighting, command
line history, on-line help, spell checking, filename completion, block
operations, etc.''
	-- VIM ``README.txt''

3. Vulnerability

During the build process, a temporary file with a predictable name is
created in the ``/tmp'' directory.  This code is run when Vim is being
build with Python support:

src/configure.in:

         677         dnl -- we need to examine Python's config/Makefile too
         678         dnl    see what the interpreter is built from
(Continue reading)

Nikolai Weibull | 18 Jul 09:38

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Fri, Jul 18, 2008 at 00:54, Jan Minář <rdancer <at> rdancer.org> wrote:

> The attacker has to create the temporary file
> ``/tmp/Makefile-conf<PID>'' before it is first written to at (1).  In
> the time between (1) and (2), arbitrary commands can be written to the
> file.  They will be executed at (2).

> Patch fixing this vulnerability can be found at the following URL:
>
>           http://www.rdancer.org/vulnerablevim-configure.in.patch

Using mktemp is a lot safer than using $$, but the file can still be
written to between the creation and setup of the file and the eval.
Dealing with temporary files in shell scripts is always racy.  This
fixes the easily guessed PID-pattern problem and as mktemp creates its
file in a hopefully non-shared directory, increases security a great
deal, but it's still racy.

Why not use pipes instead?

eval "`cd /usr/lib/python2.4/config && (cat Makefile - <<'eof'
__:
        @echo "python_MODLIBS='$(MODLIBS)'"
        @echo "python_LIBS='$(LIBS)'"
        @echo "python_SYSLIBS='$(SYSLIBS)'"
        @echo "python_LINKFORSHARED='$(LINKFORSHARED)'"
eof
) | make -f - __ | sed '/ directory /d'`"

(I really don't see the point of the sed.  Isn't that information
(Continue reading)

Bram Moolenaar | 18 Jul 16:33

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


Nikolai Weibull wrote:

> On Fri, Jul 18, 2008 at 00:54, Jan Mináø <rdancer <at> rdancer.org> wrote:
> 
> > The attacker has to create the temporary file
> > ``/tmp/Makefile-conf<PID>'' before it is first written to at (1).  In
> > the time between (1) and (2), arbitrary commands can be written to the
> > file.  They will be executed at (2).
> 
> > Patch fixing this vulnerability can be found at the following URL:
> >
> >           http://www.rdancer.org/vulnerablevim-configure.in.patch
> 
> Using mktemp is a lot safer than using $$, but the file can still be
> written to between the creation and setup of the file and the eval.
> Dealing with temporary files in shell scripts is always racy.  This
> fixes the easily guessed PID-pattern problem and as mktemp creates its
> file in a hopefully non-shared directory, increases security a great
> deal, but it's still racy.

"mktemp" is supposed to create the file with 0600 permissions.  The race
is very unlikely then.  It's still better to create a private directory
though (which is what Vim does for its temp files).

> Why not use pipes instead?
> 
> eval "`cd /usr/lib/python2.4/config && (cat Makefile - <<'eof'
> __:
>         @echo "python_MODLIBS='$(MODLIBS)'"
(Continue reading)

Bram Moolenaar | 18 Jul 11:46

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


Jan Minar wrote:

> 1. Summary
> 
> Product  : Vim -- Vi IMproved
> Versions : 5.0--current, possibly older; 4.6 and 3.0 not vulnerable
> Impact   : Arbitrary code execution
> Wherefrom: Local
> Original : http://www.rdancer.org/vulnerablevim-configure.in.html
>            http://www.rdancer.org/vulnerablevim-configure.in.patch
> 
> Insecure temporary file creation during the build process is vulnerable
> to symbolic link attacks, and arbitrary code execution.  Patch provided.
> 
> 
> 2. Background
> 
> ``Vim is an almost compatible version of the UNIX editor Vi.  Many new
> features have been added: multi-level undo, syntax highlighting, command
> line history, on-line help, spell checking, filename completion, block
> operations, etc.''
> 	-- VIM ``README.txt''
> 
> 
> 3. Vulnerability
> 
> During the build process, a temporary file with a predictable name is
> created in the ``/tmp'' directory.  This code is run when Vim is being
> build with Python support:
(Continue reading)

Nikolai Weibull | 18 Jul 13:54

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Fri, Jul 18, 2008 at 11:46, Bram Moolenaar <Bram <at> moolenaar.net> wrote:

> Unfortunately the patch breaks configure for me:
>        86: checking Python's configuration directory... /usr/local/lib/python2.5/config
>        87: usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
>        88:        mktemp [-d] [-q] [-u] -t prefix
>        89: Error: Can't create temporary file. Aborting.
>
> The BSD mktemp command requires a template or a "-t prefix" argument.  I
> don't know how portable it is, but this works for me:
>
>            tmp_mkf="`mktemp /tmp/VcPmkXXXXXXXXXX`"

And then we're back to the original problem, minus the easily
guessable PID.  If you want to solve it correctly, using pipes is a
lot better.  That way there's no chance of interception.  Patch
attached.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Attachment (configure.in.no.tmp.patch): application/octet-stream, 1055 bytes

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


mktemp(1) creates the file securely, with 0600 permissions. That's the
whole point. There is no race condition. That's the whole point.

On 7/18/08, Nikolai Weibull <now <at> bitwi.se> wrote:
> On Fri, Jul 18, 2008 at 11:46, Bram Moolenaar <Bram <at> moolenaar.net> wrote:
>
>> Unfortunately the patch breaks configure for me:
>>        86: checking Python's configuration directory...
>> /usr/local/lib/python2.5/config
>>        87: usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
>>        88:        mktemp [-d] [-q] [-u] -t prefix
>>        89: Error: Can't create temporary file. Aborting.
>>
>> The BSD mktemp command requires a template or a "-t prefix" argument.  I
>> don't know how portable it is, but this works for me:
>>
>>            tmp_mkf="`mktemp /tmp/VcPmkXXXXXXXXXX`"
>
> And then we're back to the original problem, minus the easily
> guessable PID.  If you want to solve it correctly, using pipes is a
> lot better.  That way there's no chance of interception.  Patch
> attached.
>

--

-- 
Sent from Google Mail for mobile | mobile.google.com

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
(Continue reading)

Ben Schmidt | 18 Jul 16:45

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


Jan Minář wrote:
> mktemp(1) creates the file securely, with 0600 permissions. That's the
> whole point. There is no race condition. That's the whole point.

Presuming the directory it's in is sticky or such so other users can't
change it. I suppose it probably is on most systems, but I doubt it is
on all... :-\

I expect the pipe suggestion that someone else offered would break on a whole 
bunch of systems, though.

Ben.

> On 7/18/08, Nikolai Weibull <now <at> bitwi.se> wrote:
>> On Fri, Jul 18, 2008 at 11:46, Bram Moolenaar <Bram <at> moolenaar.net> wrote:
>>
>>> Unfortunately the patch breaks configure for me:
>>>        86: checking Python's configuration directory...
>>> /usr/local/lib/python2.5/config
>>>        87: usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
>>>        88:        mktemp [-d] [-q] [-u] -t prefix
>>>        89: Error: Can't create temporary file. Aborting.
>>>
>>> The BSD mktemp command requires a template or a "-t prefix" argument.  I
>>> don't know how portable it is, but this works for me:
>>>
>>>            tmp_mkf="`mktemp /tmp/VcPmkXXXXXXXXXX`"
>> And then we're back to the original problem, minus the easily
>> guessable PID.  If you want to solve it correctly, using pipes is a
(Continue reading)

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Fri, Jul 18, 2008 at 3:45 PM, Ben Schmidt
<mail_ben_schmidt <at> yahoo.com.au> wrote:
>
> Jan Minář wrote:
>> mktemp(1) creates the file securely, with 0600 permissions. That's the
>> whole point. There is no race condition. That's the whole point.
>
> Presuming the directory it's in is sticky or such so other users can't
> change it. I suppose it probably is on most systems, but I doubt it is
> on all... :-\

Interesting!  I never would have thought security of code running on a
million platforms is going to be so much pain^H^H^H^Hfun!

If creating a temporary file securely is possible at all, shouldn't
mktemp(1) do just that?  And if it doesn't, is Vim source code the
right place to fix it?

The configure can just use a fixed file name in the current directory.

Anyway, I have adapted some code from src/auto/configure that will
work on systems without mktemp(1) -- patch attached.

Cheers,
Jan.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Ben Schmidt | 19 Jul 16:44

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


Jan Minář wrote:
> On Fri, Jul 18, 2008 at 3:45 PM, Ben Schmidt
> <mail_ben_schmidt <at> yahoo.com.au> wrote:
>> Jan Minář wrote:
>>> mktemp(1) creates the file securely, with 0600 permissions. That's the
>>> whole point. There is no race condition. That's the whole point.
>> Presuming the directory it's in is sticky or such so other users can't
>> change it. I suppose it probably is on most systems, but I doubt it is
>> on all... :-\
> 
> Interesting!  I never would have thought security of code running on a
> million platforms is going to be so much pain^H^H^H^Hfun!

Mmm. It's hard to know how far to go with stuff like this, too. Where
does the responsibility of the programmer stop and the sysadmin start,
and where does their responsibility stop and the user's start? I think
it's reasonable to expect users not to open files with suspicious names
with funny characters in them. If they do, they deserve what they get,
same as if they open a parcel that's ticking. If they have a habit of
doing such things, installing anti-virus software seems to be the in
vogue way to deal with it.

Particularly in Vim's case (as is the case with many Unix programs)
where the shell that will be called to perform certain operations can
not be predicted, so the escaping can't be determined in advance, it
quickly becomes unreasonable for the programmer to deal with the
totality of these issues. It can also be a waste of developer time if
taken too far--the great lack of likelihood of many attacks and
similarly great benefits of spending time fixing or implementing *other
(Continue reading)

Matthew Winn | 20 Jul 09:22

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


On Sun, 20 Jul 2008 00:44:48 +1000, Ben Schmidt
<mail_ben_schmidt <at> yahoo.com.au> wrote:

> As has been pointed out, making a directory in /tmp is more secure. More
> specifically, making a directory and putting a file in it (there is a
> race condition there, of course...but checking/setting the mode can
> ensure security, I think). The directory can't be deleted and replaced
> unless empty, and can't be emptied if not writable.

On Unix directories can be deleted when not empty. I've done it by
accident. So long as there's a process with the directory as its
current directory the directory remains there, although the absence
of a ".." link breaks many commands that expect a sensible filesystem
structure. It's inadvisable to do it, however, and fsck usually has
a few comments to make about the situation.

For security you need to set umask to 077, find a directory that has
the sticky bit set, ensure that all ancestors of that directory are
unwriteable by general users, create your own temporary directory,
and then create your files in that directory.

> On regular annoyance I have is that my system periodically cleans up
> /tmp and removes Vim's temp directories, and since a long-running Vim
> process created the directory, it assumes it's there and doesn't
> recreate it but just gives errors.

Shouldn't it only clear out things that haven't been used for a while?
The whole point of /tmp is that it's somewhere for short-term storage,
not no-term storage.
(Continue reading)

Ben Schmidt | 20 Jul 12:42

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


Matthew Winn wrote:
> On Sun, 20 Jul 2008 00:44:48 +1000, Ben Schmidt
> <mail_ben_schmidt <at> yahoo.com.au> wrote:
> 
>> As has been pointed out, making a directory in /tmp is more secure. More
>> specifically, making a directory and putting a file in it (there is a
>> race condition there, of course...but checking/setting the mode can
>> ensure security, I think). The directory can't be deleted and replaced
>> unless empty, and can't be emptied if not writable.
> 
> On Unix directories can be deleted when not empty. I've done it by
> accident.

Mmm. I think I have too, now you mention it. But I think I perhaps
thought that they could be moved but not fully deleted. Of course, it
depends on the filesystem as well as the OS.

> So long as there's a process with the directory as its
> current directory the directory remains there, although the absence
> of a ".." link breaks many commands that expect a sensible filesystem
> structure. It's inadvisable to do it, however, and fsck usually has
> a few comments to make about the situation.
> 
> For security you need to set umask to 077, find a directory that has
> the sticky bit set, ensure that all ancestors of that directory are
> unwriteable by general users, create your own temporary directory,
> and then create your files in that directory.

Mmm. So we're back where we started: if the system is properly
(Continue reading)

Matthew Winn | 21 Jul 20:09

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


On Sun, 20 Jul 2008 20:42:21 +1000, Ben Schmidt
<mail_ben_schmidt <at> yahoo.com.au> wrote:

> Matthew Winn wrote:
> > On Sun, 20 Jul 2008 00:44:48 +1000, Ben Schmidt
> > <mail_ben_schmidt <at> yahoo.com.au> wrote:
> > 
> >> As has been pointed out, making a directory in /tmp is more secure. More
> >> specifically, making a directory and putting a file in it (there is a
> >> race condition there, of course...but checking/setting the mode can
> >> ensure security, I think). The directory can't be deleted and replaced
> >> unless empty, and can't be emptied if not writable.
> > 
> > On Unix directories can be deleted when not empty. I've done it by
> > accident.
> 
> Mmm. I think I have too, now you mention it. But I think I perhaps
> thought that they could be moved but not fully deleted. Of course, it
> depends on the filesystem as well as the OS.

I'm pretty sure you can only delete in-use directories with a call to
unlink() at the system level. Both rm and rmdir are careful to leave
the filesystem in a sensible state, but unlink() seems to assume that
if you know enough to use a C compiler you know enough to deal with
the consequences of unlinking a directory from the tree.

--

-- 
Matthew Winn

(Continue reading)

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Winn wrote:
> I'm pretty sure you can only delete in-use directories with a call to
> unlink() at the system level. Both rm and rmdir are careful to leave
> the filesystem in a sensible state, but unlink() seems to assume that
> if you know enough to use a C compiler you know enough to deal with
> the consequences of unlinking a directory from the tree.

At least on linux, that's not true. Unlink only works on files, for
directories you want the rmdir syscall. Nonetheless, the directory
can still be the current working directory of some process. Said
process can however not do much with the directory afterwards.

And the manpage for unlink claims POSIX compliance...

Jens

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIhRigzhchXT4RR5ARAlU9AJ9fdw3N47HITwbGJELO/qqxqusB3gCg0KKh
1gP2py0Lifg2SVynBmdbaH8=
=HPJR
-----END PGP SIGNATURE-----

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
(Continue reading)

Gary Johnson | 20 Jul 09:41

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


On 2008-07-20, Matthew Winn <vim <at> mwinn.powernet.co.uk> wrote:
> On Sun, 20 Jul 2008 00:44:48 +1000, Ben Schmidt
> <mail_ben_schmidt <at> yahoo.com.au> wrote:

> > On regular annoyance I have is that my system periodically cleans up
> > /tmp and removes Vim's temp directories, and since a long-running Vim
> > process created the directory, it assumes it's there and doesn't
> > recreate it but just gives errors.
> 
> Shouldn't it only clear out things that haven't been used for a while?
> The whole point of /tmp is that it's somewhere for short-term storage,
> not no-term storage.

I think the scenario goes like this:

   Start vim.
   Do something that causes vim to create a directory in /tmp.
   Keep vim running for a long time but don't do any operations that 
      put files into the tmp directory.
   System clean-up job runs, finds that the modification time on 
      vim's tmp directory hasn't changed in a while and deletes it.
   Try to do something in vim that needs the tmp directory.  Vim 
      already created on, but it's no longer there, so vim issues an 
      error message.

Regards,
Gary

--~--~---------~--~----~------------~-------~--~----~
(Continue reading)

Bram Moolenaar | 20 Jul 16:01

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


Jan Minar wrote:

> On Fri, Jul 18, 2008 at 3:45 PM, Ben Schmidt
> <mail_ben_schmidt <at> yahoo.com.au> wrote:
> >
> > Jan Minář wrote:
> >> mktemp(1) creates the file securely, with 0600 permissions. That's the
> >> whole point. There is no race condition. That's the whole point.
> >
> > Presuming the directory it's in is sticky or such so other users can't
> > change it. I suppose it probably is on most systems, but I doubt it is
> > on all... :-\
> 
> Interesting!  I never would have thought security of code running on a
> million platforms is going to be so much pain^H^H^H^Hfun!
> 
> If creating a temporary file securely is possible at all, shouldn't
> mktemp(1) do just that?  And if it doesn't, is Vim source code the
> right place to fix it?

mktemp is secure on most systems.  Not everywhere though.  But for this
purpose it's safe enough to assume it is.  If mktemp isn't secure the
solution is to upgrade the system, since many more applications will
run into this problem.  Making Vim's configure safe won't help much.

> The configure can just use a fixed file name in the current directory.
> 
> Anyway, I have adapted some code from src/auto/configure that will
> work on systems without mktemp(1) -- patch attached.
(Continue reading)

Nikolai Weibull | 20 Jul 16:09

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


On Sun, Jul 20, 2008 at 16:01, Bram Moolenaar <Bram <at> moolenaar.net> wrote:

> Jan Minar wrote:

>> The configure can just use a fixed file name in the current directory.
>>
>> Anyway, I have adapted some code from src/auto/configure that will
>> work on systems without mktemp(1) -- patch attached.

> There probably is a small security hole in this as well.  A targeted
> symlink attack might work.  mktemp() is suppose to use a special open()
> call that avoids symlinks and creates the file in a way it can't be
> interrupted.  I think it's better to rely on mktemp for that reason.
> It's not something you can do in a shell.

The pipe solution still exists and is secure.  According to the POSIX
standard, "make -f -" should make make process standard input:

  http://www.opengroup.org/onlinepubs/009695399/utilities/make.html

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Bram Moolenaar | 21 Jul 22:05

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


Nikolai Weibull wrote:

> On Sun, Jul 20, 2008 at 16:01, Bram Moolenaar <Bram <at> moolenaar.net> wrote:
> 
> > Jan Minar wrote:
> 
> >> The configure can just use a fixed file name in the current directory.
> >>
> >> Anyway, I have adapted some code from src/auto/configure that will
> >> work on systems without mktemp(1) -- patch attached.
> 
> > There probably is a small security hole in this as well.  A targeted
> > symlink attack might work.  mktemp() is suppose to use a special open()
> > call that avoids symlinks and creates the file in a way it can't be
> > interrupted.  I think it's better to rely on mktemp for that reason.
> > It's not something you can do in a shell.
> 
> The pipe solution still exists and is secure.  According to the POSIX
> standard, "make -f -" should make make process standard input:
> 
>   http://www.opengroup.org/onlinepubs/009695399/utilities/make.html

There are make programs that were written before POSIX.  I don't think
they should break the configure script.

--

-- 
Eight Megabytes And Continually Swapping.

 /// Bram Moolenaar -- Bram <at> Moolenaar.net -- http://www.Moolenaar.net   \\\
(Continue reading)

Nikolai Weibull | 18 Jul 17:16

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Fri, Jul 18, 2008 at 15:06, Jan Minář <rdancer <at> rdancer.org> wrote:
> mktemp(1) creates the file securely, with 0600 permissions. That's the
> whole point. There is no race condition. That's the whole point.

More securely, not totally secure.  /That's/ the whole point.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Robert Buchholz | 25 Jul 03:17

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Friday 18 July 2008, Jan Minář wrote:
...
> 3. Vulnerability
>
> During the build process, a temporary file with a predictable name is
> created in the ``/tmp'' directory.  This code is run when Vim is
> being build with Python support:
>
> src/configure.in:
>
>          677         dnl -- we need to examine Python's
> config/Makefile too 678         dnl    see what the interpreter is
> built from 679         AC_CACHE_VAL(vi_cv_path_python_plibs,
>          680         [
>          681             tmp_mkf="/tmp/Makefile-conf$$"
>   (1)--> 682             cat ${PYTHON_CONFDIR}/Makefile - <<'eof'
> >${tmp_mkf} 683 __:
>          684         @echo "python_MODLIBS='$(MODLIBS)'"
>          685         @echo "python_LIBS='$(LIBS)'"
>          686         @echo "python_SYSLIBS='$(SYSLIBS)'"
>          687         @echo "python_LINKFORSHARED='$(LINKFORSHARED)'"
>          688 eof
>          689             dnl -- delete the lines from make about
> Entering/Leaving directory
>   (2)--> 690             eval "`cd ${PYTHON_CONFDIR} && make -f
> ${tmp_mkf} __ | sed '/ directory /d'`"
>          691             rm -f ${tmp_mkf}
>
> The attacker has to create the temporary file
> ``/tmp/Makefile-conf<PID>'' before it is first written to at (1).  In
(Continue reading)

Re: [Full-disclosure] Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

2008/7/25 Robert Buchholz <rbu <at> gentoo.org>:
> On Friday 18 July 2008, Jan Minář wrote:
> ...
>> 3. Vulnerability
>>
>> During the build process, a temporary file with a predictable name is
>> created in the ``/tmp'' directory.  This code is run when Vim is
>> being build with Python support:
>>
>> src/configure.in:
>>
>>          677         dnl -- we need to examine Python's
>> config/Makefile too 678         dnl    see what the interpreter is
>> built from 679         AC_CACHE_VAL(vi_cv_path_python_plibs,
>>          680         [
>>          681             tmp_mkf="/tmp/Makefile-conf$$"
>>   (1)--> 682             cat ${PYTHON_CONFDIR}/Makefile - <<'eof'
>> >${tmp_mkf} 683 __:
>>          684         @echo "python_MODLIBS='$(MODLIBS)'"
>>          685         @echo "python_LIBS='$(LIBS)'"
>>          686         @echo "python_SYSLIBS='$(SYSLIBS)'"
>>          687         @echo "python_LINKFORSHARED='$(LINKFORSHARED)'"
>>          688 eof
>>          689             dnl -- delete the lines from make about
>> Entering/Leaving directory
>>   (2)--> 690             eval "`cd ${PYTHON_CONFDIR} && make -f
>> ${tmp_mkf} __ | sed '/ directory /d'`"
>>          691             rm -f ${tmp_mkf}
>>
>> The attacker has to create the temporary file
(Continue reading)

Robert Buchholz | 25 Jul 12:18

Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Friday 25 July 2008, Jan Minář wrote:
> 2008/7/25 Robert Buchholz <rbu <at> gentoo.org>:
> > On Friday 18 July 2008, Jan Minář wrote:
> > ...
> >
> >> 3. Vulnerability
> >>
> >> During the build process, a temporary file with a predictable name
> >> is created in the ``/tmp'' directory.  This code is run when Vim
> >> is being build with Python support:
> >>
> >> src/configure.in:
> >>
> >>          677         dnl -- we need to examine Python's
> >> config/Makefile too 678         dnl    see what the interpreter is
> >> built from 679         AC_CACHE_VAL(vi_cv_path_python_plibs,
> >>          680         [
> >>          681             tmp_mkf="/tmp/Makefile-conf$$"
> >>   (1)--> 682             cat ${PYTHON_CONFDIR}/Makefile - <<'eof'
> >>
> >> >${tmp_mkf} 683 __:
> >>
> >>          684         @echo "python_MODLIBS='$(MODLIBS)'"
> >>          685         @echo "python_LIBS='$(LIBS)'"
> >>          686         @echo "python_SYSLIBS='$(SYSLIBS)'"
> >>          687         @echo
> >> "python_LINKFORSHARED='$(LINKFORSHARED)'" 688 eof
> >>          689             dnl -- delete the lines from make about
> >> Entering/Leaving directory
> >>   (2)--> 690             eval "`cd ${PYTHON_CONFDIR} && make -f
(Continue reading)

Steven M. Christey | 25 Jul 17:57

Re: [Full-disclosure] Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution


On Fri, 25 Jul 2008, [UTF-8] Jan MináÅ^Y wrote:

> > The commands do not have to be written there between (1) and (2), they
> > can be in the file long before the ./configure was started -- just
> > because the script does care whether it can write to the file at all.
> > So unlike stated in the advisory, and in CVE-2008-3294, the issue does
> > not involve a race condition if the attacker would choose to create a
> > 644 file.
>
> The file gets truncated in (1).  You're wrong, the advisory is right.

Maybe the point here is that if the attacker owns the file and sets 644
permissions, then the truncation won't happen since ./configure won't have
the permissions to modify the file.

- Steve

Re: [Full-disclosure] Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Fri, Jul 25, 2008 at 4:57 PM, Steven M. Christey
<coley <at> linus.mitre.org> wrote:
>
> On Fri, 25 Jul 2008, [UTF-8] Jan MináÅ^Y wrote:
>
>> > The commands do not have to be written there between (1) and (2), they
>> > can be in the file long before the ./configure was started -- just
>> > because the script does care whether it can write to the file at all.
>> > So unlike stated in the advisory, and in CVE-2008-3294, the issue does
>> > not involve a race condition if the attacker would choose to create a
>> > 644 file.
>>
>> The file gets truncated in (1).  You're wrong, the advisory is right.
>
> Maybe the point here is that if the attacker owns the file and sets 644
> permissions, then the truncation won't happen since ./configure won't have
> the permissions to modify the file.

I stand corrected.  I have updated the advisory.  Thanks, Robert.
Thanks to Steven for rephrasing.

Jan.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---


Gmane