The Bypass Traverse Checking (or is it the Change Notify?) Privilege
Privileges are special security powers that you assign to accounts in Local Policies->User Rights Assignment node of the Local Security Policy editor, secpol.msc. When a user logs in, the Local Security Authority Subsystem process - Lsass.exe - creates a kernel-mode data structure called a token that contains the list of groups the user belongs to and the privileges assigned to their account. Lsass attaches the token to the first process of the logon session and a user’s security identity propagates through their logon session because child processes inherit a copy of their parent’s token. A process must enable a privilege in its token before it can call an API that requires the privilege, so Windows makes copies in order that a process enabling a privilege won’t affect the privilege state of other processes.
You can view the contents of a process’ token in the Security page of the process’ properties dialog box in Process Explorer, as seen below. The grey background seen on some privileges is just Process Explorer’s visual indicator that a privilege is currently disabled.
One privilege you’ll see by default in every token with the “Default Enabled” flag is SeChangeNotifyPrivilege (the second one in the bottom listing of the screenshot). As its name implies, the privilege is required by the Windows APIs that processes can call to request notification of changes to parts of the file system or Registry that they want to monitor. One such process is Explorer, which monitors directories you open for changes so that it can automatically update the display if a directory’s contents change. You can witness this behavior and the underlying file system request by first creating a test directory, running Filemon, and setting an include filter to the full path of the directory:
Then open an Explorer window to the directory and you’ll see Explorer post a change notification request. The result field of the request will remain blank until the process cancels the request or the directory changes:
Scroll Filemon so that the change notification line is visible and then disable autoscroll in the Options menu. Now open a command prompt, set the current directory to the one you created, and enter “echo hello > out.txt”. When you hit the Enter key, Filemon will fill in the change notification request result and Explorer will refresh its window to show the new file. Take away the SeChangeNotifyPrivilege privilege and Explorer would not be able to automatically update.
Now launch the Local Security Policy editor (LSPE) and navigate to the User Rights Assignment node to see the full list of privileges (Note that LSPE shows both privileges and computer access rights in this node). You won’t find SeChangeNotifyPrivilege in the list, or any of other privilege you see in Process Explorer’s security page for that matter. Process Explorer displays internal privilege names whereas LSPE shows more descriptive and user-friendly aliases. Some of the translations are obvious, like the SeShutdownPrivilege, which LSPE represents as “Shut down the system”, but try to find the entry that maps to SeChangeNotifyPrivilege. Never mind, don’t bother. The user right that LSPE maps to SeChangeNotifyPrivilege is “Bypass traverse checking”:
It’s perfectly natural if you’re having trouble fathoming the connection between SeChangeNotifyPrivilege and “Bypass traverse checking”. The two have nothing to do with each other, other than the fact that Windows overloads the same privilege with two unrelated powers. The security system internally names the privilege according to one if its uses, change notification, and LSPE names it by the other, bypass traverse checking.
Put succinctly, bypass traverse checking gives a process the ability to skip security checks on intermediate directories or Registry keys when it opens a file, directory or Registry key. The following experiment, which requires a Windows XP system that has System Restore enabled, graphically demonstrates the privilege. To begin, log on to the system with an account that’s a member of the local Administrators group.
The Windows XP System Restore facility stores restore points in subdirectories of the System Volume Information directory on each volume that have path names formatted as \System Volume Information\_restore{XXXX}\RPn, where XXXX is the Globally Unique Identifier (GUID) of the Windows installation and n is the internal System Restore identifier of the restore point. When you try to navigate into the restore point directory you should be denied opening System Volume Information. That’s because by default the directory only allows access to the Local System account. If you are able to open it then your computer’s OEM modified permissions on the directory after installing Windows and you will need to open the permissions editor and remove access to the Administrators group for the experiment.
Next run Filemon and configure the include filter as “\rp”. Launch the System Restore wizard by opening the Help and Support center in the Start menu and selecting “Undo changes to your computer with System Restore”. Filemon should record accesses to files stored in the System Restore subdirectory as the wizard scans the existing restore points:
Select one of the lines that shows SUCCESS in the result column, double-click, and an Explorer window will open to the corresponding restore point subdirectory. How is that possible when you don’t have access to System Volume Information? Because you have the Bypass Traverse Checking privilege (SeChangeNotify), NTFS only checks the permissions on the directory or file you open, not on any parent directories. You can see further proof of this by running Notepad and entering “c:\system volume information\tracking.log” in the File Open dialog. Even though you have no acess to the parent directory NTFS still lets you open files within it that you do have access to.
At this point you might believe that Bypass Traverse Checking is a security hole, but most of the time security settings on a directory are inherited by files and subdirectories within it. Thus, if a user doesn’t have access to a directory they won’t have access to items within it, even if they happen to know the names of those items, unless someone explicitly grants them access.
So why does Windows assign Bypass Traverse Checking by default? The primary reason is performance. Instead of having to perform access checks potentially multiple times each time a process opens a file, directory or Registry key, it executes only one check per open. Why does Windows overload a single privilege with two uses? My guess is that only someone on the original Windows NT security team would know.
You can learn more about privileges and user rights, including the precise meaning of each one, in the Security chapter of my book, Windows Internals.
Originally by Mark Russinovich on 10/19/2005 3:23:00 PM
Migrated from original Sysinternals.com/Blog
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
There's another reason why Bypass Traverse Checking isn't a security hole. Even if the privilege was disabled, a program could use the (undocumented) capability of opening a file by file-id to open every file on a volume that the user had permissions to; opening a file in this manner doesn't require a directory traversal, leaving the privilege moot. Turning off the privilege would merely provide an illusion of security, so there's no harm in leaving it off.
10/20/2005 11:25:00 AM by Reuven
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
That's not correct: you need the Bypass Traverse Checking privilege to open files by ID.
10/20/2005 2:34:00 PM by Mark Russinovich
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
Interesting. I didn't realize that.
10/21/2005 2:02:00 AM by Reuven
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
Very interesting info. Are these privileges of Windowds NT/2K/XP, legacy of those of VMS, in the early days of Windows NT?
10/21/2005 6:03:00 AM by spool
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
Does this have anything do to with the fact that when you run Explorer (or Internet Explorer) with the RunAs command, directories are not automatically updated ? for example, if you create a new folder, the "new folder" doesn't appear unless you press F5 (using RunAs on Windows XP SP2).
10/24/2005 3:34:00 AM by pennino
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
No, because the runas'd process also has the SeChangeNotify privilege default enabled. I'm not sure why IE and Explorer don't do change notification when executed this way. A Filemon trace shows that they don't even try.
10/24/2005 9:32:00 AM by Mark Russinovich
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
Interesting article. I read somewhere that Bypass Traverse Checking is in Windows only for NT's POSIX compatibility. Dave Cutler, Darryl Havens, Gary Kimura or Tom Miller from “core 12” must know everything about it. Or maybe someone from (for example) Larry Osterman WebLog list (https://blogs.msdn.com/larryosterman/
archive/2004/8/27.aspx).
11/1/2005 11:34:00 AM by Yowie
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
This post has been removed by the author.
11/2/2005 12:37:00 PM by JJ
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
I _thought_ that Bypass Traverse Checking was required to allow a network user to connect to a share where the user does not have permissions at the parent folder.
Example: On a file server the data drive is drive D:. As part of the security lockdown all permissions (except admins full) is removed from the root of the drive. The a folder (let's call it shared)is created, given permissions (auth users: change) and shared out as \\server\shared. My understanding is that without Bypass Traverse checking non administrators would be unable to get to this share because they are denied access at the parent folder.
I just re-tested this and I think it does allow just that.
Thanks Mark for your fantastic work
11/2/2005 12:41:00 PM by JJ
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
You are a corporation's worst nightmare: a customer who knows more about what they are doing than they do.
Keep going...
11/4/2005 4:50:00 PM by bpr1996
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
In response to pennino's comment, I think this has to do with the dual session/profile behavior of runas. Kind of like when a channel splits on efnet...? This is not backed up with anything and is just my take on it.
Nick
11/15/2005 11:26:00 PM by nstaff
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
I have just tried to open
c:\System Volume Information\
from explorer and got "Access is denied".
I used Windows key-R and typed
c:\System Volume Information\tracking.log
and this started notepad showing me the contents of the file.
This is similar to what you get in UNIX when you setup an FTP site to allow people to download files: the folders cannot be read (chmod -x, no directory traversal) but the files can be accessed when the full path name is given.
My lecturer at Uni also had a similar system where he put the coursework files and notes inside a folder in his home directory. Students could only access that folder from his private area (full path had to be given to the ls command line or to cp / vi).
12/30/2005 7:29:00 AM by Francois Genolini
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
good article.
Revoking this right is an invitation to weird & significant issues.
A system with this revoked is a red-flag that a "security" person may have taken some action to make the system "more secure".
If you experience this, don't be surprised if you also encounter acronyms such as GIAC and CISSP.
https://support.microsoft.com/?id=823659
1/6/2006 2:30:00 PM by Anonymous
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
A system with this revoked is a red-flag that a "security" person may have taken some action to make the system "more secure".
I made this mistake once when hardening a Windows NT 4.0 domain controller. I followed Microsoft's security checklist, which provided no background information about the purpose of the settings.
With my VMS and UNIX background, I naively assumed this privilege was limited to directory traversal. I soon discovered its impact on share enumeration, directory update notifications, file streams, and a host of other unexpected side effects. Oh the pain!
Thankfully most of the current references on Microsoft's web site clearly instruct the administrator to leave this user privilege unchanged.
1/12/2006 7:15:00 PM by Anonymous
# re: The Bypass Traverse Checking (or is it the Change Notify?) Privilege
By using non microsoft products, you bypass their security, conversly, you add security by NOT using their products. Example. Enable protected system files to be used by double clicking my computer. Tools, options, views, uncheck hide protected system files, ok. Now try to access c:/System Volume Information folder. Error. Get the freeware senosoft's P3do Explorer and navigate to the folder. Hey, you can see it now and you are a genius for bypassing microsoft security since they do not have any scripts preventing the viewing of the folder. Amen?
2/3/2006 8:08:00 PM by Anonymous