Re: Yet another "get yourself admin rights exploit":
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Yet another "get yourself admin rights exploit":
- To: NTBUGTRAQ
LISTSERV.NTBUGTRAQ.COM
- Subject: Re: Yet another "get yourself admin rights exploit":
- From: David LeBlanc <dleblancMINDSPRING.COM>
- Date: Mon, 22 Jun 1998 22:54:56 -0400
- Comments: To: Paul Leach <paulleMICROSOFT.COM>
- In-Reply-To: <199806230014.UAA08079camel26.mindspring.com>
- Reply-To: David LeBlanc <dleblancMINDSPRING.COM>
- Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
At 05:06 PM 6/22/98 -0700, Paul Leach wrote:
>> -----Original Message-----
>> From: David LeBlanc [mailto:dleblanciss.net]
>> idea to put on the server, but closer examination shows that
>> we're going to
>> break things - for example, ProfileList comes with:
>>
>> Creator/Owner:F
>> Admins:F
>> System:F
>> Everyone:Query, Set Value, Create Subkey, Enumerate Subkey,
>> Notify, Read
>>
>> The paper recommends:
>>
>> QueryValue, Enumerate Subkeys, Notify and Read Control for everyone.
>>
>> If I do this, it means that only admins and people who have
>> logged onto the
>> machine before can log on, since every new user who logs on
>> creates a key
>> here.
>> This particular key should clearly be:
>> Everyone:Query, Create Subkey, Enumerate Subkey, Notify, Read
>> Or possibly Interactive instead of Everyone.
>It's a good suggestion. (But I have to ask:) Which should it "clearly" be:
>Everyone or Interactive? This highlights the problem with this whole
>thicket: nothing is "clear".
Right - but you guys have at least _some_ of the clues! Why is this key on
the allowed paths in the first place? You guys put that there for some
reason. I don't know what it is, but if I knew it would help - say we only
needed to read the root key from the network, then everything below that
could be interactive, and not everyone.
Actually, in this case, I don't see anything in ProfileList which is
required by anyone who isn't logging in locally - if the ACL weren't
screwed up in the first place (remove set value), the only thing "everyone"
would be able to do is enumerate the keys. Nobody but admins and the user
in question has any business even reading the profile path. Unless someone
knows something I don't, I say make this one Interactive.
Surely MS has some sort of test suite that can be run? Maybe not a
full-blown check, but say against all of your own currently shipping major
apps, plus maybe one rev back? You _could_ certify that it will work with
Office.
>> Another thing I'd ask is if MS were aware of this 2 years
>> ago, then why it
>> is still this way? MS has tweaked a number of registry
>> security settings
>> in service packs - why not this one?
>As the white paper says -- because we don't know what it might break. We
>make that kind of change in major releases that go through beta test, and
>where ISVs expect to synch their next release of apps with the system
>release. We _try_ not to break _anything_ in SPs, because that would cause
>people to hesitate to apply them, even when there are other fixes they
>really need.
OK, I'll buy that - except for that you changed permissions on the
HKLM\Software\Microsoft\Windows\Run, and RunOnce keys in SP3. Gave me fits
- I helped find it, then went to put it in the scanner, and couldn't find
anything on our network to show a true positive 8-/ Didn't find one until
I hit a pre-SP3 machine.
At least _some_ of this stuff is clear - everyone really shouldn't have set
value access on other people's profile paths, and everyone shouldn't have
set value access on the debugger.
>> Could perhaps MS provide us with a registry security fixing
>> tool that would
>> update us to known, tested configurations?
>Tested how? Against all 100,000 Windows apps?
Some reasonable subset would be nice. I can't expect a full regression
test, but you have had 2 years...
8-P
Plus, you really ought to be making these sorts of changes in NT 5.0, and
should have some experience and feedback on that by now. Also, this is
really only a major problem on the server due to the allowed paths - how
many of those 100k apps need to run on a server? I try not to install
_anything_ on a server. What about just testing with BackOffice?
I understand that it is also ripe for trojans with serial local users, but
this is a known evil, and not nearly as severe as the prospect of ANY plain
old user changing my profile path to who-knows-what. Or changing my
debugger to notepad just for grins.
BTW, I did do some testing before anyone panics -
1) If you set the profile path to a UNC path, it fails and creates you a
new default profile.
2) Even if you set it to a local path, it still won't load it
3) If it is another path under %systemroot%\Profile, THEN you can get
hosed. Be careful if you allow any plain users remote console access to
the server.
> It doesn't have
>> to be fancy,
>> but the only way we currently have to script registry
>> permission changes is
>> Steve Sutton's tool.
>I will say again "the security configuration editor (SCE) is in SP4".
<joke> Is SP4 known as 'Cairo'??? </joke>
>It is
>such a tool, and it comes with some templates (i.e. scripts), and those
>scripts will have been tested against some apps, but there is no guarantee
>that some or even a small percent (but hence a significant number) of apps
>won't break with any tightening beyond the way Win95 ships. (Yes, I meant
>Win95 -- that's all that the vast majority of ISVs cared about until just
>recently.) Even if only 1% break, that'll be 1000 apps...
I understand that, but the major problem here is the server being attacked
remotely. If we're really worried about locking down NT vs. trojans and
local users, we've got a LOT of work to do. We're all aware of that.
>> Could we possibly examine each of these keys and take a look
>> at just what
>> makes sense and isn't going to break things?
>Exactly what do you mean by "we"? If anyone has suggestions about particular
>keys, I'll pass them by a few folks here to see if they think they'll fly,
>and we'll update the "Securing Windows NT" whitepaper if they pass scrutiny.
We being the denizens of this list - which includes several thousand users
and admins, along with a large number of lurkers at MS. I'll come up with
my best 1st shot tomorrow (6/23) - then everyone can poke at it. The
problem I have is that there are a lot of things that only you guys know.
>> Sigh - I'm going to be writing very weird, complicated
>> registry security
>> checks for the scanner now...
>Weird/complicated => hard to predict the results of changing.
As in it isn't a trivial thing to check a DACL for a complex set of
conditions. We do a lot of testing DACLs to see if they make sense - an
easy one would be to see if any non-admins are allowed to read something
(say the repair directory). I also can't assume I'm dealing with only
variations upon what is put there on install - let's take the profilepaths
key for example - I have to test the parent key for non-admins (except
interactive) being able to create keys, and then I have to test the child
keys to be writable only by admins and their owner. Testing a process
token vs. a DACL to see if access is allowed (normal OS activity) is pretty
easy - but analyzing it to see if it makes sense and account for all the
possibilities isn't especially easy.
David LeBlanc
dleblancmindspring.com
