What is the non-standard HTTP verb "DEBUG" used for in ASP.NET/IIS?

http://support.microsoft.com/kb/937523

When the client tries to automatically attach the debugger in an ASP.NET 2.0 application, the client sends a HTTP request that contains the DEBUG verb. This HTTP request is used to verify that the process of the application is running and to select the correct process to attach.

It uses Windows authentication, and DCOM to actually do the debugging though - so I'm not aware of the DEBUG verb itself being a large security risk (obviously, if you're allowing RPC traffic, then you've got bigger problems) or of any exploits. UrlScan does block it by default, though.

I'd probably put a network sniffer on it to check what information leaks though.

The DEBUG verb does allow a potential XSS attack (according to Burp Suite), even with <compilation debug="false"/>, because the 403 response includes the requested URL path in its body, which can contain an attack vector. This fix makes IIS return a 404 response with no body, and so removes the vulnerability.

As hinted by Mark, the DEBUG verb is used to start/stop remote debugging sessions. More specifically, a DEBUG request can contain a Command header with value start-debug and stop-debug, but the actual debugging is done via an RPC protocol.

So, why does a security scanner perform such request? It appears that poking an ASP.NET website with the DEBUG requests can be used to reveal if the web.config has <compilation debug="true">. The test can be performed with telnet, WFetch or similar, by sending a request like this:

DEBUG /foo.aspx HTTP/1.0
Accept: */*
Host: www.example.com
Command: stop-debug

Depending on whether debugging is enabled or not, you will get either 200 OK or 403 Forbidden.

It is generally accepted that you should never have <compilation debug="true"/> in a production environment, as it has serious implications on the performance of the website. I am not sure if having debugging enabled opens any new attack vectors, unless RPC traffic is enabled as well, in which case you have more serious problems anyway (cf. Mark's answer). Any additional insights on the security perspective will be greatly appreciated.

There is an easy way to avoid accidentally getting <compilation debug="true"/> in production websites. Simply, add <deployment retail="true"/> to your machine.config.

Apparently, having <deployment retail="true"/> in the machine.config is not equal to setting <compilation debug="false"/> in this particular case. The result from throwing DEBUG requests against the web application can only be changed with the latter. Mind-boggling!

@Mark, @Jørn, thanks for the excellent info, I had also been curious about this.
As for the your report, from a security point of view, there is one other aspect (besides RPC and debugging support) - attack surface. I's kind of a low-risk item, but best practice is generally to minimize any external interfaces that you dont need, so that potential attackers have less room to maneuver, and have lower probability of finding that one critical flaw.
Btw, having debug compilation turned on has other effects, as it does leave more traces, pdb files, etc around. Not necessarily high risk, but still... (not to mention PCI compliance, if this is relevant.)