Lucene search

K

nt4+sp4.profile.quota.dos.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 42 Views

Ordinary users can bypass profile quota in NT SP4, causing logon issues for others.

Show more
Code
`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
17 Aug 1999 00:00Current
7.4High risk
Vulners AI Score7.4
42
.json
Report