[11968] in bugtraq
Re: Update to ODBC/RDS vulnerabilities
daemon@ATHENA.MIT.EDU (David LeBlanc)
Wed Sep 22 18:14:47 1999
Message-Id: <5F68209F7E4BD111A5F500805FFE35B9180395C9@RED-MSG-54>
Date: Wed, 22 Sep 1999 13:38:17 -0700
Reply-To: David LeBlanc <dleblanc@MICROSOFT.COM>
From: David LeBlanc <dleblanc@MICROSOFT.COM>
X-To: "rfp@WIRETRIP.NET" <rfp@WIRETRIP.NET>, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
> -----Original Message-----
> From: rfp@WIRETRIP.NET [mailto:rfp@WIRETRIP.NET]
> the permissions on these registry keys are Everyone -> Special Access,
> which includes Set Value. This basically means domain users
> can remotely
> disable handler and sandbox restrictions by changing the
> values of these
> keys. Hmmm. I've tested this, and it worked as expected.
You did your testing as an administrator on the machine. Network
permissions for the registry are governed by the permissions on
HKLM\System\CCS\Control\
SecurePipeServers\winreg, and by the 'Machine' value in the AllowedPaths key
below it. Default permissions for winreg key allow only admins to access
the registry remotely. Exceptions to this are the AllowedPaths, which are
governed by the permissions on the keys themselves. HKLM\Software is not on
the allowed paths for either the workstation or the server, so this portion
of what you describe will not work remotely against a default install of
Windows NT unless administrator access has already been obtained.
It is also generally a good practice to place router filters in front of
your internet-exposed web servers such that they cannot make outbound
connections to places where they shouldn't. People who took such
precautions found that things such as the .htr overflow didn't work, and
would prevent your UNC path variant from working. Turning off the Server
and Workstation services, as well as unbinding NetBIOS from the external
interface would also prevent an attack involving an external UNC path from
working.
