What is the correct order for installing this patch in conjunction with the hotfix discussed in 317748?
This security patch does not contain a patch from Knowledge Base Article 317748 that is required to ensure normal operation of SQL Server 2000 and MSDE 2000. The correct order of installation is to install the 317748 patch and then this security patch. If you have applied this security patch to a SQL Server 2000 or MSDE 2000 installation prior to applying the hotfix from Knowledge Patch article 317748, you must answer "no" if and when prompted to overwrite files to ensure that you do not overwrite files from the security patch.
How do I check I've got this security patch installed?
You should verify that the version of ssnetlib.dll in the \MSSQL\BINN folder for the instance you applied the patch for is: 2000.80.636.0
If the version of the ssnetlib.dll in the \MSSSQL\BINN folder is less than 2000.80.636.0, then you will need to re-apply the security patch. However Microsoft recommends that you apply the latest security patch as described in MS02-061 since this contains fixes for additional security vulnerabilities in these products.
What vulnerabilities does this patch eliminate?
This patch eliminates three vulnerabilities, both involving the SQL Server 2000 Resolution Service:
• | The first two vulnerabilities could enable an attacker to gain significant, and perhaps complete, control over an affected SQL Server. |
• | The third vulnerability could enable an attacker to cause two affected SQL Servers to engage a never-ending information exchange, for the purpose of slowing the performance of the servers. |
What is the SQL Server 2000 Resolution Service?
SQL Server 2000 introduces the ability to install multiple copies of SQL Server on a single machine and have it appear that the copies are completely separate database servers. These copies, known as instances, run independently of each other. The default instance listens on TCP port 1433. Other instances cannot share this same port and require a port of their own.
The challenge is how to enable SQL Server clients to find the port that a particular instance is operating on; the solution is the SQL Server Resolution Service. The first instance on a SQL Server always operates over port 1433. Additional instances are allocated their own port numbers dynamically. When a SQL client needs to connect to an additional instance on the SQL Server, it queries the SQL Server Resolution Service (which operates on UDP port 1434), which tells it which port the requested instance is using.
Is the UDP 1434 port typically blocked at the firewall?
It depends on the particular deployment scenario.
• | If a network doesn't host any Internet-connected SQL Servers, the port associated with the SQL Server Resolution Service (and all other ports associated with SQL Server) should be blocked. |
• | If a network offers SQL Server services to the Internet but there's only a single instance on the server, the SQL Resolution Service can and should be blocked. |
• | If a network offers SQL Server services to the Internet and has more than one instance, the SQL Resolution Service must be accessible through the firewall. |
Does the SQL Server Resolution Service exist on previous versions of SQL Server?
No. Previous versions of SQL Server didn't support multiple instances, and the SQL Server Resolution Service didn't exist. As a result, no other versions of SQL Server are affected by the vulnerabilities.
The Affected Versions section says that Microsoft Desktop Engine (MSDE) is also affected by these vulnerabilities. What is MSDE?
MSDE is a database engine that's built and based on SQL Server 2000 technology, and which ships as part of several Microsoft products, including Microsoft Visual Studio and Microsoft Office Developer Edition. There is a direct connection between versions of MSDE and versions of SQL Server. MSDE 2000 is based on SQL Server 2000.
Buffer Overruns in SQL Server Resolution Service (CVE-CAN-2002-0649):
What's the scope of this vulnerability?
There are actually two vulnerabilities here, both of which are buffer overrun vulnerabilities. An attacker who successfully exploited either vulnerability could gain the ability to cause the server to fail, or to run code using the privileges of the SQL Server.
Although exploiting the vulnerabilities would grant the attacker full control over the database, it would not necessarily convey full control over the system itself. SQL Server 2000 can be configured to run with varying levels of privilege; by default, it runs with the privileges of a domain user, rather than an administrator.
What causes the vulnerabilities?
The vulnerabilities result because a pair of function offered by the SQL Server Resolution Service contain unchecked buffers. By sending a specially formatted request to UDP 1434 port, it could be possible to overrun the buffers associated with either of the functions.
What would this vulnerability enable an attacker to do?
The vulnerability could enable an attacker to take either of two actions:
• | Cause SQL Server to fail. This would be the easiest type of attack to mount, and would require only that the attacker overrun the buffer with random data. |
• | Modify the functioning of SQL Server, in order to perform functions of the attacker's choosing. This would require that the attacker overrun the buffer with precisely chosen data. |
Who could exploit the vulnerability?
Any user who could deliver a request to the SQL Server (over UDP port 1434) on an affected server could exploit the vulnerability.
If the attacker exploited the vulnerability to cause SQL Server to fail, what would the administrator need to do in order to restore normal operation?
The administrator could resume normal operation by restarting the SQL Server service.
If the attacker exploited the vulnerability to cause SQL Server to perform functions of his choice, what privileges would the attacker's code run in?
Clearly, the attacker's code would have full control over the database functions, since it would run in the security context of SQL Server itself. But it might have few privileges outside of SQL Server. During SQL Server 2000 setup, the administrator must choose what Windows account SQL Server should run within. By default, the SQL Server service runs as a Domain User. If best practices were followed and a normal user context was chosen, the attacker would not gain administrative control over the operating system, nor administrative privileges over the domain.
How does the patch eliminate the vulnerabilities?
The patch ensures that the SQL Server Resolution Service correctly limits the size of input data and prevents it from overrunning any of its buffers.
Denial of Service via SQL Server Resolution Service (CVE-CAN-2002-0650):
What's the scope of this vulnerability?
This is a denial of service vulnerability. An attacker could use the vulnerability to slow the performance of an affected SQL Server. The precise amount by which the system's performance would be slowed would depend on a number of factors, such as the processor speed and memory on the SQL Server, the number of systems attacking the server, and so forth.
The vulnerability could not be used to cause the server to fail altogether, nor would it provide the attacker with any privileges on the system. The server would resume normal operation as soon as the attack was broken off.
What causes the vulnerability?
The vulnerability results because of a flaw in the SQL Server 2000 keep-alive mechanism,which operates via the Resolution Service. If a particular data packet is sent to the SQL Server 2000 keep-alive function, it will reply to the sender with an identical packet. By spoofing the source address of such a packet, it would be possible to cause two SQL Server 2000 systems to start an endless cycle of packet exchanges.
What's the keep-alive function in SQL Server 2000?
SQL Server 2000 includes a mechanism by which it can determine whether a server is active or not. It does this by sending a so-called keep-alive packet to the SQL Server Resolution Service on UDP port 1434 and listening for a reply.
What's wrong with the implementation of the keep-alive function in SQL Server 2000?
It's possible to create a keep-alive packet whose response will be identical to the request. If one SQL Server were to send such a packet to another SQL Server, they would enter an unending cycle of sending the same packet back and forth to each other. This activity could consume most or all of the available bandwidth on the two machines.
Could this situation occur naturally?
No. The situation involved in the vulnerability could not occur under normal conditions. SQL Server does not normally generate a keep-alive packet with the needed characteristics. However, it could be possible for an attacker to introduce such a packet in order to initiate an exchange, which would thereafter be self-sustaining.
How might an attacker do this?
Suppose there were two SQL Servers with the vulnerability, Server 1 and Server 2. Now suppose the attacker created the needed keep-alive packet and modified the source address so that it contained Server 1's address, then sent the packet to Server 2. This would initiate the exchange, because Server 2 would reply to Server 1, which would reply to Server 2, ad infinitum.
What could this vulnerability enable an attacker to do?
An attacker could use this vulnerability to consume resources on two SQL Server 2000 systems at the same time.
Who could exploit the vulnerability?
Any user who could send data to an affected SQL Server's Resolution Service port could exploit the vulnerability.
How long would an attack last?
Once started, an attack would continue until one of the machines stopped sending packets. This could happen because the system had been rebooted, the SQL Server service had been restarted, or connectivity between the two servers had been lost.
Once the attack was over, would the server resume normal operation by itself?
Yes.
How much of a system's resources could be monopolized through such an attack?
It would depend on the specifics of the attack. For instance, it would be possible to engage multiple servers in an attack against a single one. Likewise, it would depend on the network bandwidth between the systems, the processor speed on the respective machines, and so forth.
How does the patch eliminate the vulnerability?
The patch eliminates the current keep-alive mechanism, and determines which servers are active and which are passive via a different mechanism. After applying the patch, a SQL Server 2000 system will no longer respond to keep-alive packets.