Date: Fri, 21 May 1999 01:15:11 +0200 From: Tonino Lucca To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Ordinary user can easily surpass profiles quota in NT+SP4 Hi all, File system full in %systemdrive% in Terminal Server can easily be reached by an ordinary user by growing his own profile so denying the logon to all roaming profiles users who don't have locally cached stored copy of their own profile. (Such result can also be reached by growing D:\temp dir, but you can prevent that modifing TEMP and TMP through system policies or modifing TEMP and TMP ntuser.dat hive HKCU\environment values.) Quota profile in SP4 are not effective to prevent growing of user profile, and so %systemdrive% can't be protected >from growing, and logon for roaming user can be denied by anyone. The profile quota in SP4 is supposed to give to administrators the ability to deny, through system policies, the ability to log off to any user who exceeds a specified quota until he/she make profile below the estabilshed quota. In fact article Q185561 says: << Remember that the user will not be able to log off if the user profile quota is exceeded. >> But the user can still log off exceeding the quota, if he kills his own process proquota.exe. *He* is the owner of the proquota.exe process, and not the system. It's very simple to do, unless the task manager is disabled through system policies too. I tried this in NT Terminal Server edition. The problem in Terminal Server may be seriuos because in case of a system full on %systemdrive% drive (wich stores the locally cached copies of actually logged users profiles) the logon will be denied to everyone who doesn't have locally cached copy of his own user profile (virtually all roaming profiles, if deleting locally stored cached copy of user profiles policy is applied). Nevertheless such kind of problems still remains if there will be simply changed the proquota.exe process security environment from user to system, because it comes up only in logoff. So I think Sp4 quota profiles through system policies is not so effective to solve profiles quota and security related problems in NT, and specially in NT Terminal Server Edition. Tonino Lucca (Sysadm.- Milano University) (p.s. sorry for not perfect english) --------------------------------------------------------------------------- Date: Fri, 21 May 1999 16:47:50 +0200 From: Arnt Witteveen To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: Ordinary user can easily surpass profiles quota i n NT+SP4 Tonino Lucca wrote: > File system full in %systemdrive% in Terminal Server can easily be > reached by an ordinary user by growing > his own profile so denying the logon to all roaming profiles > users who > don't have locally cached stored copy of their own profile. > > The problem in Terminal Server may be seriuos because in case of a > system full on %systemdrive% drive (wich > stores the locally cached copies of actually logged users ) This already makes the quota system worthless: a user can (apparently) grow his cached copy, without the profile quota ever intervening. Whether it is copied to the directory where you put the roaming profiles doesn't even matter anymore, since the locally cache profile is on the systemdrive. (This only applies as long as the user is logged on, if you delete the local profiles.) Also, this prompts the following question from me: can you generally solve this kind of problem by putting this directory on another drive and creating a 'shortcut' to it? First test conclusions: any explorer or file/open dialog does support this, any command prompt command like cd does not support this, so I fear this won't work. Any experience with this anyone? BTW: this leads to an even bigger problem I believe: combine this with the filling/growing of the MFT as reported by Vladimir Dubrovin [vlad@SANDY.RU] on 27/04/99 .This means that any user can make the %systemdrive% drive (and/or the drive with roaming profiles) inusable (as in 'reformat needed'!), just by putting a zillion empty files in it! Or am I completely wrong here (for once, I'd love to be wrong ;-) ? (None of this tested, all conclusions drawn from facts stated in cited post.) Arnt Witteveen ------------------------------------------------------------------------ VARTEC NV - Interactive Holstraat 19, 9000 Gent, Belgium Ph. : +32 9 269 99 66 Fax.: +32 9 269 99 69 Visit our web-sites : http://www.vartec.be - the 3D & VR solution provider http://www.adm.vartec.be - inter-, intra- and extranet solutions --------------------------------------------------------------------------- Date: Fri, 21 May 1999 11:19:53 -0400 From: Eric Johnfelt To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: FW: Ordinary user can easily surpass profiles quota in NT+SP4 This is more sinister then you think. (See snippet below) I have been sitting on this a long time because I haven't been able to thoroughly test it, but it appears the cat is out of the bag. I informed MS some time ago that roaming profiles are a DoS waiting to happen. In addition to a user being able to grow his/her own profile to an outrageously large size, they can do far worse. Growing the profile will indeed cause the same problems, but, I doubt any user would intentionally attempt to store 6GBs of hidden data in a profile (assuming you have a system with disk quotas for example) only to find out to their horror that all 6GB gets downloaded to their workstation each time they log in. What the problem is, the permissions needed on the roaming profiles share and the permissions on the file system where the profiles reside. Heres the deal. - Joe-Average NT admin creates a new user with a roaming profile. - Said profile does not get created until the user logs in once and then logs out. - Now the profiles exists. In order for this to work properly, Joe-Average Nt admin will do the following.... ProfileShare (ie %SystemRoot%\Profiles) Everyone:Full Filesystem holding said profile directories Everyone:Full The profiles are created in the users security context, so any difference in this permissions arrangement will cause difficulties (as I have found, although there may be a better solution for this out there). A hacker can pick this one up quick.... md \\server\profileshare\MyHiddenWaReZ attrib +h \\server\profileshare\MyHiddenWaReZ Walla, instant hidden storage, this circumvents having to store anything in the user's profile directory. The problem, if ProfileShare is %SystemDrive%\SomePath, SP3 and Pre SP3 NT servers will BSOD or freeze up when the drive gets filled and the server is prodded into doing something that requires it to swap. I have not tested this against SP4 or SP5 and I've only seen it happen once on a live server [NT 4.0 SP3 (No hotfixes)]. There are apparent solutions to this however, I'm sure there are more. (Like MS changing how or when the profile directories are created). #1. Place a quota system on the system drive. #2. Put the profiles on a non-booting partition or drive. #3. Don't use roaming profiles. #4. Build a home grow convoluted system for creating the user's profile directory on the share, while leaving the root of the share Everyone:R. I reported this a year ago, the response appeared to be they included the profile quota in SP4. Unfortunately that is only half or a solution. They seemed to miss the bigger picture. -----Original Message----- >From: Windows NT BugTraq Mailing List [mailto:NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM] On Behalf Of Tonino Lucca Sent: Thursday, May 20, 1999 7:15 PM To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Ordinary user can easily surpass profiles quota in NT+SP4 Hi all, File system full in %systemdrive% in Terminal Server can easily be reached by an ordinary user by growing his own profile so denying the logon to all roaming profiles users who don't have locally cached stored copy of their own profile. --------------------------------------------------------------------------- Date: Tue, 25 May 1999 17:01:16 -0700 From: David LeBlanc To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: FW: Ordinary user can easily surpass profiles quota in NT+SP4 At 11:19 AM 5/21/99 -0400, Eric Johnfelt wrote: >What the problem is, the permissions needed on the roaming profiles >share and the permissions on the file system where the profiles reside. >In order for this to work properly, Joe-Average Nt admin will do the >following.... > ProfileShare (ie %SystemRoot%\Profiles) Everyone:Full This is NOT a good idea. This will mix the local and roaming profiles. Better to place them elsewhere - if you have a lot of users, then put them on their own partition, and it would even be best to use DFS - then you can redirect them at will without impacting the users. This also opens you up to the ProfileList registry attack Mnemnonix mentioned recently - which is really a lot more severe problem. > Filesystem holding said profile directories Everyone:Full This isn't needed, either. At worst, this could be everyone:C, but it is a lot smarter to make it: admins, system:F everyone:add creator-owner:F >The profiles are created in the users security context, so any difference >in this permissions arrangement will cause difficulties (as I have found, >although there may be a better solution for this out there). Look at the difference between the inherited permissions and the permissions on the container itself. >A hacker can pick this one up quick.... > > md \\server\profileshare\MyHiddenWaReZ > attrib +h \\server\profileshare\MyHiddenWaReZ Only if the hacker has a valid user account on your system. You can't do this without a valid account and password. Note that the same threat exists for _any_ writable share, and these are typically in abundance. >Walla, instant hidden storage, this circumvents having to store anything >in the user's profile directory. If the hacker has a valid account, your miseries have only just begun. >The problem, if ProfileShare is %SystemDrive%\SomePath, SP3 and Pre SP3 NT >servers will BSOD or freeze up when the drive gets filled and the server >is prodded into doing something that requires it to swap. So best practice is to ALWAYS put the OS on a seperate partition from any user-accessible shares. Something else to remember is that you should change where the print spool is kept to a different partition. Note that this is a really common thing to do with any OS - put your critical OS directories on a different partition than where people write. >I have not tested this against SP4 or SP5 and I've only seen it happen >once on a live server [NT 4.0 SP3 (No hotfixes)]. Most operating systems tend to get annoyed when they cannot write to the disk. >There are apparent solutions to this however, I'm sure there are more. >(Like MS changing how or when the profile directories are created). >#1. Place a quota system on the system drive. Or just don't let users access it at all. This is how I always set up servers. >#2. Put the profiles on a non-booting partition or drive. Yup. >#3. Don't use roaming profiles. Or use them only where they are needed. You can do this on a per-user basis. >#4. Build a home grow convoluted system for creating the user's profile > directory on the share, while leaving the root of the share Everyone:R. There is no need for this to be convoluted. You can do it with a batch file. For example: net user %1 /add /domain md \\server\profiles\%1 cacls \\server\profiles\%1 /g administrators:F system:F %1:F I could probably come up with something better if I spent more than a minute. David LeBlanc dleblanc@mindspring.com --------------------------------------------------------------------------- Date: Thu, 27 May 1999 14:01:29 -0400 From: "Steve Craft (ITS_DDI)" To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: re- Ordinary user can easily surpass profiles quota in NT+SP4 - TSE $.02 I inserted some comments here and there as they pertain to Terminal Server Edition with MetaFrame (TSE/MF), since it is pretty different >from a "regular" NT server installation. [sections snipped] > -----Original Message----- > From: dleblanc@MINDSPRING.COM [mailto:dleblanc@MINDSPRING.COM] > At 11:19 AM 5/21/99 -0400, Eric Johnfelt wrote: > > >What the problem is, the permissions needed on the roaming profiles > >share and the permissions on the file system where the > profiles reside. > >In order for this to work properly, Joe-Average Nt admin will do the > >following.... > > ProfileShare (ie %SystemRoot%\Profiles) Everyone:Full > > Filesystem holding said profile directories Everyone:Full > This isn't needed, either. At worst, this could be > everyone:C, but it is a lot smarter to make it: > admins, system:F > everyone:add > creator-owner:F TSE/MF "likes" to keep the profiles in %systemroot%\profiles. My perms look like this: c:\ Auth.Users - Read Admins - Full System - Full c:\wtsrv Auth.Users - Read Admins - Full System - Full Guest - No Access Domain Guests - No Access c:\wtsrv\profiles Auth.Users - Read Admins - Full System - Full Guest - No Access Domain Guests - No Access c:\wtsrv\profiles\all users (and entire subtree) Auth.Users - Read Admins - Full System - Full Guest - No Access Domain Guests - No Access c:\wtsrv\profiles\anyuserthatwashere theusername - Full Admins - Full System - Full TSE/MF creates the profile entry for the user and applied the perms, so they can only modify things inside their own profile. This doesn't keep them from creating a lot of mess in their own directory, however.... > So best practice is to ALWAYS put the OS on a seperate > partition from any > user-accessible shares. Something else to remember is that you should > change where the print spool is kept to a different partition. When you're using a published app on TSE/MF, you are actually using the "C:" drive of the server (your local PC hard drive is mapped to the first available drive letter, starting from "V:" and your local PC floppy is "A:"). So you can't really keep users out of "C:". I have put a lot of time into ACL antics, opening enough of the filesystem to let software run without compromising the server's ability to run. If anyone out there has headaches from the same, throw me an email, maybe we can swap XCACLS routines. %temp% and spooling are on a seperate partition, and the bulk of apps run on a 3rd partition, but there isn't a whole lot to be done about people filling up their own profile in "C:" and making a mess, other than publishing specific applications (ie, not Explorer.exe or Office) and making it generally unintuitive for Joe User to get to his profile directory in the first place. Oh, and I script a nightly purge of the profiles directory. Steve Craft stephen.craft@mail.tju.edu ITS - Desktop Development & Integration Thomas Jefferson Univ. H. --------------------------------------------------------------------------- Date: Fri, 28 May 1999 12:51:33 -0700 From: Shawn Wright To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM Subject: Re: Ordinary user can easily surpass profiles quota i n NT+SP4 On 21 May 99, at 16:47, Arnt Witteveen wrote: > Tonino Lucca wrote: > > > File system full in %systemdrive% in Terminal Server can easily be > > reached by an ordinary user by growing > > his own profile so denying the logon to all roaming profiles > > users who > > don't have locally cached stored copy of their own profile. > > > > The problem in Terminal Server may be seriuos because in case of a > > system full on %systemdrive% drive (wich > > stores the locally cached copies of actually logged users ) > > This already makes the quota system worthless: a user can (apparently) grow > his cached copy, without the profile quota ever intervening. Whether it is > copied to the directory where you put the roaming profiles doesn't even > matter anymore, since the locally cache profile is on the systemdrive. (This > only applies as long as the user is logged on, if you delete the local > profiles.) In addition to this problem (which I wasn't aware of), by Microsoft's own guidelines, the profiles should be kept separate from user home directories to avoid long login delays. But doing this makes the quota system worthless for the purpose of controlling user disk space on the network also. Why is it so hard for MS to implement real quotas which Netware has had for years? Taken from the MS User Profiles FAQ: "Server-based user profiles should never be stored in the root level of a user's home directory. Because every file in the user profile folder is copied over the network for server-based user profiles, storing server-based user profiles in a user's home directory can result in very long logon times. For this reason, user's server-based user profiles should be stored in dedicated user profile folders. However, this dedicated directory can be a subdirectory of the home directory, or some other user directory. Unfortunately, you cannot user the %username% environment variable for the user profile path as %username% does not expand out when text follows it (for example, \\servername\sharename\%username%\ profile)." ======================== Shawn Wright Computer Systems Manager Shawnigan Lake School 250-743-6240 swright@sls.bc.ca