full-disclosure - Another IE trick (Re: IE sucks : sun java virtual machine insecure tmp file creation)

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: <40EFE3CE.13924.4E18175A@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Another IE trick (Re: IE sucks : sun java
 virtual machine insecure tmp file creation)

"Eric Paynter" <eric@...ticbears.com> wrote:

> I think:
> 
> mount /dev/xxxx /tmp -o noexec
> 
> would reduce the risk significantly. Can you do something equivalent in
> Windows?

You can specifically remove the "execute" permission (depending how you 
handle such things "Traverse Folder/Execute File" or FILE_EXECUTE) on 
the %TEMP% folder.  However, doing so is likely to break all manner of 
stuff, particularly installers that simply expect to be able to 
decompress their archived contents into a dir under %TEMP% and then 
execute one or more of those unpacked files to kick-off the 
installation for real.

Something else that I suspect is a difference between *nix "noexec" and 
the Windows FILE_EXECUTE permission is that the latter does not prevent 
execution of scripts (either Windows "shell scripts" such as .BAT and 
.CMD files, or scripts for any WSH-hosted scripting engines such as 
.JS, .VBS & .PL).  So long as such script files residing in a 
FILE_EXECUTE denied dir (and that have inherited that permission or 
have had it explicitly applied) also have "Read Data" (FILE_READ_DATA) 
and "Read Extended Attributes" (FILE_READ_EA) -- the minimum necessary 
to list their contents with the default shell's "type" command or to 
open them with Notepad -- those scripts can be run.  Somewhat oddly 
(perhaps -- this is Windows after all...) simply trying to invoke them 
from a shell commandline results in an "Access is denied" error (Win2K 
SP4 -- YMMV) yet using a command of the form:

   <script_interpreter> <script_filename>

(e.g. "cscript test.js" or "perl test.pl") or simply entering the 
script's filename into the Start/Run applet or double-clicking the 
script in Explorer sees the script "execute" just fine.  Of course, if 
the decision of whether to execute the contents of a script is left up 
to the interpreter, the flaw here is as much in the interpreter as 
anywhere -- there are obvious parallels with NetWare's "execute-only" 
attribute, which was of course dependent solely on the client-end of 
the connection playing ball for its enforcement to work.

Regards,

Nick FitzGerald