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. |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
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
|
|||
|
|||
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
|
|||
|
|||
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` |
#4
|
|||
|
|||
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. |
#5
|
|||
|
|||
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` |
#6
|
|||
|
|||
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. |
#7
|
|||
|
|||
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` |
#8
|
|||
|
|||
|
#9
|
|||
|
|||
|
#10
|
|||
|
|||
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 | |
|
|
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 08:20 PM |
help with motherboard choice | S.Boardman | General | 30 | October 20th 03 10:23 PM |