Remote buffer overflow in DCOM VB T-SQL debugger
BindView Security Advisory
Remote buffer overflow in DCOM VB T-SQL debugger
Issue Date: March 27, 2001
Contact: [EMAIL PROTECTED]
Topic:
Remote buffer overflow in DCOM VB T-SQL debugger
Overview:
Microsoft Developer Studio version 6 installs a world-launchable DCOM
object, known as the VB T-SQL Debugger, which contains an exploitable
buffer overflow.
Affected Systems:
Windows NT and Windows 2000 systems with Microsoft Developer Studio 6
Impact:
Remote attackers without credentials can run arbitrary code on the
target with the credentials of the user currently logged in at the
target.
Details:
Microsoft Developer Studio installs a variety of DCOM components. One
in particular is the "VB T-SQL Debugger Object". It is installed to
run as "Interactive User", which means that when it is launched, it
runs with the credentials of the currently logged on user. It also
allows Everyone to start and access it remotely.
The purpose of this DCOM object is not documented, nor are any of the
methods that it supports. However, by examining the type library that
it includes, the methods and their parameters can be examined. One of
the methods the VB T-SQL debugger provides is the NewSPID method,
which looks like this:
HRESULT NewSPID([in] long spid,
[in] long pid,
[in] BSTR lpctstrDbName,
[in] short cbName,
[out, retval] short* nReturn);
The purpose of this call is apparently to create a new stored
procedure id in the given database, but that's just conjecture.
Anyway, this method contains a classic buffer overflow, due to an
unchecked call to sprintf using the passed in lpctstrDbName. Passing
in a dbname over approximately 128 characters in length will overwrite
the stack frame. From that point, it's relatively easy to return to
an address that will call into the exploit code on the stack. Just
find a "call esp" somewhere in the address space, and return there.
Workarounds:
Remove the Everyone:Launch and Everyone:Access permissions from the VB
T-SQL Appid key under HKCR\Appid. Restrict the permissions to SYSTEM
and Admins only.
Recommendations:
Determine whether the VB T-SQL Debugger Object is installed on your
systems. To do this, run dcomcnfg and look for it in the list of
applications. Alternatively, look for the registry key
HKCR\Appid\{124765aa-7866-11cf-bf3b-00a0d10003fa}. If it exists
either remove it, or restrict the launch and access permissions
specified there.
Install the hotfix from Microsoft.
References:
Microsoft's security bulletin:
http://www.microsoft.com/technet/security/bulletin/MS01-018.asp
Microsoft's Hotfix:
http://msdn.microsoft.com/vstudio/downloads/debugging/default.asp
Microsoft's Knowledge Base article:
http://www.microsoft.com/technet/support/kb.asp?ID=281297
(may take a couple days to appear)
CVE:
The Common Vulnerabilities and Exposures (CVE) project has assigned
the name CAN-2001-0153 to this issue. This is a candidate for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.
Local promotion in NT4's NTLM Security Support Provider
BindView Security Advisory Local promotion vulnerability in NT4's NTLM Security Support Provider Issue Date: February 7, 2001 Contact: [EMAIL PROTECTED] Topic: Local promotion vulnerability in NT4's NTLM Security Support Provider Overview: Due to a flaw in the NTLM Security Support Provider's handling of client requests, it is possible for local users to send requests to the privileged server and make the server execute arbitrary code of the user's choosing. Affected Systems: Windows NT 4.0 up to and including SP6a Windows 2000 is _not_ affected Impact: All Windows NT 4.0 machines are subject to compromise by any user who can log in locally and run arbitrary programs. This could possibly lead to Domain Admin access, if Domain Admin credentials are on the machine. In the case of Terminal Server, it should also be possible to use the credentials of other users on the compromised machine to take actions across the network as those other users. Details: The NTLM Security Support Provider (NTLMSSP) service is found in ntlmssps.dll and is hosted by services.exe. It handles most of the cryptographic calculations behind the NTLM protocol for clients. It listens for client connections on the LPC port at \NtLmSecuritySupportProviderPort. Once a client connects, it sends requests to the NTLMSSP to handle the various steps in the NTLM protocol. The client indicates which function it wants done by putting the proper function number in the first 32bit word of its LPC request to the NTLMSSP. The NTLMSSP then uses this number to index a call table and calls the associated function. The NTLMSSP _does_ perform a check on the function number to verify it's legal, but it does this check incorrectly, treating the index as signed instead of unsigned, so the check can be bypassed simply by making the number negative. So, the client can use more or less any index it wants to, but what can it use to jump somewhere useful? Well, it happens that the NtConnectPort api which is used to connect to \NtLmSecuritySupportProviderPort allows the client to map a shared memory section into the server's address space, and is even kind enough to tell the client what address it was mapped at. The client can then calculate the proper index to call through a pointer in the first 32bits of that section, and put a pointer there to the rest of the section. He can then fill that with whatever code he wants. When he makes the proper request to the NTLMSSP, it will then call through to his code, and execute it as SYSTEM. Workarounds: None known. Recommendations: Install the hotfix from Microsoft, when available. Limit local logon privileges, if possible. References: Microsoft's security bulletin: http://www.microsoft.com/technet/security/bulletin/MS01-008.asp Microsoft's FAQ: http://www.microsoft.com/technet/security/bulletin/fq01-008.asp Microsoft's Hotfix: NT4: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=27804 Microsoft's Knowledge Base article: http://www.microsoft.com/technet/support/kb.asp?ID=280119 (should be available shortly)
BindView advisory: sshd remote root (bug in deattack.c)
Remote vulnerability in SSH daemon crc32 compensation attack detector
---
Issue date: 8 February 2001
Author: Michal Zalewski [EMAIL PROTECTED]
Contact: Scott Blake [EMAIL PROTECTED]
CVE: CAN-2001-0144
Topic:
Remotely exploitable vulnerability condition exists in most ssh daemon
installations (F-SECURE, OpenSSH, SSH from ssh.com, OSSH).
Tested against:
** Vulnerable:
SSH 1.2.x (ssh.com) -- all recent releases
F-SECURE SSH 1.3.x -- all recent releases
OpenSSH prior to 2.3.0 (unless SSH protocol 1 support is disabled)
OSSH 1.5.7 (by Bjoern Groenvall) and other ssh1/OpenSSH derived
daemons
** Not vulnerable:
SSH2 (ssh.com): all 2.x releases
NOTE: SSH2 installations with SSH1 fallback support are vulnerable
OpenSSH 2.3.0 (problem fixed)
SSH1 releases prior to 1.2.24 (vulnerable to crc attacks)
Cisco SSH (own implementation)
LSH (SSH protocol 1 not supported)
** Other SSH daemons: not tested
Overview:
An integer-overflow problem is present in common code of recent ssh daemons,
deattack.c, which was developed by CORE SDI to protect against cryptographic
attacks on SSH protocol.
Impact:
Insufficient range control calculations (16-bit unsigned variable is
used instead of 32-bit, which causes integer overflow) in the
detect_attack() function leads to table index overflow bug.
This effectively allows an attacker to overwrite arbitrary portions of
memory. The altered memory locations affect code that is executed by
the daemon with uid 0, and this can be leveraged to obtain general
root access to the system.
Details:
When the condition described above occurs, a 32-bit local variable,
which is set to 65536 for large input buffers, is assigned to a 16-bit
local variable, effectively causing it to be set to 0. Due to specific
malloc(0) behavior, memory allocation routine will be passed, creating
buffer of size (malloc_usable_size) 12. Next:
for (i = HASH(c) (n - 1); h[i] != HASH_UNUSED;
We can see n-1 here, and n is equal to 0. Because i is an unsigned
32-bit integer, it would cause integer overflow. This code will be
equal to i = HASH(c) 0x. Binary AND operator reduces this
to i = HASH(c). Pointer 'c' is referencing client-provided cryptographic
packet, and HASH function is simply responsible for changing byte
order in input stream.
Then, detect_attack() routine is trying to access h[i], causing
segmentation fault due to table index overflow bug.
To reproduce this condition, run your sshd server on localhost under gdb
with '-d' switch (to avoid forking). Then try (using OpenSSH client -
ssh.com client software crops the login name):
$ ssh -v -l `perl -e '{print "A"x88000}'` localhost
Program received signal SIGSEGV, Segmentation fault.
0x806cfbd in detect_attack ( ..., len=88016, IV=0x0) at deattack.c:138
136 for (i = HASH(c) (n - 1); h[i] != HASH_UNUSED;
We can inspect the table index (SEGV happened during h[i] !=
HASH_UNSIGNED comparsion):
(gdb) printf "%x\n",i
Results may vary with every connection, depending on the entropy seed
used by the client, crypto keys, etc. You can easily produce a wide
32-bit range of indexes by changing client parameters or simply
reconnecting. It is obvious there wouldn't be a problem to specify very
large index that would point outside our table, but will cause address
space wrap to point accessible memory (stack or another segment). Then,
few lines below, in the same loop, we can find following statement:
h[i] = j;
...where j is a simple block counter.
Conclusion:
By carefully preparing encrypted data, an attacker can point used,
accessible memory (that would pass check in line 136 without SEGV), and
then, he will able to alter dword at chosen address, replacing it with
value of j. The attacker can alter stack variables, alter malloc
structures, etc, and attack later due to improper execution of daemon
code. This condition is relatively difficult to exploit, but there are
no technical reasons that would make this impossible.
Currently, we are not aware of working exploits for this vulnerability.
Note that the attacker needs to make a TCP connection from an IP
address for which sshd will enter into a key-exchange dialogue. If the
attacker's packets have a source IP address that is disallowed by
(for example) DenyHosts in the sshd configuration file, the key
exchange will not happen and the attacker will not have an opportunity
to compose the required exploit data.
Solution:
Included are a few patches for various versions/implementations of SSH.
This is not meant to be an all-inclusive list, as there are a number of
implementers of SSH daemons that are not open source. If you *do* have
the source code for SSH, it should be fairly simply to study the patches
below, see what has been done, and patch your own code. Note that this
is a fix for the one issue that
BindView Security Advisory: Local Promotion Vulnerability in Windows NT 4
BindView Security Advisory Local Promotion Vulnerability in Windows NT 4 Issue Date: January 13, 2000 Contact: Todd Sabin [EMAIL PROTECTED] Topic: Problem in NtImpersonateClientOfPort system call on NT 4 Overview: Due to a flaw in the NtImpersonateClientOfPort Windows NT 4 system call, any local user on a machine is able to impersonate any other user on the machine, including LocalSystem. We have written a demonstration exploit which allows any user to spawn a cmd.exe window as LocalSystem. Affected Systems: All Windows NT 4.0 systems up to and including SP6a. We tested our exploit on W2K RC2, and it was not vulnerable. Impact: All Windows NT 4.0 machines are subject to compromise by any user who can log in locally and run arbitrary programs. This may lead to Domain Admin access, if Domain Admin credentials are on the machine. In the case of Terminal Server, it should also be possible to use the credentials of other users on the compromised machine to take actions across the network as those other users. This has not been tested, however. Details: Windows NT includes a mostly undocumented feature called Lpc ports, which are used for making Local Procedure Calls on a machine. One of the system apis used with Lpc ports is NtImpersonateClientOfPort, which allows a server to act in the security context of the client who is calling it. However, the interface to the call lets the server specify which client to impersonate based on process and thread IDs. The kernel does do some sanity checking of the parameters to verify that the call is legitimate, but it's possible to fake it. First it verifies that the port you're trying to impersonate on actually has an outstanding request. This is easy to satify by making a request to it ourselves. Next, it checks that the message ID in the request matches the outstanding message ID in the thread you're asking to impersonate. This is also easy to satisfy, because if a thread is _not_ making a request, it's outstanding message ID will be zero. So, as the server, when the request comes in, we just change the pid and tid to the ones we want, and change the Message ID to 0. Once we're impersonating we can do whatever we want as that user. The pseudo-code for our exploit works like this. There are two threads. Server threadClient thread NtCreatePort NtReplyWaitReceivePort... NtConnectPort... (returns) NtAcceptConnectPort NtCompleteConnectPort NtReplyWaitReceivePort... (returns) NtRequestWaitReplyPort... (returns) modify the LpcMessage received in the request so that the process and thread ids point to the thread we want, and change the message id to 0. NtImpersonateClientOfPort At this point, we're running under the token of the thread we specified above. For our exploit, we choose to impersonate a thread of lsass. The reason has to do with the privileges that lsass has enabled. When impersonating, it seems that the impersonation token only gets those privileges that are _enabled_ in the client at the time of impersonation. Privileges that are disabled in the client, are not put into the impersonation token, even in a disabled state. Now, lsass happens to have the CREATE_TOKEN privilege enabled, so we can impersonate lsass, and use that privilege to create a new token for ourselves based on the lsass impersonation token, but with _all_ privileges enabled. We can then launch another process under that token. So to continue: // get the information about the current token. // TOKEN_USER, TOKEN_GROUP, etc. (esp. TOKEN_PRIVILEGES) NtOpenThreadToken GetTokenInformation // (several times) // Add _all_ privileges to our TOKEN_PRIVILEGES struct // all user space, preparing for NtCreateToken NtCreateToken // with info from the lsass token, except that // all privileges are enabled Finally. We have our token. Now, we can CreateProcessAsUser with that, except that there are a couple more hoops to jump through. CreateProcessAsUser requires more privileges than lsass had enabled, so we don't currently have them, however, our new token does! So, we can just impersonate the new token. But again, that's not enough. CreateProcessAsUser checks for the privileges in the _process_ token, ignoring any impersonation token. So as a final step, we change the new token to be our primary process token. ImpersonateLoggedOnUser NtSetInformationProcess (... ProcessAccessToken ...) CreateProcessAsUser and we're finally there. Recommendations: Install the hotfix from Microsoft. Limit local logon privileges, if possible. References: Microsoft's security bulletin: http
BindView Security Advisory: SSR Denial of Service
Bindview Security Advisory Cabletron SmartSwitch Router 8000 Firmware v2.x Issue date: November 24, 1999 Contact: Scott Blake [EMAIL PROTECTED] Topic: Denial of Service Vulnerability in Cabletron's SmartSwitch Router (SSR) Overview: Cabletron's SSR is a Layers 2-4 routing and switching device with one of the fastest switching architectures in the industry. Attackers can cause the SSR to stop handling any network traffic. Affected Systems: Bindview only confirms the vulnerability in the SSR 8000 running firmware revision 2.x. Due to the nature of the problem, other equipment may be vulnerable, including other manufacturers' products. Impact: A malicious attacker can cause the SSR to stop functioning for as long as the attacker can continue feeding packets to the device. Details: Cabletron indicates that the bottleneck appears to occur in the ARP handling mechanism of the SSR. The SSR appears to only be capable of handling ~200 ARP requests per second. Thus, by initiating network traffic to more than this critical number of IP addresses, an attacker can cause the router to stop functioning while the ARP handler is flooded. In extreme cases, with input rates only available on the local network, it may be possible to corrupt the SSR's configuration with a sustained flood of new IP addresses. The danger in this problem arises from the fact that many perimeter defenses (firewalls) permit ICMP through, which means that remote, anonymous attackers may be able to crash the SSR. Fix Information: Upgrade your SSR firmware to version 3.x: http://www.cabletron.com/download/download.cgi?lib=ssr
