[12226] in bugtraq
Re: RFP9903: AeDubug vulnerabilty
daemon@ATHENA.MIT.EDU (David LeBlanc)
Tue Oct 12 18:33:30 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <3.0.3.32.19991012113744.043d2760@mail.mindspring.com>
Date: Tue, 12 Oct 1999 11:37:44 -0700
Reply-To: David LeBlanc <dleblanc@MINDSPRING.COM>
From: David LeBlanc <dleblanc@MINDSPRING.COM>
X-To: Mark Dixon <mdixon@TYNDALL.COM.AU>, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <380017C1.A1458682@tyndall.com.au>
At 02:36 PM 10/10/99 +1000, Mark Dixon wrote:
>> > > > >4) Put a binary on the system
[snip]
>> > UNC paths may not work in this instance. Not all paths contained in
>the
>> > registry can be remote. I'd have to test this to be sure,
>I already tested this before I posted. I should have said UNC paths do
>work here.
OK - I hadn't checked this one explicitly, and it is nice to know the exact
parameters of your risk.
>I have a machine which Dr.Watsons reliably when running SRVINFO.EXE
>against a particular host (I haven't figured out why yet...)
Maybe a samba box? Samba will often give things back to Win32 API calls
that NT won't and it can violate the programmer's assumptions. The Net*()
family of APIs all write back a valid pointer to the struct you asked for
if they return success. Samba, OTOH, will sometimes give you back a
success, but decide not to give you any information, so the pointer you
thought was valid is really null, and boom.
>Sure enough when I fired up SRVINFO it crashed and ran the
>executable from the remote share. I was careful to make sure the share
>was being accessed using guest privileges (verified in the security
>log).
Nice to know that - thanks for testing.
>> > that it may be dependent on what user caused the debugger to fire.
> I'm not quite sure what you mean here... true I crashed the process
>as administrator on the machine SRVINFO was running on, but I can't see
>why this should make any difference if I was using an unpriveliged
>account or an Administrator.
It regulates whether the 'debugger' is going to run as an ordinary user or
some higher level user. Means that I can't log on at a student kiosk,
crash my own app and take over the machine.
> If you're refering to whether it would work without a user logged in
>(say a service crash at the logon screen) then you may well be right. I
>haven't tested this. Does the debugger fire when no one is logged in ? I
>imagine it does but I've never seen a Dr Watson at the login screen.
I'd suspect you'd be getting it to run as localsystem at that point.
> At any rate an Administrator logged in at the console is definately
>would be vulnerable to someone using this type of attack to elevate
>privileges. It's just one more reason to not use administrator accounts
>unless you really have to.
Absolutely. There are several other keys in this area where someone might
be able to stir up trouble - see Steve Sutton's NSA paper at
http://www.trustedsystems.com/NSAGuide.htm for additional details.
What I recommend here is:
1) Go set the ACLs on keys in this area to something a bit stronger. If
you're using the Security Configuration Editor, make a template that tweaks
out all of them the way you want them and run around applying it to all
your servers (BTW, you have to be admin to get to this area on a
workstation remotely).
2) I strongly suspect that everyone does not need
HKLM\Software\Microsoft\Windows NT\CurrentVersion in the AllowedPaths value
located at HKLM\System\CurrentControlSet\Control\SecurePipeServers\Winreg.
The thing to do would be to set auditing for the network user on the
CurrentVersion tree, and see if any non-admins really access it. If they
don't, then it is probably safe to remove it from the AllowedPaths value.
I would be really interested in hearing from anyone who has tried this and
what their results are.
David LeBlanc
dleblanc@mindspring.com
