Re: RFP9903: AeDebug vulnerability

[dleblanc () MINDSPRING COM (David LeBlanc)]

Going to respond to bits of 3 replies -

At 11:49 PM 10/3/99 -0500, .rain.forest.puppy. wrote:

> > True, but you have to get something to crash that is running as a
> > higher-level user than you are.  I understand that this may be possible,
> > but it is a precondition.

> Understood.  Hmm, now if we could just crash some system processes....

This might indeed be possible, but Murphy's law says that if you're the
hacker, then you probably can't on a given host, and if you're the admin,
it will be trivial, so... 8-)

At any rate, if all you had to do was crash one of your own processes, this
would be a LOT worse.

> > Nope.  This is NOT default.  There is some strange condition involving
> > upgrades from specific versions of NT.  My own workstation had allowed

> Ok, willing to detract default.  I will only inject personal experience,
> which consists of viewing (counting...) 16 NT server installs (SP 3 to SP
> 5 level), and verifying with other people (who had the same permissions).
> So not default, I guess not on workstation, but damn, it does seem to be
> abound.

Todd Sabin just reminded me that I'm wrong.  You're both right.  I was
thinking of something else, and Todd should know, since he's the one who
told me that the other key I'd found writable isn't default and that's
because I'm running a system that hasn't seen a clean install since beta 2
of NT 4.0.  Sorry.

> > A further precondition for pulling this off is that you need to be able to
> > place a binary on the system.  Else changing the registry key gets you
> > nowhere.

> If you can run programs, you can (attempt) to use ftp or rcp to pull files
> in.  I realize this is dependant on outgoing firewall rules, access to the
> commands, etc.  But it's not impossible--these methods have been used by
> many people contacting me on the RDS issue.

Didn't mean to say it was impossible.  Just a pre-condition.  If you can't
for some reason, then this attack won't work.  This is one good reason to
take most of the useful command line utilities out of %systemroot% tree,
put them elsewhere and DACL them to admins:F only.  For a list of the ones
I would move, see the config on the www.hackpcweek.com NT machine.

> As a side note, is there some SeDebug or somesuch privilege?  I have
> deja-vu in recalling it....

Yes, and if you have it, you can inject threads in other processes.  I'll
leave the consequences of this as an exercise to the reader.  By default,
this is admin-only.

> Why the hell is it still an issue at the end of 1999?

I don't know.  I'm looking into it.

> > 5) Make something crash that has higher access rights than you do

> It's NT.  That mean the odds of a blue screen within 2 weeks is pretty
> good.:)

A BSOD won't do.  That's a kernel crash, and it ends up doing different
things.
You've got to make a service go down that won't kill the machine.

> > Yes, there's even a document entitled "Securing Windows NT Installation" on
> > Microsoft's site, and it has been there for quite some time.  It recommends
> > checking the security on this particular key, as well as several others.
> > Steve Sutton's NSA paper mentions it as well.  So does the ISS Scanner
> > documentation.

> Forgive me for thinking that all needed security fixes are handled by
> upgrades, hotfixes, and service packs.  Plus, you need to keep track of
> the oh-so-well-organized MS KB and ever-evolving documents for *extra*
> security fixes not included in the upgrades, hotfixes, service packs, etc.

Yup, same sort of fun you get with every OS out there.  Keeping up with
fixes and tweaks is so much fun.  Not.  I used to have to write software to
figure out whether a given machine had applied all of the above, and it is
sometimes very non-trivial.  Then you get some fixes that just do a binary
patch of a certain file, and unless you want to do a binary diff between
the fixed and unfixed versions...  I'm very glad I don't have that
particular job any longer.

> DAMN!  How will I be able to make 5 releases in Oct when you keep stealing
> all my ideas?

I promise not to steal any of your UNIX-related advisories. 8-)

> I'll just have to get more creative...maybe I'll go through
> the 1994 archives.  I can see it now:  RFP9905 -- problems with
> /cgi-bin/phf.

There we go!

BTW, Pete Deuel suggested just removing the whole key, which makes a
regular pop-up come up.  Seems it solved a problem for him a while back.
Might work - I've never tried it.

One other thing to consider is that when user processes crash, they can
sometimes create a user.dmp file, which like UNIX-style core files can
sometimes contain information useful to an attacker.  There is a way to
turn this off, but I don't recall what it is at the moment.

David LeBlanc
dleblanc () mindspring com