Nearly undocumented NT security feature - the solution to executable attachments?

["KJK::Hyperion" <noog () libero it>]

MYTH: Windows NT users cannot defend from e-mail borne malware, because 
unlike in Unix all files in Windows NT are executable, and the only 
protection against this is antivirus software (read on Usenet)

FACT: all files, in Windows NT, are merely executable *by default*. In fact 
not only execution of files can be restricted on a per-file basis, but it 
can be restricted more efficiently than on Unix, and using only features of 
the operating system

Instead of boring you with a lesson on Windows NT security, with the risk 
of ranting all the time against Unix, I'll get straight to the point: 
there's almost NOTHING that Windows NT cannot do, in terms of access 
control. I'll demonstrate this with two examples: system-wide temporary 
directory, and secure attachments directory

EXAMPLE 1: Unix-like /tmp
    I use a lot of Unix-like programs in my everyday work. I had to come 
at a lot of compromises to make them work properly. For example, I renamed 
"Documents and Settings" (the user profiles directory) to "home", set a 
HOME environment variable for all users that points to their profile 
directory, and I used the reparse point feature of the NTFS to achieve a 
single-root filesystem. But something that this system always lacked was a 
functional and secure /tmp directory
    That is, until I understood just a bit more about Windows NT security. 
Unlike I thought, it didn't even require writing code. Just follow some 
simple steps:
 - create, or choose a directory that all users will be able to use as a 
directory for temporary files, without security issues
 - open the properties for the directory, go to the Security tab (or 
whatever it's its name in english versions of Windows)
 - uncheck the "inherit permissions from parent", a warning will pop up, 
choose "remove". This empties the directory's DACL and prevents implicit 
permissions from inheritance
 - grant full access to Administrators, Creator Owner and System, and read 
access to Everyone (use the Add... button)
 - press Advanced
 - double-click on Everyone, select "only the directory" from Applies to, 
check "Create files" and "Create directories" in the "Allow" column, click 
OK. This allows everyone to read the directory's contents, and create files 
and subdirectories inside it, but doesn't allow to read the contents of the 
files
 - double-click on Creator Owner, select from Applies to "only 
subdirectories and files", click OK. This grants full access to every 
account on the files and subdirectories created by that account
 - click Apply, OK
    This should do the trick. Enjoy!

EXAMPLE 2: Secure attachments directory
    I tested this with Qualcomm Eudora, but it shouldn't be hard to apply 
it to all programs that decode and save attachments in a directory, and to 
all programs in general. I'll take advantage of a nearly undocumented 
feature of Windows NT: execute access, like in Unix, is distinct from read 
access. Unlike in Unix, execute access doesn't necessarily apply to 
scripts, we'll see why later
    Eudora, one of the oldest and best mail programs available for Windows 
and MacIntosh, was recently found to have a series of flaws caused by its 
use, when run on Windows, of Microsoft Internet Explorer to view messages. 
In exceptional cases this could lead to executable attachments to be 
sneakily saved in the attachments directory and executed. We'll now see how 
to integrate Eudora's built-in protection (that prevents accidental opening 
of dangerous attachments through the Windows shell) with a lower-level 
approach that uses the native security features of Windows NT
 - locate your attachments directory. If you use Eudora, see 
Tools->Options->Attachments if you don't know this directory's location
 - open the directory's security properties
 - click Advanced
 - click Add, select Everyone, check "Execute files" in the Deny column, 
select "Only files" from Applies to, click OK, click OK. This denies 
execute access to everyone on all files contained in the attachments 
directory and subdirectories
    If you want to try if it works, copy an executable in this directory 
and try to run it. Another kind of directory you may want to apply this 
kind of permissions to are the temporary directories, to avoid executing 
accidentally files inside zip archives: after this, users won't have any 
excuses for having executed mail-borne malware! (please note that this 
could break self-executing setup packages - that is, most of the setup 
packages available for Windows - but users aren't supposed to install stuff 
either)
    You could go even further and remove execute access (don't explicitely 
deny access, as inherited access denied entries cannot be overriden) by 
default on all disks and profile directories except on the program files 
and system directories, but don't overdo it, or you may find yourself with 
an unbootable system
    Restricting execute access will also affect the loading of DLLs. But 
please note that, as I said earlier, this won't stop scripts (except batch 
files) from executing, unlike in Unix. This is due to the different way 
Windows and Unix create processes from scripts. In Unix:
 1. a process calls execlp or execvp to execute the file
 2. the system opens the file requesting execute access, then tries to map 
it into memory. It finds it isn't executable, so it reopens it requesting 
read access
 3. then, the system opens the default command interpreter executable 
requesting execute access, then it maps it into memory
 4. the standard input of the process is set to the descriptor that grants 
read access to the script
 5. control is transferred to the command interpreter's main procedure. 
The interpreter will parse the script and execute the commands it contains
Most systems also allow alternate interpreters to be invoked instead of the 
default, by writing the full path and arguments of the interpreter in the 
first line of the script prepended with #! (sequence known as "hash-bang", 
or "shebang").
    In Windows:
 1. a process calls CreateProcess to execute the file
 2. the system opens the file requesting execute access, then tries to map 
it into memory. If the file is found not to be executable, the file name is 
examined
 3. if the file's extension is CMD or BAT, cmd.exe is invoked with the 
full command line as arguments
 4. otherwise, the file is considered to be a raw DOS executable. The DOS 
emulator creates a code segment in emulated v86 mode and copies the file 
into it, then executes it as a sequence of 16 bit 80x86 instructions
    When you double-click a script in Explorer, in fact, a sophisticated 
wrapper of CreateProcess is used instead, ShellExecute, that determines the 
file type and starts the appropriate program for the requested operation. 
This wrapper, incidentally, is flexible enough to allow Eudora to restrict 
access through it to the files in its attachment directory. Nonetheless, 
regarding scripts, Windows is flawed in several ways:
 - early implementations of ShellExecute only allowed two operations: 
"open" and "print". Only later support was added for operations such as 
"edit", "view", and so on. A "run" or "execute" operation was never 
defined, because it would have broken compatibility with previous versions 
of Windows
 - CreateProcess only creates processes from scripts (thus performing the 
appropriate access checks) when they have the BAT or CMD extension. A 
mechanism similar to the "shebang" used in Unix systems would have been better
 - the documentation for CreateFile doesn't document the GENERIC_EXECUTE 
access, so programmers that write their own script interpreters cannot 
write them secure (that is, by requesting execute access in addition to 
read access, even if it isn't strictly necessary)
    Now that you know, start writing secure programs, and secure your 
systems armed with this knowledge. And spread the word!