Re: More Before-The-Fact-Isms II, blocking viruses and spyware through NTFS
From: Stefan Kanthak (postmaster_at_18.104.22.168.in-addr.arpa)
Date: Sat, 22 Jan 2005 20:20:31 +0100
"Gordon Fecyk" <firstname.lastname@example.org> wrote:
Hmm... your OLEXP breaks lines, the quoting is weird!
> > Can you be more specific on this bug?
> > Is a fix available?
> When you manually specify all of the ACL flags, it seems to work as though
> "E" is really the inverse of "E":
> > Xcacls.vbs "%userprofile%" /T /E /Q /L /G
> This behaves as though you didn't specify "E", but issuing this:
> > Xcacls.vbs "%userprofile%" /T /E /Q /L /G
> ...without the "E" assumes you've issued E. The E flag seems to be treated
OK, I read this some time ago in another thread, but thought "there must be
> > > OK, so now it's possible to restrict access to executables through the
> > > file system completely, at least in theory. I'd like to know how many
> > > 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
> > > hidden) on the %systemdrive% (usually C):
> > >
> > > \Documents and Settings
> > > \Program Files
> > Do you only support english versions of Windows?
> > "%AllUsersProfile%\..\" resp. "%UserProfile%\..\" and "%ProgramFiles%"
> > "%CommonProgramFiles%" will work on all languages :-)
> For the purposes of this thread, you can assume that the non-English
> equivelants work. Though, is \RECYCLER called something else on non-English
It's \RECYCLER\ in all the languages I've seen yet (else I would have
> This makes me think how many English applications break when faced with the
> non-English folder names. Do they bother checking the environment or APIs
> for the correct names? Hmmmm...
Almost all bad written applications (the most of them are installers,
followed by games!) don't break, they just completely ignore the environment
(which doesn't mean "environment variables" only here) and use (or create)
"C:\Program Files\". The vast majority of these bad written applications comes
from english speaking programmers...
Hard-coded pathnames are awful, evil, ...
This reminds me of one omission in my first post: to stop some viruses from
spreading I'm using \WINDOWS.NT4\, \WINDOWS.NT5\ and \WINDOWS.XP\ for the
In addition there even ain't a C: drive on some of my machines! CodeRed and
Nimda failed on these machines even when unpatched.
> > Do you allow "Guest" access?
> Well, the intent is to restrict executable use on the machine. I suppose
> swapping builtin\users with builtin\authenticated users would be OK, but my
> understanding was if the machine was part of a domain, the Domain Users
> global group is only added to builtin\users.
It's just that "Guest" was (before XP) part of "BuiltIn\Users", but never
part of "BuiltIn\Authenticated Users".
> If someone needs guest access I'd just as soon create my own "guest" account
> on the machine or in the domain.
> > 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.
> ooh, nasty. Only if the dialer can't run in the first place because Execute
> permissions were restricted to installed apps, it seems moot.
Correct. But your users might use NOTEPAD.EXE and modify phone numbers too.
> > > I have to create \RECYCLER by playing with the Recycle Bin, but I then
> > > 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?
> In Win2K SP4, launch a 16-bit app (such as command.com) that can spawn other
> processes. Have it spawn CMD.EXE and check the resulting environment of the
> launched command prompt. %TEMP% and %TMP% change to %systemroot%\temp. I
> don't believe this happened in Win2K SP3 or earlier (nor do I have access to
> a SP3 machine to check at the moment).
Sorry, but this is wrong. I can't reproduce it here (on more than one system).
> In command.com's case, you can check the environment straight up before
> launching anything from it.
Nope, TMP and TEMP are just as expected %UserProfile%\Local Settings\TEMP!
> I have no clue what's really doing this or where the setting is to change
> this behaviour back to pre-SP4 (%userprofile%\local settings\temp).
But look into %SystemRoot%\SYSTEM32\AUTOEXEC.NT and/or the "autoexec" file
specified in %SystemRoot%\_DEFAULT.PIF: do you set TMP and TEMP there?
Since a side-effect of Disable8dot3NameCreation is that some 16-bit apps
fail either due to the spaces in or the length (>64) of %TEMP% setting it
in AUTOEXEC.NT seems a good idea!
> > > 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
> > is a pain in the ass, but it's the native way). Windows should reapply it
> > every now and then...
> Ahh... that's just it! There IS NO SECURITY TEMPLATE for %userprofile% to
> create or edit...
> I once tried monkeying with group policy to define the ACLs for
> %userprofile%. I can do so for such things as %systemdrive%,
> %systemdrive%\RECYCLER, etc, but once I specify %userprofile% it expands
> whatever %userprofile% has at that moment and doesn't take any effect over
> other users. It would have made my life soooo much easier if I could just
> specify it in a template.
> My guess is whatever defines the ACL for a new %userprofile% is hard coded
> to administrators, system and %userdomain%\%username%.
> > What about floppy disks, USB sticks, CDs and DVDs?
> I already remove floppies and CD-ROMs from machines where they're not needed
> (PIPEDA regulations in Canada - all transfer of personal information must be
> audited). If I had my way, I'd also rip off USB connectors. The ones on
> the front come off easily from most PC cases, but the back ones are another
> matter and I wish MB makers made boards with detachable USB connectors.
> I'm sure the American NSA orders systems without USB connectors for this
> Alternately, I'd find some way to restrict loading the Mass Storage driver.
> Apparently, limited users aren't forbidden from activating the Mass Storage
> driver used by most USB sticks and other memory devices. Disabling "load
> and unload device drivers" doesn't help.
Deny ALL access to %SystemRoot%\INF\USBSTOR.INF before attaching the first USB
> > > 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.
> That could break a LOT of stuff that Microsoft already certified as Designed
> for XP. But maybe LoadLibrary[Ex]() already checks filesystem ACLs? I
> can't read documentation that says it does or not. If it did, it would
> cover ActiveX controls, too.
I'm using SafeDLLSearchMode on W2K without negative impact.
On 2K3 this setting is already standard!
> > > At first glance, VBS scripts are the worst enemy at this point. The
> > > Scripting Host doesn't check filesystem ACLs for Execute permissions
> > > 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?
> Technically, these aren't Win32 binaries. Which is stupid, because they can
> cause damage (especially VBS with full access to the Win32 API). It's also
> interesting that explorer.exe checks filesystem ACLs on BAT and CMD files
Hmmm... I don't think that EXPLORER.EXE checks ACLs, it's the API called
from Explorer. Just have a look at HKCR\batfile\shell\open\command: the
string is %1 %*, i.e. Explorer passes the (path)name of the *.BAT/*.CMD
to whatever API it calls.
There was an interesting entry in Raymond Chen's Blog about how Explorer
tries to deduce whether to pass long or short filenames in %1 to called
> where cmd.exe does not (and never mind command.com checking ACLs on BAT
> I still have a support ticket open on the original %userprofile% ACL
> problem, and I brought this up with the techs already. Hopefully they will
> correct this.
> But it might just be specific to Win2K. If you remove or deny Execute from
> a VBS file on XP, what happens?
Access denied, in all cases: "Open" in Explorer as well as [CW]Script.Exe *.vbs