A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Storage & Hardrives
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

NetApp Data Ontap 6.5 CIFS security issue



 
 
Thread Tools Display Modes
  #1  
Old February 22nd 04, 01:28 AM
Deadgame
external usenet poster
 
Posts: n/a
Default NetApp Data Ontap 6.5 CIFS security issue

Has anyone seen this? we are new to network appliance, our company
has just decided to start getting these units instead of other SAN/NAS
solutions that would have a windows kernel rather than unix. It
started when one of our developers was alerted to errors in one of
their applications. This application was written in VB and would use
the end user's NTFS permissions to traverse a directory structure.
Our developer would trap for error 50 which would just convieniently
keep the user from seeing directories they did not have access.
It appears the behavior of a CIFS share is a bit different from a real
windows NTFS share, if you know the full path of a file, you can
actually browse the directory structure and even attempt to open the
file, if you do not have rights, you will not be able to open the
file, but you can almost do it. If you type in the full path and file
name the windows client will attempt to open this file using the
associated file type. This produces an error 75 instead of 50. This
is in contrast to a real NTFS share where if you do not have rights to
the directory you cannot see past that directory, the client cannot
even see it by typing the full path and file name in the explorer
address bar. Now I am not a super hacker or anything I don't even
know how much more can be done, but it appears that Windows NTFS Share
is actually more secure than a Ontap CIFS Share.
If anybody knows of a tweak I could try please let me know. I have
opened a case with Network appliance and will be pursuing this with
them at the beginning of the week.
  #2  
Old February 22nd 04, 01:36 PM
Lyle Meier
external usenet poster
 
Posts: n/a
Default

This is the behavior that one would get in NTFS if one applied the bypass
traverse checking
option in the user rights area. The behavior is listed as being needed if
one wants to run
the posix subsystem, so the NetApp behavior is not surprising given its
heritage.

"Deadgame" wrote in message
om...
Has anyone seen this? we are new to network appliance, our company
has just decided to start getting these units instead of other SAN/NAS
solutions that would have a windows kernel rather than unix. It
started when one of our developers was alerted to errors in one of
their applications. This application was written in VB and would use
the end user's NTFS permissions to traverse a directory structure.
Our developer would trap for error 50 which would just convieniently
keep the user from seeing directories they did not have access.
It appears the behavior of a CIFS share is a bit different from a real
windows NTFS share, if you know the full path of a file, you can
actually browse the directory structure and even attempt to open the
file, if you do not have rights, you will not be able to open the
file, but you can almost do it. If you type in the full path and file
name the windows client will attempt to open this file using the
associated file type. This produces an error 75 instead of 50. This
is in contrast to a real NTFS share where if you do not have rights to
the directory you cannot see past that directory, the client cannot
even see it by typing the full path and file name in the explorer
address bar. Now I am not a super hacker or anything I don't even
know how much more can be done, but it appears that Windows NTFS Share
is actually more secure than a Ontap CIFS Share.
If anybody knows of a tweak I could try please let me know. I have
opened a case with Network appliance and will be pursuing this with
them at the beginning of the week.



  #3  
Old February 22nd 04, 09:07 PM
Peter da Silva
external usenet poster
 
Posts: n/a
Default

In article ,
Deadgame wrote:
associated file type. This produces an error 75 instead of 50. This
is in contrast to a real NTFS share where if you do not have rights to
the directory you cannot see past that directory, the client cannot
even see it by typing the full path and file name in the explorer
address bar.


Wouldn't that depend on whether you have traverse checking enabled or not?

And unless I missed something, NTFS doesn't do traverse checking by
default, due to historical requirements for compatibility with older apps.
Odds are NetApp is emulating the historically consistent behaviour for
the same reason.

Given the environment, I would consider this an extremely minor issue in the
overall security posture of a site. The exposure is limited to a low quality
information leak if you're using inherited privileges since the actual
access rights to the files themselves should be the same either way, and
if you really need to enforce rights that broadly and strictly you should
be wearing both belts and suspenders and applying them to the share itself.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`
  #4  
Old February 22nd 04, 09:09 PM
Peter da Silva
external usenet poster
 
Posts: n/a
Default

In article ,
Lyle Meier wrote:
This is the behavior that one would get in NTFS if one applied the bypass
traverse checking
option in the user rights area. The behavior is listed as being needed if
one wants to run
the posix subsystem, so the NetApp behavior is not surprising given its
heritage.


That seems extraordinarily strange, since the normal POSIX behaviour assumes
traverse checking is taking place: I don't know of any traditional UNIX file
system in which it is even possible to bypass traverse checking.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`
  #5  
Old February 22nd 04, 09:23 PM
Deadgame
external usenet poster
 
Posts: n/a
Default

Well, by default and I just checked... Bypass Traverse checking is
applied to:
Administrators
Everyone
Backup Operators
Power Users
Users

This does not allow a user (who has no file/folder permissions) to
type in the full path and filename causing windows to attempt to open
a file with the associated program. However on a Network Appliance,
this appears to be the case. Let me restate that the file does not
get opened.. They get a generic access denied type of error. But the
fact that a user with no permissions can get this far into the file
system is alarming.. And it does break code for programmers who count
on the NTFS rights behaving as expected.
Thanks
Dead



