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