Ordinary users can bypass profile quota in NT SP4, causing logon issues for others.
`Date: Fri, 21 May 1999 01:15:11 +0200
From: Tonino Lucca <[email protected]>
To: [email protected]
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 <[email protected]>
To: [email protected]
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 [[email protected]]
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 <[email protected]>
To: [email protected]
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:[email protected]] On Behalf Of Tonino Lucca
Sent: Thursday, May 20, 1999 7:15 PM
To: [email protected]
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.
<snip snip snip...>
---------------------------------------------------------------------------
Date: Tue, 25 May 1999 17:01:16 -0700
From: David LeBlanc <[email protected]>
To: [email protected]
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
[email protected]
---------------------------------------------------------------------------
Date: Thu, 27 May 1999 14:01:29 -0400
From: "Steve Craft (ITS_DDI)" <[email protected]>
To: [email protected]
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: [email protected] [mailto:[email protected]]
> 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
[email protected]
ITS - Desktop Development & Integration
Thomas Jefferson Univ. H.
---------------------------------------------------------------------------
Date: Fri, 28 May 1999 12:51:33 -0700
From: Shawn Wright <[email protected]>
To: [email protected]
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
[email protected]
`
Transform Your Security Services
Elevate your offerings with Vulners' advanced Vulnerability Intelligence. Contact us for a demo and discover the difference comprehensive, actionable intelligence can make in your security strategy.
Book a live demo