Dear KJK::Hyperion,

Techniques described in this message (among another recommendations on
e-mail security) were described in my presentation on Uninet online
infosec conference on April, 19.

You can find conference logs on
http://infosec.uninet.edu/english/des.eng.html
or on
http://www.security.nnov.ru/articles/uninet/

I disagree that this approach is undocumented. It's just rarely used
in-the-wild and the main reason I see is laziness or weakness of system
administrators.

--Wednesday, May 8, 2002, 12:28:33 AM, you wrote to bugtraqsecurityfocus.com:

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

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

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

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

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

-- 
~/ZARAZA
Æàëî ìíå íå ïîíàäîáèòñÿ (Ñ. Ëåì)

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]