Security
Brief items
Cross-site tracing attacks
[This article was contributed by LWN reader Tom Owen]
Last week, this Extremetech article was the first press coverage of Whitehat Security's whitepaper on a new type of cross site scripting attack. Whitehat has called it "cross site tracing", or XST.Cross-site scripting (XSS) is a simple idea at heart: the attacker loads exploitative HTML, including a client-side script, into a web site, typically one which allows public submissions and which does not properly quote HTML tags. Any user of the site who reads the story loads the exploit into their browser. The script uses the client browser's rights to cause mischief -- typically to access information and send it to the attacker. Recent XSS vulnerability reports focus on exposing cookie contents -- perhaps including session and authentication details -- to the attacker. Browser domain restrictions are supposed to stop clients from sending cookie contents anywhere except back to the server that issued them, but it's hard to enforce this restriction if scripts are allowed to access those contents, and many browsers have faults which allow scripts to bypass domain restrictions.
Enter cross-site tracing, which is a new variety of XSS attack. It uses the TRACE command, which is an obscure part of the HTTP 1.1 protocol. It substitutes for GET, except that instead of replying to the request the server echoes it -- the TRACE string and the subsequent headers -- back to the client with a content type of message/http. It's intended as a debugging aid. Most web servers implement TRACE as part of the standard, and, as it's never been implicated in security problems, most sites leave it enabled.
In essence, Whitehat report that some browsers can be scripted to send TRACE requests and return the echoed headers to the script. The report lists Mozilla (using XMLDOM) and IE (using XMLHTTP) as vulnerable. HTTP headers seem like they would be innocous, but unfortunately they carry cookies and HTTP authorization strings to the server. With the aid of one of the available domain restriction breaches, these data can be taken from the trace and sent to the attacker.
Whitehat was obviously pleased with this discovery.
The
press
release
uses words like "pandemic" and refers to
"a serious security flaw affecting all web server[s] world
wide.
"
The whitepaper is more tempered, but it implies
that the TRACE method has a defect
which compromises every web server.
Opinion on Bugtraq (discussions here and here) and Slashdot ranges from "hyped, sensationalised snakeoil" to "a terrible security hole." The critics point out that there's no fault in TRACE, and client domain restriction breaches already offer scripted ways ways to read cookies. On the whole they seem to have won the argument as there's been little press coverage and no rebuttal from Whitehat. There have been some more positive responses noting that script access to the Authorization: header containing the HTTP Basic authentication is new and disturbing, and that client problems are sometimes best fixed at the server.
Nobody is claiming that TRACE is needed on a production server -- it's as vestigial as HELP in Sendmail SMTP. So, as it's certain that a server that can't do TRACE won't ever allow its clients to be subverted through it, removing it may be the way to go. The Apache Limit directive can't suppress TRACE, so Whitehat and Apacheweek both suggest using mod_rewrite to force a forbidden (403) error in Apache:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
RewriteEngine On needs to be repeated in every <VirtualHost> block. Experiment suggests that there's more to it than this, (no, I can't make it work ...) but it has to be easier than iPlanet/Netscape, which requires a binary edit.
Security consultants feel pressure to find and publicise security holes, and it's inevitable that some of them will be less serious than the spin suggests. The community's loud and direct quality control is necessary to keep the numbers within limits. However, even snake oil may have something to teach us, and at least one Apache admin will be spending a few hours this week figuring out just what secures the DELETE method.
A look at the MS-SQL worm
Recommended reading: this posting by Karsten Self on the MS-SQL (aka "Sapphire" or "Slammer") worm and why Linux users shouldn't be overly smug about this episode. "This means that the infected hosts were on the order of 1% of all potential hosts. That is, Microsoft users were attaining a 99% patch and/or secure rate of systems publicly visible to the worm. This is a pretty good compliance rate. It was also wholly inadequate in preventing this attack".
New vulnerabilities
dhcp3 - ignored counter boundary
| Package(s): | dhcp3 | CVE #(s): | CAN-2003-0039 | ||||||||||||||||
| Created: | January 28, 2003 | Updated: | April 5, 2003 | ||||||||||||||||
| Description: | Florian Lohoff discovered a bug in the dhcrelay causing it to send a
continuing packet storm towards the configured DHCP server(s) in case
of a malicious BOOTP packet, such as sent from buggy Cisco switches.
When the dhcp-relay receives a BOOTP request it forwards the request to the DHCP server using the broadcast MAC address ff:ff:ff:ff:ff:ff which causes the network interface to reflect the packet back into the socket. To prevent loops the dhcrelay checks whether the relay-address is its own, in which case the packet would be dropped. In combination with a missing upper boundary for the hop counter an attacker can force the dhcp-relay to send a continuing packet storm towards the configured dhcp server(s). This patch introduces a new commandline switch ``-c maxcount'' and people are advised to start the dhcp-relay with ``dhcrelay -c 10'' or a smaller number, which will only create that many packets. The dhcrelay program from the ``dhcp'' package does not seem to be affected since DHCP packets are dropped if they were apparently relayed already. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
MySQL - double free vulnerability
| Package(s): | mysql | CVE #(s): | CAN-2003-0073 | ||||||||||||||||
| Created: | January 29, 2003 | Updated: | February 21, 2003 | ||||||||||||||||
| Description: | MySQL 3.23.55 fixes a double-free vulnerability which allows a hostile client to crash the server process. Logging into the server is necessary before this vulnerability can be exploited. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
noffle - buffer overflows
| Package(s): | noffle | CVE #(s): | CAN-2003-0037 | ||||
| Created: | January 27, 2003 | Updated: | January 29, 2003 | ||||
| Description: | Dan Jacobson noticed a problem in noffle, an offline news server, that leads to a segmentation fault. It is not yet clear whether this problem is exploitable. However, if it is, a remote attacker could trigger arbitrary code execution under the user that calls noffle, probably news. | ||||||
| Alerts: |
| ||||||
Page editor: Jonathan Corbet
Next page:
Kernel development>>