Odd Apache/MSIE issue with downloads from ISC

Published: 2009-10-14
Last Updated: 2009-10-14 15:05:43 UTC
by Johannes Ullrich (Version: 1)
15 comment(s)

This diary is a bit unusual in that the problem here is very close to home, the ISC/DShield website. But I figure among all of our readers, there may be one who can help. I have seen others describing the same issue, but so far I haven't found a solution.

The problem:

Users who download our log submission client using Internet Explorer frequently receive truncated files. Firefox appears to download them fine. In either case, the server logs a "200" status and the file size in our Apache access log is correct (about 2.2 MBytes). However, the users only receives 200-300kBytes. A packet capture confirms that only 200-300kBytes got transfered. As MSIE starts the download, it does display the correct file size (and the content-length header is correct)

Some of the issues we excluded:

mod_security, firewall, IPS

Also note that the downloads work fine with Firefox, so the server is perfectly capable of sending the file. Any help is appreciated.

Link to the file: http://isc.sans.org/clients/cvtwin-setup.exe

Here is a packet dump of the end of the connection:

IP client.54436 > server.80: Flags [.], ack 193105, win 32850, length 0
IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460
IP client.54436 > server.80: Flags [.], ack 196025, win 32850, length 0
IP server.80 > client.54436: Flags [.], ack 646, win 1783, length 1460
IP server.80 > client.54436: Flags [FP.], seq 215005:216465, ack 646, win 1783, length 1460
IP client.54436 > server.80: Flags [.], ack 198945, win 32120, length 0
IP client.54436 > server.80: Flags [.], ack 200405, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 203325, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 207705, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 210625, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 212085, win 32120, length 0
IP client.54436 > server.80: Flags [.], ack 213545, win 32850, length 0
IP client.54436 > server.80: Flags [.], ack 216466, win 32120, length 0
IP client.54436 > server.80: Flags [F.], seq 646, ack 216466, win 32850, length 0
IP server.80 > client.54436: Flags [.], ack 647, win 1783, length 0

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: apache MSIE
15 comment(s)

Comments

how is ending the trace? you should be able to determine which end is closing the connection.

justme

Oct 14th 2009
1 decade ago

I added the last few packets from my packet capture above. The server is sending the first "FIN".

Dr. J

Oct 14th 2009
1 decade ago

Have you tried right clicking on the file from a directory view and then save-as?? If that works then the chances are the browser is reading the Character Set of the last page it was on and using it for the transfer type. If no default character set is listed it may default to a 7-bit Latin character set (1251 I believe) as many windows things do.

Try setting up a doctype in the html..

<meta http-equiv="content-type" content="text/html; charset=utf-8">

I know you can set the default character set in Apache as well, which may solve your problem.

The other option is to set up an FTP link instead.

Just a thought..

Good luck, Al

Al of YourDataCenter

Oct 14th 2009
1 decade ago

I'm fairly confident this is NOT your problem, but I thought I'd mention it just in case. I had a somewhat similar issue that was resolved using the Apache EnableSendFile directive:
http://securityonion.blogspot.com/2008/10/apache-enablesendfile-directive.html

For more information, please see:
http://httpd.apache.org/docs/2.0/mod/core.html#enablesendfile

Thanks,
Doug Burks

Doug

Oct 14th 2009
1 decade ago

Charset: already setting it in HTTP header and as a META tag

EnableSendFile: Tried it... so far no difference (but a good catch!) .

Dr. J

Oct 14th 2009
1 decade ago

I set up two test files:
http://isc.sans.org/null.bin (all "0")
http://isc.sans.org/random.bin (random content)

both files are 1,000,000 bytes long. I am still having the same issue with these files as I have with the cvtwin-setup.exe file.

Dr. J

Oct 14th 2009
1 decade ago

Because the .exe is a zip file, could it be related to the mod_deflate module in Apache?

http://www.waterworld.com.hk/en/node/58

Terosaur

Oct 14th 2009
1 decade ago

Just a quick observation. Doubt it means anything...

C:\Users\ignorance>nc isc.sans.org 80
GET /clients/cvtwin-setup.exe HTTP/1.0

HTTP/1.1 302 Found
Date: Wed, 14 Oct 2009 18:21:54 GMT
Server: nc -l -p 80
Location: https://blogs.sans.org/appsecstreetfighter//clients/cvtwin-setup.exe
Content-Length: 252
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://blogs.sans.org/appsecstreetfighter//clients/cvtwin-setup.
exe">here</a>.</p>
</body></html>

Same results (302 redirect and double-slash in redirect) with telnet.

ignorance is bliss

Oct 14th 2009
1 decade ago

Just a quick observation. Doubt it means anything...

C:\Users\ignorance>nc isc.sans.org 80
GET /clients/cvtwin-setup.exe HTTP/1.0

HTTP/1.1 302 Found
Date: Wed, 14 Oct 2009 18:21:54 GMT
Server: nc -l -p 80
Location: https://blogs.sans.org/appsecstreetfighter//clients/cvtwin-setup.exe
Content-Length: 252
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://blogs.sans.org/appsecstreetfighter//clients/cvtwin-setup.
exe">here</a>.</p>
</body></html>

Same results (302 redirect and double-slash in redirect) with telnet.

ignorance is bliss

Oct 14th 2009
1 decade ago

I am not having this problem in ie8 using your test files.
This reminds me of a gzip issue I ran into before.
This is an IE problem and they have fixed it in ie8. There is a work around you can apply in apache though.
http://support.microsoft.com/kb/871205

Marc

Oct 14th 2009
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives