Microsoft DCE-RPC denial of service

Windows RPC Endpoint Mapper does not properly check message inputs under certain circumstances. An attacker can send a certain type of malformed RPC message after RPC established a connection, which may cause the RPC Endpoint Mapper process on the remote machine to fail. In this case, most of the server services become unavailable and rebooting the machine might be required.

A worm known as the W32/Lovsan.worm, MSBlast, Blaster/LovSan, or simply RPC worm is known to exploit this vulnerability.

The RPC Endpoint Mapper process is responsible for maintaining the connection information for all of the processes on that machine using RPC. Because the Endpoint Mapper runs within the RPC service itself, exploiting this vulnerability would cause the RPC service to fail, with the attendant loss of any RPC-based services the server offers, as well as potential loss of some COM functions.

(see more details about RPC services and 99x dropped logs is provided in the additional information section)

NG with Application Intelligence (R55) will output a drop log with rule number 994 for the Blaser worm.

NG with Application Intelligence R55 already provides all the protections added in this advisory, as well as further specific Blaster worm protections. Therefore, there is no need to update any file.
The Blaster worm specific protection will output a drop log with rule number 994.

FireWall-1 inspects DCE-RPC connections. This allows security administrators to specifically define Microsoft based RPC services that need to pass through the firewall. The service definitions are based on RPC service identifiers (UUID) that are unique for each service that is matched by RPC Mapper. As a result, FireWall-1 is performing Stateful Inspection security checks on both the connections and check the packet validity.

In case those DCE RPC connections are required to pass the firewall, it is recommended to use specific DCE RPC services in the rule base. (For example: MS Exchange, WINS etc.)

Security Administrators should perform the following tasks:

1. Define specific DCE-RPC rules in the SmartDashboard. Such rule should include specific DCE-RPC UUID (and NOT a general TCP/135 service).

   For example: Internal Net, Servers Net, MSExchangeMTA, Accept, Log

2. Install the attached INSPECT code. Administrators should perform the following tasks on the SmartCenter Server:
   1. Stop the SmartCenter Server, by running cpstop.
   2. Backup the file $FWDIR/lib/dcerpc.def
   3. Replace the old dcerpc.def file with the new file
3. Edit $FWDIR/lib/table.def and replace the following line:
   dcerpc_binds = dynamic sync refresh expires TCP_TIMEOUT;
   with:

   dcerpc_binds = dynamic sync refresh expires 40;

4. Start the SmartCenter server by running cpstart and install policy on all modules.

Updated: 28-Jun-04:
 dcerpc.def for NG with Application Intelligence (R54)
(MD5: 289be06b815081536a77a471a73e164e)

Note: Users of latest HFAs already have the latest updates and do not need to download the file

Updated: 30-Jun-03:
 dcerpc.def for NG FP3
(MD5: B83318A1 6DC706EF E291D508 847B5304)

Rules 996, 997, 998, and 999 are dummy rule numbers that appear in DCE RPC specific error logs. They indicate that the initial DCE RPC packets were allowed, but an error occurred later in the TCP stream, which did not conform to the correct DCE RPC flow as FireWall-1, understands
it. Specifically:

• Rule 996 indicates a specific RPC denial of service attack.
• Rule 997 indicates that the client tried to switch to a UUID that is not allowed.
• Rule 998 indicates a client-to-server malformed packet.
• Rule 999 indicates a server-to-client malformed packet.

NG with Application Intelligence (R55) will output a drop log with rule number 994 for the Blaser worm.