full-disclosure - Security Bug in MSVC

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]

Message-ID: <20060118101110.GB4681@melpomene.jschipper.dynalias.net>
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