"Lyle Meier" wrote in message ...
This is the behavior that one would get in NTFS if one applied the bypass
traverse checking
option in the user rights area. The behavior is listed as being needed if
one wants to run
the posix subsystem, so the NetApp behavior is not surprising given its
heritage.

"Deadgame" wrote in message
om...
Has anyone seen this? we are new to network appliance, our company
has just decided to start getting these units instead of other SAN/NAS
solutions that would have a windows kernel rather than unix. It
started when one of our developers was alerted to errors in one of
their applications. This application was written in VB and would use
the end user's NTFS permissions to traverse a directory structure.
Our developer would trap for error 50 which would just convieniently
keep the user from seeing directories they did not have access.
It appears the behavior of a CIFS share is a bit different from a real
windows NTFS share, if you know the full path of a file, you can
actually browse the directory structure and even attempt to open the
file, if you do not have rights, you will not be able to open the
file, but you can almost do it. If you type in the full path and file
name the windows client will attempt to open this file using the
associated file type. This produces an error 75 instead of 50. This
is in contrast to a real NTFS share where if you do not have rights to
the directory you cannot see past that directory, the client cannot
even see it by typing the full path and file name in the explorer
address bar. Now I am not a super hacker or anything I don't even
know how much more can be done, but it appears that Windows NTFS Share
is actually more secure than a Ontap CIFS Share.
If anybody knows of a tweak I could try please let me know. I have
opened a case with Network appliance and will be pursuing this with
them at the beginning of the week.

  #6  
Old February 23rd 04, 03:11 AM
Peter da Silva
external usenet poster
 
Posts: n/a
Default

In article ,
Deadgame wrote:
This does not allow a user (who has no file/folder permissions) to
type in the full path and filename causing windows to attempt to open
a file with the associated program. However on a Network Appliance,
this appears to be the case. Let me restate that the file does not
get opened.. They get a generic access denied type of error. But the
fact that a user with no permissions can get this far into the file
system is alarming.. And it does break code for programmers who count
on the NTFS rights behaving as expected.


"get this far into the file system"?

You don't break security in a file system by pushing again and again at
an information leak until something magically changes and access is
granted. And the reason for this leak is clearly related to an attempt
to duplicate a feature of NTFS that *does* have the potential to allow
unintended access to files: "bypass traverse checking" is something that
other file systems do not (and in fact should not) implement.

--
I've seen things you people can't imagine. Chimneysweeps on fire over the roofs
of London. I've watched kite-strings glitter in the sun at Hyde Park Gate. All
these things will be lost in time, like chalk-paintings in the rain. `-_-'
Time for your nap. | Peter da Silva | Har du kramat din varg, idag? 'U`
  #7  
Old February 24th 04, 02:14 AM
Faeandar
external usenet poster
 
Posts: n/a
Default

On 21 Feb 2004 16:28:32 -0800, (Deadgame) wrote:

Has anyone seen this? we are new to network appliance, our company
has just decided to start getting these units instead of other SAN/NAS
solutions that would have a windows kernel rather than unix. It
started when one of our developers was alerted to errors in one of
their applications. This application was written in VB and would use
the end user's NTFS permissions to traverse a directory structure.
Our developer would trap for error 50 which would just convieniently
keep the user from seeing directories they did not have access.
It appears the behavior of a CIFS share is a bit different from a real
windows NTFS share, if you know the full path of a file, you can
actually browse the directory structure and even attempt to open the
file, if you do not have rights, you will not be able to open the
file, but you can almost do it. If you type in the full path and file
name the windows client will attempt to open this file using the
associated file type. This produces an error 75 instead of 50. This
is in contrast to a real NTFS share where if you do not have rights to
the directory you cannot see past that directory, the client cannot
even see it by typing the full path and file name in the explorer
address bar. Now I am not a super hacker or anything I don't even
know how much more can be done, but it appears that Windows NTFS Share
is actually more secure than a Ontap CIFS Share.
If anybody knows of a tweak I could try please let me know. I have
opened a case with Network appliance and will be pursuing this with
them at the beginning of the week.


In 6.4 and up you get the following:

cifs.bypass_traverse_checking on

You can change this by running

options cifs.bypass_traverse_checking off

or using rsh with the same command.

~F
  #8  
Old February 24th 04, 02:16 AM
Faeandar
external usenet poster
 
Posts: n/a
Default

On Tue, 24 Feb 2004 01:14:28 GMT, Faeandar wrote:

On 21 Feb 2004 16:28:32 -0800, (Deadgame) wrote:

