Bugtraq mailing list archives
Hide Drives does not work with OUTLOOK 98 - Summary of Answers (W InNT4)
From: Carlos_DeAvillez () STERCOMM COM (DeAvillez, Carlos)
Date: Fri, 24 Mar 2000 11:09:24 -0600
(a copy of this e-mail has also been sent to NTBugTraq) This is a summary of answers I got on this. Summing it all up, it seems that the "Hide Drivers" policy simply does not protect you, no matter what you do, whether you are running Office 97/98/2K, or anything else. Markus Buchhorn [markus () acsys anu edu au] pointed that this seems to be a problem also with Office 2000:
It's a problem in (all of) Office2k as well - Office2k-SR1 mentions a fix:
http://support.microsoft.com/support/kb/articles/q245/0/21.ASP "Q249949 OFF2000: Policy to Hide Drives Ignored in Office Programs " http://support.microsoft.com/support/kb/articles/Q249/9/49.ASP
-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x- Scott Talkovic [satalkov () uci edu] went on a longer discussion:
Users can usually get to the drives using other methods too...for
instance,
within applications such as FTP, or, if available, by clicking on
Start/Run
and typing in the drive letter. I also wouldn't be surprised if someone could also call a batch file that would bring up the "hidden" drives or perhaps, if they can get to a shortcut's properties, use the browse button on the properties sheet (under Change Icon) to browse the drive. They
might
also be able to use Find to find files on a hidden drive if they manually type in the drive letter to search. If it finds something, then they could probably use the "Open Containing Folder" option in the Find tool to get access to the drive. I would verify these possibilities for you, but I
don't
have enough time right now. I do know for a fact that we can use FTP to browse the hidden drives on these workstations. I've done that before. As you can see, it's probably impossible to totally "hide" drives from
users...
Because of this, we always use NTFS and/or share permissions to protect files on the drives. We also only map those drives that are needed at the workstations.
I set up a "Hide Drivers" policy where ALL drivers, except one network drive, would be blocked. I then tested Windows Explorer and indeed only the network driver was visible. But when I started a MsDOS session (cmd.exe), I was put in my system's default path for DOS (C:\WinNT\Profiles\<user>\DeskTop), which should have been blocked (but look at the KB Q249949 above). Hum anyway. I then launched Find Files, and I was able to see all my drivers if I explicitly selected then. Hum. Jos Fotinos [sw_fotinos () hotmail com] also pointed out that:
(...) But opening documents inside word entering c:\ as an adress inside the explorer deliviers simular results.
Thmas Seck [thomas.seck () stadt-bornheim de] also offered another way,
there is a much easier way to circumvent this policy. Use Filemanager (winfile.exe).
16-bit app, leftover from Win3... cool.
Only Explorer and Explorer-based file dialogs care about these registry
keys. And finally Sean Alderman [SAlderman () FREITRATER COM] said:
I use similar restrictions on Windows 9X policies. You may also notice
that
any 16bit File Open API will allow you to see all local and mapped drives. (...) I would suggest checking the other File Open dialogs in apps like Office
and
maybe some 32bit non MS apps. The 16bit dialog does not allow you to perform edit ops like the 32bit dialog does. I have not noticed any
issues
with this in my Office 97 installations. (...)
This seems to be quite broken. As far as I can understand, only the casual user will ever be blocked here. I also wonder if there is any chance of the "Hide Drivers" policy ever working. It is probable that the best (and, perhaps, the only) way of blocking access to different drivers is by using NTFS and acls. Maybe the Office 2000 SR1 will succeed in block it at the Office (application) level, but this is only a minor point here. If I cannot open a document with Office (on a restricted system), I can still ftp it over somewhere else and open it (on a non-blocked system). One might also say this is what happens when security is implemented at the application (user) level, instead of at the kernel level... Regards, ..Calado..
Current thread:
- gpm-root egmont () FAZEKAS HU (Mar 22)
- Re: gpm-root ADAM Sulmicki (Mar 22)
- Trend Micro releases Patch for "OfficeScan Unauthenticated CGI U sage" vulnerability Richard Sheng (Mar 22)
- Re: gpm-root Koblinger Egmont (Mar 23)
- Local Denial-of-Service attack against Linux Jay Fenlason (Mar 23)
- Re: Local Denial-of-Service attack against Linux Michal Zalewski (Mar 24)
- Re: Local Denial-of-Service attack against Linux dapozza (Mar 24)
- Hide Drives does not work with OUTLOOK 98 - Summary of Answers (W InNT4) DeAvillez, Carlos (Mar 24)
- Windows 2000 Internet Server Security Configuration Tool Microsoft Security Response Center (Mar 24)
- Irix Objectserver remote exploit Marcy Abene (Mar 29)
- New ZZ v1.2 Simple Nomad (Mar 29)
- [RHSA-2000:008-01] ircii buffer overflow bugzilla () REDHAT COM (Mar 30)
- Microsoft Security Bulletin (MS00-019) Microsoft Product Security (Mar 30)
- Microsoft Security Bulletin (MS00-021) Microsoft Product Security (Mar 30)
- Napster, Inc. response to Colten Edwards Elias Levy (Mar 30)
- Cobalt apache configuration exposes .htaccess Paul Schreiber (Mar 30)
- Re: Napster, Inc. response to Colten Edwards Danny Crawford (Mar 30)
- Re: Napster, Inc. response to Colten Edwards Dylan Griffiths (Mar 30)
- Re: gpm-root ADAM Sulmicki (Mar 22)