Matt,
This is an excellent question because it is one in which we’ve been
ambivalent. Since the kit is source code, our customers will be free to
change this as they see fit. From an implementation standpoint, the
difference is small (to call IoRegisterFileSystem or to not call
IoRegisterFileSystem.) But as you note, there is a structural
difference in how it interacts with filter drivers.
I’m of the opinion (and I tend to hold a fair amount of sway around OSR,
at least in the file systems space) that we should register as a file
system driver in this secondary stack. Thus, other filters will detect
our presence and can choose to layer on top (and thus “see” the
additional I/O).
An interesting issue with security customers (a strong constituency of
those with interest in the DMK - not everyone wants compression support)
is that they often want to break the very rules they complain when
others break. Thus, THEY may not want other filters to “see” what they
are doing. Pull out that registration and suddenly they aren’t visible.
And please note that the concept of not registering as a file system
(even when you are one) is not something we’ve invented. A number of
file systems do not register (originally, the purpose of registration
was to receive mount requests so network redirectors did not
traditionally register, for example. It was the filter team that
piggybacked filter attachment semantics on top of registration and thus
moved to a model where filters rely upon registration.) Several
existing file systems do not register using this mechanism. Indeed,
with the interop issues that arise with filter drivers, it seems there’s
compelling reason *not* to register (anyone remember when the Exchange
IFS team showed up at Plugfest, interop tested and found that nobody
layered over their IFS and left, never to return again?)
Interoperability is going to provide job security in this field for many
years to come. I’ve always tried to encourage solutions that foster
such interoperability - the shadow device object (with its named device
object) is a mechanism for dealing with a serious ill (reentrant
behavior that causes stack overflows and deadlocks) with a much narrower
case (an alternate named path to the volume). As is so often the case
in this business, a fix for one thing creates a new issue.
So, of course, the interesting question is “how do I mitigate against
this new security vulnerability?” In the shadow device case you could
maintain a table that is available to both the main (filtering) path and
the shadow device path. In the main filtering path you add the thread
address to the table. In the shadow device path, you look up in the
table to see if this thread is “authorized” and if not you can assume
this is a potential exploit (suggestion: good time to put a message into
the event log.) Otherwise, you proceed with the operation (removing the
thread from the table before the termination of the operation, of
course.) This greatly narrows the window of vulnerability.
Of course, all of this depends upon your threat model. If you are in a
tightly controlled environment, this probably is a non-issue (you define
everything in the environment because it is being used to control some
custom devices.) If you are in a high threat (hostile) environment then
you’ll be looking at these issues as part of your security evaluation
against your threat models (if you don’t, rest assured that there is a
community of volunteer reviewers who will demonstrate your security
holes to the world.)
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston, MA April 18-21, 2006 (note new date - MS scheduled plugfest the
same week again.)
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Friday, March 03, 2006 10:50 AM
To: ntfsd redirect
Subject: RE: [ntfsd] Shadow devices and security holes?
Tony,
In the DMK kit you are referring to, would other filters on top of your
original filter device then essentially miss the I/O that then goes to
your
controlled fileobject on the new device object (anything other than the
original IRP_MJ_CREATE)? Or, is the new device object under your
driver’s
control essentially an entirely new volume stack that filters would be
expected to attach to? Just curious.
Matt
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Wednesday, March 01, 2006 8:19 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Shadow devices and security holes?
Neal might be able to comment on this further, but my reading here is
that
creating such a named object in this case might result in a couple of
possible issues:
(1) It might bypass other filters in the stack. Suppose you had a chain
of
device objects like:
Filter1->Filter2->NtfsVolume
If Filter2 were to create a *name* then it might be possible to bypass
Filter1 and call directly into Filter2. Since this is likely to be an
unintentional bypass it certainly could create confusion in Filter1 when
it
receives I/O on the file later, since it would really only be the
IRP_MJ_CREATE that bypassed Filter1, not the subsequent I/O operations.
(2) It might make names visible that were not otherwise visible. This
is
similar to what might happen if you just called IoCreateSymbolicLink and
added some Win32 visible name.
(3) It might bypass security checks on the containing object manager
directory. Suppose we had:
\SecureDirectory\SecureDevice and a restrictive ACL on SecureDirectory
(and
let’s turn off SeChangeNotifyPrivilege just to make it REALLY
interesting.) Then you come along and create a filter but just use a
different name like “\Device\MyFilterOverSecureDevice”. Now the
security
check has been bypassed because the open on your device goes through the
normal Device directory and then doesn’t require any sort of specialized
ACL
check - in essence, you have subverted the security.
To mitigate against this, I would suggest using dynamic names. In the
shadow device case you control both ends of the connection (the filter
that
redirects and the driver that creates the named device.) If you
dynamically
generate the name (I like using a GUID) then it will be difficult to
exploit
(since to find your device they’ll have to be able to read through the
directory structure anyway.) There may still be scenarios in which this
is
deemed to be an unacceptable risk, but I’d argue that you probably don’t
want to be using Windows in such environments anyway (at least not with
anything that hasn’t gone through a rigorous security review.)
In our DMK kit we use dynamic names to manage redirection of files.
When we see an IRP_MJ_CREATE on a file (in the filter,) if we wish to do
further processing on it we replace the name and do a STATUS_REPARSE on
it,
sending it to a different driver that we also control. We do this using
dynamic names (well, I should be careful here - this is the technique I
outlined for it, but I didn’t implement this code, so I know how it was
expected to work.)
Theoretically then, someone could open up our device directly by using
our
dynamically generated name, although practically speaking it wouldn’t
yield
anything useful to the caller in this specific case (we’re doing an open
on
the file with the user’s credentials in any case, and our implementation
is
a layered/stackable file system that potentially adds additional
security
checks and encryption.)
There may be other security issues here as well. It may well be that
the
specifics of the attack are something that those who know what it is are
unwilling to discuss for fear that it will be exploited. It wouldn’t be
the
first time that information in this forum has been used to develop
inappropriately behaved applications.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the next OSR File Systems class in
Boston,
MA April 18-21, 2006 (note new date - MS scheduled plugfest the same
week
again.)
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Wednesday, March 01, 2006 6:52 PM
To: ntfsd redirect
Subject: [ntfsd] Shadow devices and security holes?
Hi all,
In the docs for the Win2k3Serv IFS kit, it says the following while
referencing a bit of code that creates a device object for attaching to
a
volume device object in a filter:
************************************************************************
****
*
“In the above call to IoCreateDevice, setting the DeviceName parameter
to
NULL specifies that the filter device object will not be named. Filter
device objects are never named. Because a filter device object is
attached
to a file system or volume driver stack, assigning a name to the filter
device object would create a system security hole.”
************************************************************************
****
*
While trawling the archives, I ran into this bit from Neal Christiansen
on
this thread:
http://www.osronline.com/showThread.cfm?link=62930
************************************************************************
***
"The documentation you are talking about refers to creating a “Volume
Device
Object” (VDO) that a filter uses to attach to volumes and file system
control device objects (CDO). These device objects should never be
named.
Naming them gives an alternate way of accessing a volume which is
unintended
and could cause security issues. Please follow the rules.
The control device object (CDO) for the filter itself should be named.
Unless you have a good reason not to do this you should also specify the
FILE_DEVICE_SECURE_OPEN flag when creating a filters CDO, this prevents
non-admins from being able to open it.
When in doubt about these types of issues please follow what the IFSKit
samples do.
Did this answer your question?
Neal Christiansen
Microsoft File System Filter Group Lead
This posting is provided “AS IS” with no warranties, and confers no
rights."
************************************************************************
****
**
I guess I’m still wondering exactly what the security hole would be.
Anyone
know? Lastly, is there any real difference between this case and the
case
of using a named shadow device to recognize filter re-entrancy, which is
a
widely known/used technique mentioned in the IFS FAQ? The shadow device
is
named, and sends I/O down the volume stack. If it is OK to have shadow
devices, then shouldn’t it be OK to have a named volume filter device?
Where am I going wrong here…
Thanks,
Matt
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send
a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com