Has anyone seen this? we are new to network appliance, our company
has just decided to start getting these units instead of other SAN/NAS
solutions that would have a windows kernel rather than unix. It
started when one of our developers was alerted to errors in one of
their applications. This application was written in VB and would use
the end user's NTFS permissions to traverse a directory structure.
Our developer would trap for error 50 which would just convieniently
keep the user from seeing directories they did not have access.
It appears the behavior of a CIFS share is a bit different from a real
windows NTFS share, if you know the full path of a file, you can
actually browse the directory structure and even attempt to open the
file, if you do not have rights, you will not be able to open the
file, but you can almost do it. If you type in the full path and file
name the windows client will attempt to open this file using the
associated file type. This produces an error 75 instead of 50. This
is in contrast to a real NTFS share where if you do not have rights to
the directory you cannot see past that directory, the client cannot
even see it by typing the full path and file name in the explorer
address bar. Now I am not a super hacker or anything I don't even
know how much more can be done, but it appears that Windows NTFS Share
is actually more secure than a Ontap CIFS Share.
If anybody knows of a tweak I could try please let me know. I have
opened a case with Network appliance and will be pursuing this with
them at the beginning of the week.


In 6.4 and up you get the following:

cifs.bypass_traverse_checking on

You can change this by running

options cifs.bypass_traverse_checking off

or using rsh with the same command.

~F


Clarification: this option does not affect unix security style qtrees,
only ntfs security style.

~F
  #9  
Old February 29th 04, 09:55 PM
Deadgame
external usenet poster
 
Posts: n/a
Default

Well your reaction appears to be typical of the support call I had. I
finally was able to explain it to them so they could duplicate this
anomoly themselves and see the proof for themselves. I am not sure we
are even talking about the "bypass traverse" thing. I am talking
about a clear and simple difference between the way CIFS lets your
windows client OS see what type of file is behind a folder that you
supposedly do not have access.
test
use a real Windows NTFS SHA
create folder "TEST"
go into folder
create file "test.txt"
go back up a level
right click on the "TEST" directory click properties
go to security tab, click advanced
remove inherited permissions
remove any other permissions (there shouldn't be any)
at this point, you shouldn't be able to get into that folder,
let's say you mapped the share as F:
type F:\TEST\test.txt
you get your access denied, no associated programs will start, you
cannot see or tell what files could even be in this directory. You
get this even if you have the right to "bypass traverse checking" I
know because I made no changes in my OS setup and it was already
allowed. This has no impact whatsoever.

try this same excercise above with a netapp CIFS share, notepad will
open because your windows client can clearly see that the file is
there and knows that it is associated in windows as a notepad txt
file. Your eyes may not see at the windows explorer level but I
suspect someone more clever than I might be able to break in. Also,
you can traverse the directories if you are in explorer mode.. if
there are further sub-directories you can see them even the names of
them although you wont be allowed in them. The windows NTFS shares do
not behave this way. I tried it in windows NT, 2000, XP, 2003, Active
Directory and NT4 domain using administrator accounts and I was not
able to reproduce this anomoly.

Safe or not, the behavior is most definitely different than a real
NTFS share and it does break programming code that traps for errors
relating to NTFS permissions. In my case one of our programmers was
able to make the change (they added trap for error 75 in addition to
50) so in the long run, no harm was done.

....and I wasn't talking about pushing again and again in the exact
same way. That is deliberate flame bait.
I just think that if there is a vulnerability someone may be able to
find a way to exploit it. Just because I don't know how, doesn't mean
someone else couldnt find a clever way to slip through the crack.
There may possibly be more information that could be seen that I can't
see at first glance.


(Peter da Silva) wrote in message ...
In article ,
Deadgame wrote:
This does not allow a user (who has no file/folder permissions) to
type in the full path and filename causing windows to attempt to open
a file with the associated program. However on a Network Appliance,
this appears to be the case. Let me restate that the file does not
get opened.. They get a generic access denied type of error. But the
fact that a user with no permissions can get this far into the file
system is alarming.. And it does break code for programmers who count
on the NTFS rights behaving as expected.


"get this far into the file system"?

You don't break security in a file system by pushing again and again at
an information leak until something magically changes and access is
granted. And the reason for this leak is clearly related to an attempt
to duplicate a feature of NTFS that *does* have the potential to allow
unintended access to files: "bypass traverse checking" is something that
other file systems do not (and in fact should not) implement.

  #10  
Old February 29th 04, 09:57 PM
Deadgame
external usenet poster
 
Posts: n/a
Default

Thanks, I will give this a try!


Faeandar wrote in message . ..
On 21 Feb 2004 16:28:32 -0800, (Deadgame) wrote:

In 6.4 and up you get the following:

cifs.bypass_traverse_checking on

You can change this by running

options cifs.bypass_traverse_checking off

or using rsh with the same command.

~F

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Modem connection speed Neil Barnwell General 58 July 14th 04 07:18 PM
Sata and Data Corruption Robert Neville General 7 April 25th 04 11:02 AM
Maximum System Bus Speed David Maynard Overclocking 41 April 14th 04 10:47 PM
2nd Hard Drive Disappears After Standby/hibernatio, Partition Magic Issue? wrt General 1 December 5th 03 09:20 PM
help with motherboard choice S.Boardman General 30 October 20th 03 10:23 PM


All times are GMT +1. The time now is 02:22 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.