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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dbfc82860807180038p69f2121al20f261de035fb767@mail.gmail.com>
Date: Fri, 18 Jul 2008 09:38:28 +0200
From: "Nikolai Weibull" <now@...wi.se>
To: vim_dev@...glegroups.com
Cc: vim-dev@....org, full-disclosure@...ts.grok.org.uk,
	bugtraq@...urityfocus.com, bugs@....org
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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