Attachments/Uploads fail when using apache with mod_security due to unmatched boundaries in multipart content

[klktrk]

On a clean Trac 0.11.5 installation running Apache 2 I ran into problems when trying to upload attachments.

Attachments of any type (whether binary or text) would fail, whether they were being attached to a ticket or the wiki. There was no error message about the attachment being too large. Instead, apache was reporting that it was not allowed to write the file.

I checked my directory permissions, and they were owned by www-data (debian httpd username).

Guessing that it had to do with file-size, I upped the max_size param in my trac.ini, but this had no effect.

Finally, by looking through my logs again, I realized that mod_security was blocking the attachments due to a particular rule regarding checking for unmatched boundaries in multipart uploads.

This ruleset is part of the default mod_security installation for mod_security 2, and looks like this:

# Did we see anything that might be a boundary?
#SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"

It's important to note that mod_security is not interfering with large uploads of any kind of files for my other virtual hosts running drupal or wordpress. This issue is specific to Trac, and it was occurring whether using wsgi or mod_python.

This occurred both when using mod_python and also when I switched to wsgi

I was able to work around the issue by disabling the specific mod_security rule for the specific virtual host.

# in mod_security.conf, I changed
# Did we see anything that might be a boundary?
#SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"

# to

# give this rule an id, so we can make an exception
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.',id:111"

# which provides an id for the rule, so it can be referred to.

In my virtual host apache conf for my trac application, I disabled the rule like so:

<IfModule mod_security2.c>
	# see line 64 of modsecurity.conf
	SecRuleRemoveById 111
</IfModule>

Something in the way trac is performing its uploads which is not kosher. I don't like having to make my server more vulnerable in order to run trac, so it would be great if someone could look at the handler that performs multi-part uploads and see if everything is done the way it should.

I realize the actual upload handling might be performed by an auxiliary python library. If that is the case, then I suppose I'll have to transfer this bug to that library's developer. I am new to python, so I am unable to investigate whether this is the case or not.

Thanks for your help and attention.

(Please see ​The Trac google group thread for previous discussion)

[rblank]

There's one thing I don't understand: isn't the payload for the upload, containing the form data, generated by the browser? How can the behavior of the browser be different with Trac than with other applications?

Can you reproduce the issue with different browsers? If possible, please try at least two with different engines.

[anonymous]

More info requested, more information supplied:

1. I tried with two different browsers: Safari 4.0.3, and Camino (Gecko engine). Both produced the same error.

2. However, I notice now that this seems actually specific to attaching documents to wiki pages. I removed my mod_security rule override and was able to upload large documents to tickets, but NOT to the wiki.

[anonymous]

The error that is sent back to the browser is:

Forbidden
You don't have permission to access /330/attachment/wiki/HDFC/Shareholder Forms/ on this server.

The error that appears in the logs is:

ModSecurity: Access denied with code 403 (phase 2). Match of "eq 0" against "MULTIPART_UNMATCHED_BOUNDARY" required. [msg "Multipart parser detected a possible unmatched boundary."] [hostname "xxx.xxxxxx.xxx"] [uri "/dir/attachment/wiki/path/Doc%20Name/?action=new&attachfilebutton=Attach+file"] [unique_id "wqq88kj5TcIAAD5TDHwAAAAH"]

[anonymous]

Sorry, wish I could edit my previous comment. I expunged PII from the log error, but not from the browser error. I should have made the browser error look like so:

Forbidden You don't have permission to access
/dir/attachment/wiki/path/Doc Name/ on this server.

[cboos]

Nobody really had a clue about this issue, it doesn't help to keep it opened, so closing.

This is an InstallationIssue in the end.