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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 18 Jul 2008 09:38:28 +0200
From: "Nikolai Weibull" <now@...wi.se>
To: vim_dev@...glegroups.com
Cc: bugs@....org, vim-dev@....org, full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com
Subject: Re: Vim: Insecure Temporary File Creation During Build: Arbitrary Code Execution

On Fri, Jul 18, 2008 at 00:54, Jan Minář <rdancer@...ncer.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
output to stderr anyway (in which case it should be suppressed?))

I'm not sure if this requires too much from make and sh, though.  It
works with Bash's sh emulation.