Hello,

I don't know, whats wrong with my modsecurity installation, but if I try to upload a file to my owncloud installation with the android client, the upload will fail.

If I exclude 00_asl_z_antievasion.conf, it works.

The problem is, that there are no logfile entries wich show what happened. No entry in audit.log...
So I only know, that it must have to do something with 00_asl_z_antievasion.conf.


I'm using
Debian Squeeze
Apache 2.2.16-6+squeeze7
ModSecurity 2.6.3-1
ModSecurity Rules: 201208031104


Do you have any Ideas?

Christian

PS: sorry for my bad English

I don't know why there is still nothing to see in the log files.
But know I tested it again,the responsible mod security rule is 333791.
If I add "SecRuleRemoveById 333791" to the configuration of the Vhost, it works.

We'd be happy to help. So first, make sure you are running the latest modsecurity, according to what you posted you're running a very old version that has both bugs, and some very big security vulnerabilities.

With that said, rule 333791 does not block anything, it just detects unknown encoding types and configures the WAF to inspect them more closely using other rules. Disabling this rule will open a very huge whole in your system, and you should not disable this rule. This rule does not block anything, and disabling it will make the WAF blind to many attacks.

Are any rules being logged as having been triggered on your system? And do you have modsecurity configured as described on the wiki:

https://www.atomicorp.com/wiki/index.ph ... rity_Rules

And do you have any other rules installed on your system?

I have updated modsecurity to 2.6.6-3. Thats the newest debian packet. The normal stable packet is much older and doesn't work well with asl modsecurity rules.

I have updated the asl modsecurity rules to the newest version and I have still the same problem.
Modsecurity itself is configured correctly.

No rules being logged as having been triggered, that is what I don't understand.

No, only asl rules

2.6.7 is the latest stable, please make sure you are using 2.6.7 which includes some fixes.

OK, so if I understand you correctly, no rules are being triggered in your case, is that correct? Does the test case generate a log message on your system?

https://www.atomicorp.com/wiki/index.ph ... are_loaded

Do you have any rules disabled, or any custom modifications to your rules?

So we just setup owncloud 4.0.6 on a test system, and using the iphone and linux clients uploaded and synced a bunch of docs and photos and didnt have any issues. What exactly are you doing with owncloud?

We'll get the android client setup in a moment to see if it works, but so far owncloud seems to be working fine with the rules out of the box.

In the mean time, can you run a single test on your system with your android client with modsecurity in debug mode (please dont do anything else on the server when you do this, it will generate a lot of data we dont need), and then send us the modsec-debug.log file. Please also send your modsec configuration.

Add these lines to your modsec config to setup debug mode.

SecDebugLog logs/modsec-debug.log
SecDebugLogLevel 9

And then disable these once you are done, debug mode will slow down apache considerably.

I built mod security from sources and now I have 2.6.7 but still the same Problem.

The testcase generates the following log entries:

audit.log:



./20120806/20120806-2349/20120806-234901-UCA7zS4EcpwAAB1eOE8AAAAO:


I will send you a downloadlink for the debug.log in some Minutes.

So what are you doing with owncloud? We've done file syncs, calendar and contacts from iphones, ipads, linux and windows without any issues. So what are you doing with owncloud?

I tested some settings and files to upload and it seems so, that it works to upload very small files.
But it works only if the uploaded file is smaller than SecRequestBodyInMemoryLimit.
If the file is larger, it will be stored in /tmp on the disk but after that nothing seems to happen The upload fails.


My modsecurity config:


here is the debug log file:
https://killerhorse.eu/debug/debug.log

I will send user and password with PM.

I just uploaded a 500MB file myself, with no issues. How big of a file are you trying to upload?

Only 1 Mbyte

Definitely not able to reproduce that:

/var/www/html/owncloud/data/testuser/files/media

root@server1 media]# ls -alh *
-rw-r--r-- 1 apache apache 1.4M Aug 6 20:11 libjpeg-turbo-1.1.1.src.rpm
-rw-r--r-- 1 apache apache 2.6M Aug 6 20:13 roundcubemail-0.7.2.tar.gz

Uploads over 1MB work just fine on the test box here. Keep in mind that we use apache 2.2.21 on our WAF appliances. With that said, if you arent seeing any rules trigger then this does not sound like its the rules causing this. If one of our rules is triggered, that gets logged, nothing in the logs, none of our rules are doing this. This is especially true if the issue abates when you disable rules, or rulesets that just configure the WAF itself. For example, 333791, which only changes the configuration of the WAF and does not do anything else. Or if you disable the antievasion rules which do the same thing.

Looking at your debug log, this is starting to look like a problem with either how modsecurity is setup or built on your system, which could include an issue with a library, or a possible bug in the version of Apache you are using (or one its libraries). But something is wrong with the environment it seems.

From the debug file, can you confirm thats the entire debug for this event? If so, something is very wrong with your system. It quit during your write, hard, it just stopped cold. Heres what happens on your system:

