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: Wed Jan 18 10:11:18 2006
From: j.schipper at math.uu.nl (Joachim Schipper)
Subject: Security Bug in MSVC

On Tue, Jan 17, 2006 at 02:25:11PM -0800, Morning Wood wrote:
> ------------------------------------------------------------
>      - EXPL-A-2006-002 exploitlabs.com Advisory 048 -
> ------------------------------------------------------------
> 
>               - MSVC 6.0 run file bug -

> IMPACT
> ======
> The impact of this is quite severe, as it is possible to script
> commands such as to launch ftp, retrieve and execute a file from
> a remote location.

> 1.a
> ====
> InputPath=.\Release\hello.exe
> SOURCE="$(InputPath)"
> 
> "hello.exe" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
>  calc
> 
> 1.b
> ====
> PostBuild_Cmds=notepad.exe

> SUGGESTED PATCH
> ===============
> Include a dialog box that warns the user, before pre and post
> build directives can be launched, if the presence of execute
> directives exist in the build project files.

Well, if that's an undisclosed vulnerability, let me be the first to
note that Makefiles and pretty much any other build mechanism I know of
allow the same.

For very good reasons - quite a few programs cannot be built without
this functionality. It is a well-known fact that one should not run make
on an untrusted makefile, as it can do whatever it pleases. Is the
Windows world truly so backward as to not have 'discovered' the Windows
analogue earlier? I find that hard to believe.

In all this, I am discounting the fact that if someone is building
untrusted sources, (s)he is most likely going to run the untrusted
program afterwards.

In short - I think this functionality is useful, I don't see the
vulnerability, and I don't want to believe that nobody figured out that
arbitrarely running project files is about as bad an idea as arbitrarily
running anything else.

		Joachim

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