PPC Macs and mod security

Seems like request headers get extra padding

[StupidScript]

I have a simple file upload form running on Apache 2 (using PHP 5 to handle the upload). I have one user who can get to the page, and if they don't fill out the form completely or try to upload the wrong filetype, they get the proper error message (request sent and PHP-driven response). If they DO fill out the form completely and include a valid filetype (JPEG), they trigger a mod_security response:

ModSecurity: Request body is larger than the configured limit (131072).

(128kb)

Here are three user agent profiles. The first two work fine (Safari on Intel OSX, Firefox on XP) and the third is the problem setup (Firefox on PPC OSX).

OK

IPA.DDR.ESS.001 - - [03/May/2007:11:57:23 -0400] "POST www.example.com/fileupload.html HTTP/1.1" 200 408 "http://example.com/fileupload.html" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419 (KHTML, like Gecko) Safari/419.3"

OK

IPA.DDR.ESS.002 - - [02/May/2007:19:45:15 -0400] "POST www.example.com/fileupload.html HTTP/1.1" 200 400 "http://www.example.com/fileupload.html" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"

BAD

IPA.DDR.ESS.002 - - [02/May/2007:19:41:42 -0400] "POST www.example.com/fileupload.html HTTP/1.1" 413 352 "http://example.com/fileupload.html" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"

Note the 413 error code in the BAD profile ... returned by mod_security.

Has anyone running mod_security had request-size issues with clients using PPC OSX Macs?

[jdMorgan]

Do you know how big the file he's trying to post actually is?

If so, and if it is reasonable, you could increase the LimitRequestBody [httpd.apache.org] setting, either in httdp.conf or .htaccess.

If, however, the file he's trying to upload is significantly smaller than 128kB, then that might indicate a problem with the SSL implementation on Mac PPC Firefox.

If you can 'recruit' this person to help, have them install the Live HTTP Headers extension from the Mozilla projects site, and see what size the browser thinks the file is.

Basically, when I don't know what's wrong, more data is good data... :)

Jim

[StupidScript]

Thank you for the response. I have modified my log so it captures the size of the request, as well (mod_logio > %I) and here is a complete pair of requests, from the time they first requested the page through the POST attempt. (These, as with the above mis-named "user agent profiles", are actually "log entries" ... doh!)

IPA.DDR.ESS.002 - - [03/May/2007:20:08:46 -0400] "GET www.example.com/fileupload.html HTTP/1.1" 200 [b]438[/b] 1961 "-" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"

IPA.DDR.ESS.002 - - [03/May/2007:20:11:57 -0400] "POST [b]www.example.com-[/b] HTTP/1.1" [i]413[/i] [b]621[/b] 352 "http://example.com/fileupload.html" "Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.11) Gecko/20070312 Firefox/1.5.0.11"

Note the request URI in the second, POST, entry. All of the requests that worked requested the fileupload.html file with fileupload.html as the referrer. Odd. (Note that I modified the BAD example's request in my first post because I thought it would be distracting from the PPC direction I wanted to go in. The request for the BAD example above was the same as this second test. I guess I'm just a bad scientist ...)

Again, we see the 413 error returned by ModSecurity, but now we can see that my server thinks the request was clocking in at 621 bytes. Clearly way below the 128kb SecRequestBodyLimit setting in mod_security.conf.

The user gets a "Connection reset by peer" error.

It is ModSecurity that's throwing the block up, not Apache, AFAIKT.

I will ask them to install Live HTTP Headers plug-in (or walk them through, it, as they are true noobs) to see what their end says.

I'm still looking at the PPC processor as the primary problem on this. Does it always use an internal SSL process of some kind? I haven't been able to find any info on what exactly goes into a POST request on a PPC Mac. Note that the fileupload page is not contained in an SSL environment at the server.

<edit>
Anonymized IP
</edit>

[edited by: StupidScript at 7:17 pm (utc) on May 4, 2007]

[jdMorgan]

The byte count is the size of the server's response, not the posted file. 621 bytes is the size of your 413 response page.

I assumed that you had SSL turned on with mod_security. This may not be the case.