[07/Aug/2012:00:26:52 +0200] [youbox/sid#7fdbb1639ad8][rid#7fdbb42a2580][/owncloud/remote.php/webdav/5.jpg][4] Input filter: Request too large to store in memory, switching to disk.
[07/Aug/2012:00:26:52 +0200] [yourbox/sid#7fdbb1639ad8][rid#7fdbb42a2580][/owncloud/remote.php/webdav/5.jpg][4] Input filter: Created temporary file to store request body: /tmp/2
0120807-002652-UCBEqi4EcpwAACtBGakAAAAB-request_body-EgHDFh
[07/Aug/2012:00:26:52 +0200] [yourbox/sid#7fdbb1639ad8][rid#7fdbb42a2580][/owncloud/remote.php/webdav/5.jpg][4] Input filter: Wrote 131072 bytes from memory to disk.
[07/Aug/2012:00:26:52 +0200] [yourbox/sid#7fdbb1639ad8][rid#7fdbb42a2580][/owncloud/remote.php/webdav/5.jpg][9] Input filter: Bucket type TRANSIENT contains 2048 bytes.
[More of the same ....]

But then after pushing some of the file, apache just quits:
[07/Aug/2012:00:26:59 +0200] [yourbox/sid#7fdbb1639ad8][rid#7fdbb42a2580][/owncloud/remote.php/webdav/5.jpg][9] Input filter: Bucket type TRANSIENT contains 1508 bytes.
[07/Aug/2012:00:26:59 +0200] [yourbox//sid#7fdbb1639ad8][rid#7fdbb42a2580][/owncloud/remote.php/webdav/5.jpg][9] Input filter: Bucket type EOS contains 0 bytes.

And thats in your log. Which means apache quit, no rules were triggered, apache just stopped processing the thread.

Heres a healthy apache:

[06/Aug/2012:20:26:02 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][4] Input filter: Request too large to store in memory, switching to disk.
[06/Aug/2012:20:26:02 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][4] Input filter: Created temporary file to store request body: /tmp/20120806-202602-UCBgmn8AAAEAAHdvvlcAAAAD-request_body-yFaMpe
[06/Aug/2012:20:26:02 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][4] Input filter: Wrote 131072 bytes from memory to disk.
[06/Aug/2012:20:26:02 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][9] Input filter: Bucket type TRANSIENT contains 8192 bytes.
[More of the same.....]
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][9] Input filter: Bucket type TRANSIENT contains 2166 bytes.
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][9] Multipart: Added file part 2b7faf58e2d0 to the list: name "files[]" file name "snort-2.9.0.5-1.src.rpm" (offset 366, length 5826266)
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][9] Input filter: Bucket type EOS contains 0 bytes.
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][5] Adding request argument (BODY): name "MAX_FILE_SIZE", value "536870912"
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][5] Adding request argument (BODY): name "dir", value "/media"
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][4] Request body no files length: 236
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][4] Input filter: Completed receiving request body (length 5826678).
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][4] Starting phase REQUEST_BODY.
[06/Aug/2012:20:26:03 --0400] [ourhost/sid#2b7fa0dc2768][rid#2b7fabc896a0][/owncloud/][9] This phase consists of 3442 rule(s).

And it continues from there, with rules being processed and the body is inspected. In your case, apache never gets to this, the thread just dies.

If your debug truly did stop here:

[07/Aug/2012:00:26:59 +0200] [yourhost/sid#7fdbb1639ad8][rid#7fdbb42a2580][/owncloud/remote.php/webdav/5.jpg][9] Input filter: Bucket type EOS contains 0 bytes.

Then there may be something more fundamental wrong with your modsecurity setup or build, possibly somethings amiss with apache on your system, or maybe the client just quit (although we would see an error to that effect normally, and I dont see that here), or maybe your modsecurity setup is munged. Check to make sure your rules are valid, and your config is correct. Somethings wrong with your modsecurity setup, modsecurity itself isn't either working with a valid setup or something's wron with tHe build/environment.

Can you confirm that the debug file you posted is the entire debug file?

Yes it is the entire logfile!
Also the apache logfiles are looking like there is something missing.

Here the access.log:

80.109.93.175 - killerhorse [07/Aug/2012:03:12:21 +0200] "HEAD /owncloud/remote.php/webdav/5.jpg HTTP/1.1" 200 - "-" "Jakarta Commons-HttpClient/3.0"
80.109.93.175 - killerhorse [07/Aug/2012:03:12:21 +0200] "HEAD /owncloud/remote.php/webdav/5%20(2).jpg HTTP/1.1" 404 - "-" "Jakarta Commons-HttpClient/3.0"


I tried the same again with disabled asl Rule ID 333791
by adding this to the vhost:

<LocationMatch /owncloud/remote.php/*>
<IfModule mod_security2.c>
SecRuleRemoveById 333791
</IfModule>
</LocationMatch>


And here the related access.log:
80.109.93.175 - killerhorse [07/Aug/2012:03:16:09 +0200] "HEAD /owncloud/remote.php/webdav/5.jpg HTTP/1.1" 200 - "-" "Jakarta Commons-HttpClient/3.0"
80.109.93.175 - killerhorse [07/Aug/2012:03:16:10 +0200] "HEAD /owncloud/remote.php/webdav/5%20(2).jpg HTTP/1.1" 404 - "-" "Jakarta Commons-HttpClient/3.0"
80.109.93.175 - killerhorse [07/Aug/2012:03:16:10 +0200] "PUT /owncloud/remote.php/webdav/5%20(2).jpg HTTP/1.1" 201 - "-" "Jakarta Commons-HttpClient/3.0"


I don't think that it has something to do with the mod security build, because I tested 3 different builds. An old one from the Debian packages, a newer one and the newest stable built from source. I really don't know whats going wrong, but I think tomorrow I will also test an other Apache version (I will also build it from source).

But why I don't have any problem with other php scripts with the same asl rules, the same modsecurity and the same apache...!?

Hello,

I'm very very sorry. The reason of this Problem was a realy stupid mistake on my part.
There was a Problem in the updatescript for the modsecurity rules (my own script, not yours).
The bigger part of the modsecurity rules were really old.

Thank you for hard try to help me.

Christian