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

[3APA3A <3APA3A () SECURITY NNOV RU>]

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 bugtraq () securityfocus 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
Жало мне не понадобится (С. Лем)