Last Updated: 2013-02-08 21:07:10 UTC
by Johannes Ullrich (Version: 3)
An interesting blog post by Kristian Kielhofer describes how a specific SPI packet can "kill" an Intel Gigabit ethernet card . If a card is exposed to this traffic, the system has to be physically power cycled. A reboot will not recover the system.
The network card crashed whenever the value 0x32 or 0x33 was found at offset 0x47f. Kristian first noticed this happening for specific SIP packets, but in the end, it turned out that any packet with 0x32 at 0x47f caused the crash. Intel traced the problem to an EEPROM used in this specific card (82574L). There are some links in the comment to the blog suggesting that others have run into this problem before. For example, the commend: "ping -p 32 -s 1110 x.x.x.x" can crash an affected card remotely.
[Update] A few asked why this doesn't happen just randomly every 128th packet: Once the card receives the value "0x34" in this position, it appears to be no longer vulnerable. There are also a number of earlier bug reports about this card that sound very similar, and appear to be related to ASPM, a PCI power safe feature. Kristian claims he eliminated this issue. if you try to reproduce this issue, power up the system and then issue the "ping" command shown above quickly after reboot in order to avoid the "inoculation" wiht 0x34. We would like to hear any reports of being able to reproduce (or not) this issue.
There are also some reports about similar issues in certain 3G USB modems.
Last Updated: 2013-02-06 20:30:17 UTC
by Johannes Ullrich (Version: 1)
(This is a guest diary submitted by Bill Parker)
Last Updated: 2013-02-06 19:07:01 UTC
by Johannes Ullrich (Version: 1)
Last week, I was debugging the podcast access script, I came across some interesting behaviour regarding the "Range" header in HTTP requests. The purpose of the "Range" header is to allow for resumable downloads via HTTP. The client may ask the server to only sent a certain part of the page, instead of the entire response. Not all servers (or browsers) necessarily support this feature. The feature is very different from "Chunked encoding", another feature that can be used to break up a page, but not to break it up as demanded by the client.
Client Side / Request
A request may include a range header, asking only for a part of the file. For example:
would request the first 100 bytes from the response. The server may ignore this header, and the browser should accept whatever comes back, even if it is more or less then the requested range
Server Side / Response
A partial response always uses the status code 206 instead of 200. In addition, a header indicating the range delivered, and the total length of the file will be included:
From the RFC:
HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif
The Content-Range header indicates the range delivered, and the number following the / is the size of the file. In addition, you should still see a content-length header.
So what could possibly go wrong? I played with various invalid combinations, and so far, what I found is that the browser will ignore them. I haven't gotten around to test them all with respect to an IDS, but assume that a properly configured HTTP preprocessor will reassemble these ranges. Of course, without preprocessor, there will be a wide range of evasion/insertion attacks.
An issue I found is that some podcast clients will first try to download byte range 0-1, then they will download the file. Most of the time in one attempt, but frequently in multiple ranges. This can confuse web log analysis software as it will register them as multiple "hits" to the same file. You need at least to look at the status code (200 vs. 206). Also, the clients did not access the complete file if the server returned the entire file instead of just bytes 0-1.
It is also possible to specify multiple byte ranges in one request, and older versions of Apache had a denial of service vulnerability if an excessive number of byte ranges was specified.
Let us know if you find anythingelse interesting when it comes to processing the Range header.
References: RFC 2616 http://www.w3.org/Protocols/rfc2616