Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS
From: Stefan Kanthak (postmaster_at_1.0.0.127.in-addr.arpa)
Date: 01/21/05
- Next message: Roger Abell: "Re: Services snap in & Security"
- Previous message: Karl Levinson, mvp: "Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- In reply to: Gordon Fecyk: "More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- Next in thread: Gordon Fecyk: "Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- Reply: Gordon Fecyk: "Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 21 Jan 2005 08:48:49 +0100
"Gordon Fecyk" <gordonf@pan-am.ca> wrote:
> Thanks to Roger Abel for finding a bug in xcacls.vbs and a workaround to
> this default permissions problem.
Can you be more specific on this bug?
Is a fix available?
> OK, so now it's possible to restrict access to executables through the NTFS
> file system completely, at least in theory. I'd like to know how many holes
> this little net has.
Well, let's see... just some thoughts/comments...
> We have a default installation of 2K Pro or XP Pro, with these folders (some
> hidden) on the %systemdrive% (usually C):
>
> \Documents and Settings
> \Program Files
Do you only support english versions of Windows?
"%AllUsersProfile%\..\" resp. "%UserProfile%\..\" and "%ProgramFiles%" resp.
"%CommonProgramFiles%" will work on all languages :-)
> \RECYCLER
> \WINDOWS or \WINNT (%systemroot%)
>
> The root of %systemdrive% normally has "Everyone - Full Control". I usually
> change it to this ACL:
>
> BUILTIN\Administrators Full Control
> NT AUTHORITY\SYSTEM Full Control
> BUILTIN\Users Read
> BUILTIN\Users List Folder Contents
Do you allow "Guest" access?
If not, then use "BUILTIN\Authenticated Users" instead of "BUILTIN\Users"
(although the group definitions have changed with 2k3).
Since NT4 SP4 I replace "WORLD\Everyone" with "BUILTIN\Authenticated Users"
throughout the whole system (file system and registry).
SubInACL.Exe comes in handy here...
> I don't bother with the Power Users group since it doesn't exist on XP Home,
> and the point is to restrict executable access.
>
> The default ACLs for Documents and Settings, Program Files and %systemroot%
> are fine.
The RASPHONE.PBK in
"%AllUsersProfile%\Application Data\Microsoft\Network\Connections\Pbk\" is
AFAIK world-writeable (at least on 2k)!
Malware (a dialer) might modify or create a RAS entry there.
> I have to create \RECYCLER by playing with the Recycle Bin, but I then copy
> the ACL for \Documents and Settings\All Users\Documents (aka: "Shared
> Documents"). If I have any 16-bit apps I also have to do this to
> %systemroot%\temp.
Do 16-bit apps REALLY use %windir%\TEMP\ instead of %TMP% resp. %TEMP%?
I've never seen this! Do you have the reference to a description handy?
I turn off 8dot3 name creation since NT4, and some (very few) DOS and 16-bit
apps (especially the %&$§* SETUP.EXE from InstallShield) break. And badly
written 32-bit apps might break too, for example some of the media player
hotfixes from MSFT...
> This way, users can still use the Recycle Bin but they
> can't run programs in \RECYCLER.
>
> The resulting ACL for \RECYCLER, %systemroot%\temp and \Documents and
> Settings\All Users\Documents looks like this:
>
> BUILTIN\Administrators Full Control
> NT AUTHORITY\SYSTEM Full Control
> BUILTIN\CREATOR OWNER Full Control for Subfolders Only
> BUILTIN\CREATOR OWNER Special (Full Control except Execute) for Files
> Only
> BUILTIN\Users Read
> BUILTIN\Users List Folder Contents
> BUILTIN\Users Special (Create Files / Write Data,
> Create Folders / Append Data,
> Write Attributes,
> Write Extended Attributes,
> Read Permissions) for This Folder and
> Subfolders
>
> Essentially, users can create and manipulate their own files and folders in
> these places, but still can't launch any executables.
>
> Then I have a script launch on logon - either a domain logon script run
> synchronously or one set through local policy - that executes this:
>
> xcacls.vbs "%userprofile%" /T /E /Q /L /SPEC C /P
> "%userdomain%\%username%":F
> xcacls.vbs "%userprofile%" /T /E /Q /L /G
> "%userdomain%\%username%":12345789ABCD
>
> (assming cscript.exe is the default scripting host, and xcacls.vbs is
> available in the %path%)
Why don't you create a security template and apply this (OK, to write SDDLs
is a pain in the ass, but it's the native way). Windows should reapply it
every now and then...
BTW: . is always the first implicit entry in %PATH%. It's therefore good
practice to write fully qualified pathnames (using %SystemRoot% etc. of
course:-) whereever possible.
> I can repeat those lines with "%homedrive%\%homefolder%" or "%homeshare%" in
> a domain.
>
> Normally %temp% is set to %userprofile%\Local Settings\temp, so it ends up
> with the same restrictions. 16-bit apps have a different %temp% for some
> reason, pointing to %systemroot%\temp. As long as temp filenames don't
> clash (and 16-bit apps clean up after themselves) there shouldn't be a
> problem with two user accounts on one machine.
> (Is there a way to force %userprofile%\local settings\temp for 16-bit apps?
> I mean, it comes up as short filenames anyway!
> "C:\DOCUME~1\USERNA~1\LOCALS~1\TEMP")
See above; and the latter is one of those compatibility settings I REALLY
hate: there a way too many bad written applications that STILL can't
handle spaces in pathnames. If MSFT would only had the guts to cut this one
and ENFORCE all those evil programmers^W^Wlazy bones to fix their flaws.
> Seems pretty crazy, but this only needs to be done once and written to a
> disk image (Ghost or similar). I also usually have a separate 2 GB
> partition for the pagefile with no access at all for BUILTIN\Users, but
> that's a performance decision.
>
> Once done, I have full control (heh) of what BUILTIN\Users are allowed to
> execute. And this ends up being anything installed in %systemroot% or in
> \Program Files. Programs Designed for Windows XP and Win2K seem to work
> without any hiccups in this locked down setup, and individual app folders or
> Registry keys can have different ACLs if needed (ie: Cardscan, MS Photo
> Editor, etc).
What about floppy disks, USB sticks, CDs and DVDs?
> The end results for Limited Users:
>
> EXE files are disallowed
> BAT/CMD files are disallowed if launched from Explorer but not if launched
> from a Command Prompt
> COM files are disallowed
> LNK (Shortcut) files are allowed if they really are shortcuts - EXEs posing
> as LNKs are disallowed
> URL (Internet Shortcut) files are allowed - EXEs posing as URLs just don't
> work
> PIF (MS-DOS Settings) files are allowed if really a PIF pointing to an
> allowed EXE - EXEs posing as PIFs are disallowed
> SCR (screen saver) files are disallowed
> VBS files are still allowed if really VBS
> Other file types defined in %PATHEXT% (including .PL if you have a Perl
> interpreter) are still allowed
> Java applets (with Sun JVM 1.5) are still allowed
> .NET applets not yet tested - where are some I can try?
>
> I haven't tested something like RUNDLL32 evildll.dll yet, but my
> understanding is DLLs are subject to the Execute permission.
You might modify the "KnownDLLs" registry keys... Or set
[HKLM\System\CurrentControlSet\Control\Session Manager]
"SafeDLLSearchMode"=dword:01
at least to avoid loading of "private" DLLs over/instead of system DLLs.
This will also avoid "DoS attacks": place a file named <well-known>.EXE or
or <well-known>.DLL in . and you might be unable to use the real files.
In 2K there are MANY references to system files in the registry with only
their plain filename, not with their fully qualified pathname. And MANY
fully qualified pathnames start "C:\WIN...\" instead of using REG_EXPAND_SZ
with "%SystemRoot%\" or "%SystemDrive%\" or "%ProgramFiles%\".
XP got better, but is still far from beeing completely independent of the
drive letters and hard coded pathnames.
OK, NT is just about 12 years old, that's way to short to get these
annoyances sorted out!
> At first glance, VBS scripts are the worst enemy at this point. The Windows
> Scripting Host doesn't check filesystem ACLs for Execute permissions before
> launching a script. I wish it did. Also, the Command Prompt (CMD.EXE)
> ignores filesystem ACLs when launching batch files.
That's bad! Have you opened a call for these problems?
> Any other potential holes here? I imagine this wold take the steam out of
> executable e-mail attachments, executables in ZIPs, executables delivered as
> a payload in some IE exploit, etc. Couple this with the "NX" capability in
> newer processors (to avoid buffer overflow and stack smash exploits) and
> this oughta be a pretty safe setup.
Stefan
- Next message: Roger Abell: "Re: Services snap in & Security"
- Previous message: Karl Levinson, mvp: "Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- In reply to: Gordon Fecyk: "More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- Next in thread: Gordon Fecyk: "Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- Reply: Gordon Fecyk: "Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
