[25406] in bugtraq
Nearly undocumented NT security feature - the solution to
daemon@ATHENA.MIT.EDU (KJK::Hyperion)
Thu May 9 02:27:34 2002
Message-Id: <5.1.0.14.0.20020507152125.0279f718@pop3.aldebaran>
Date: Tue, 07 May 2002 22:28:33 +0200
To: <bugtraq@securityfocus.com>
From: "KJK::Hyperion" <noog@libero.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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!