But no matter what, your server thinks the file is too big. Whether that has anything to do with Mac PPC or not, I don't know.

Jim

[StupidScript]

Thanks again. And for the clarification of what I see in the log entries.

An interesting note (perhaps):

The page is a pretty standard PHP-on-top-and-form-on-bottom page with the form's action being <?=$PHP_SELF?>. If there is a POST array, the PHP kicks in to parse the form data.

The PHP checks for (a) all form fields have values, (b) file to upload is JPEG (via MIME-type check) and (c) file to upload is <2MB.

If the form (name, company, email, file-to-upload) is incomplete, the PPC Mac user gets alerted and prompted to complete the form. So the request went out and the page responded.

If the file type is incorrect (i.e. GIF, etc.), the PPC Mac user gets alerted and prompted to choose a different file. Again, the request went out and the page responded.

Likewise if the file is over the size limit, they get the prompt, so even that request was processed. I've tried it on a couple of Winboxes and a Linux box with files that are too large (>7MB) and received the same prompts. I had a friend try from an Intel Mac with a file that was too large, and they got the prompt, and when they chose a <2MB file it was uploaded successfully.

They are only denied by ModSecurity when the form is complete, the file type is JPEG and its size is <2MB.

This seems to lean toward something other than the size/type of the file, and maybe toward something a PPC Mac does during a file upload. I'm guessing (wildly) that its when the connection to upload the file is made is when ModSecurity kicks in, and not the page request, itself.

Intel Macs don't do it, and neither do Win or Lin boxes. So that's why I'm fixating on PPC Macs.

I appreciate your continuing thoughts on this, Jim. Thanks.

[jdMorgan]

Well, the first thing I'd do is to make sure that the size limit settings of Apache core LimitRequestBody [httpd.apache.org], mod_security's SecRequestBodyLimit [modsecurity.org], and your script are all equal. Or set your script's size limit very slightly lower if you prefer to deliver "error-too big" messages from the script. Whichever of these three is set lowest will likely throw an error message to the user if his/her file is too big, although mod_security's behaviour isn't easily predictable unless you fully understand all the rules you've got configured for it.

Mod_security may be focusing on that particular user's IP address, account name, or other configured filter parameters. If he's already in "high suspicion mode," the filesize of his upload may be putting him over the top, so mod_security rejects his POSTs.

You are getting the "file too big" error message from mod_security, so I'd start there.

Jim

[StupidScript]

Thanks, again.

Over the weekend I'll do some more tests with the user making attempts and me adjusting things. I'm going to pay particular attention to the items you mentioned. I'm also looking at httpd.conf's MaxRequestsPerChild, in case the PPC Mac's uploading process involves launching multiple connections, and mod_security's SecUpload.. group of directives.

I am waiting for the user to try my most recent suggestion to them, which is to disable their "Enable Stealth Mode" setting in their Mac firewall, as it may be cluttering up a file upload attempt with extra strings or something (that seems to cause very slow surfing and frequent 'Connection reset by peer' errors for many Mac users).

It really does seem to be related to the actual act of uploading a file that passes the PHP checks, as when the checks are not passed, the page loads normally and they are not having trouble connecting to or browsing around any other pages stored on the server, including the fileupload page. They just run into this when the upload passes muster and is then attempted.

I'll be back to post the results. Thanks, Jim.

[StupidScript]

I'd like to note that in the last two custom log file entries, the request size is displayed in addition to the response size.

[i]413[/i] [b]621[/b] 352

The response 413 error message ("Connection reset by peer."+/-) is 352 bytes. The request POST submission should be 621 bytes, according to the mod_logio [httpd.apache.org] docs.

%...I Bytes received, including request and headers, cannot be zero.

I'm kinda thinking that there's something going on under the hood ...

[StupidScript]

Well, we've eliminated the usual suspects, so I'm left with thinking it has to do with the "MTU" (Maximum Transfer Unit), which may apparently be set too large on the Mac. Unfortunately, the user I was troubleshooting with has no desire to get that deep into the tech world (command line stuff), so we will wait to see if other users have problems, and I'll try to work it out with them, if and when they contact me.

Sorry, no joy, yet.