Re: [mod-security-users] Fwd: Blocking File uploads by contents
Brought to you by:
victorhora,
zimmerletw
From: Brian R. <Bri...@br...> - 2008-11-13 00:47:26
|
Because we both got that backwards ;) After looking at the source: '1' is okay, otherwise it is rejected. So, just reverse your 0 and 1 in the exit calls. Sorry. I'll blame Ivan for that inconsistency :) -B Justin Brown wrote: > Well we keep getting closer, there are no errors from the script now > that I set "SecUploadFileMode 0644", but it is still not blocking the > file. Now the debug log gives me: > > #### > ... > Executing /usr/bin/modsecFileChecker.sh to inspect > /tmp/20081112-162049-SRty4dE@BGIAAEzoMQoAAAAD-file-EKGOTw. > Exec: /usr/bin/modsecFileChecker.sh > Exec: First line from script output: "1" > Operator completed in 6253 usec. > Rule returned 0. > No match, not chained -> mode NEXT_RULE. > ... > #### > > It looks to me like the script returned a 1 (denied) but then it says > "Rule returned 0". What am I missing? > > > On Wed, Nov 12, 2008 at 4:14 PM, Brian Rectanus > <Bri...@br... <mailto:Bri...@br...>> wrote: > > See below... > > Justin Brown wrote: > > Thanks! That did the trick; once I added "SecRequestBodyAccess On" > to my > > config file it started running the rule. Now the problem is with my > > script. :( I get this in the audit_log: > > > > #### > > --44a8c35a-H-- > > Message: Exec: Execution failed while reading output: > > /usr/bin/modsecFileChecker.sh (End of file found) > > Message: Rule processing failed. > > #### > > > > Is there any documentation regarding the location, permissions, etc. > > that are required for the approver script? As you can see I have it in > > /usr/bin and the permissions are 755 root:root. > > Not really. It needs to be read/execute for the user running Apache. > > As root (if you can): > > su - apache_user > > Then try to run as that user. > > > > > > I saw someone on the mailing list archives talking about proper > > permissions and location for chroot, but I'm not familiar with that > > concept and don't believe it is implemented on my system. > > This involves setting up Apache to run in a virtual root (as in "/", not > the user) where you specify some directory to be considered the same as > the root directory "/". In this case, the script would need to reside > in /your/chroot/usr/bin as well as any libs and bash, etc. You (or your > sysadmin) would have had to set it up. > > However, it looks like the script executed or you would have gotten: > > Exec: Execution failed: /usr/bin/modsecFileChecker.sh (Some error here) > > My guess is your script exited early because the file it is attempting > to read is not readable (see script comments below). You may need to do > this: > > SecUploadFileMode 0644 > > Which will change the file mode (permissions) to octal 644 after it is > written. > > > > > Here is the full source of my script (it's designed to find files > with a > > PHP opener tag (<?) in them. > > > > #### > > #!/bin/bash > > > > #Verify that we have a valid filepath argument > > if test -e "$1" > > > Probably want -r (file is readable) and not just -e (exists). > > > > then > > #Check for PHP open tag > > phpOpenCount=`grep -c "<?" $1` > > Probably do not have permissions on $1 and get an error for the grep > call (and thus no output). Check your exit codes ;) > > phpOpenCount=`grep -c "<?" $1` > if [ "$?" -ne 0 ]; then > echo 1 > fi > > > > > #if one or more lines are found, return modSec denied code > > if [ "$phpOpenCount" -gt "0" ] > > then > > If $phpOpenCount is empty then you would get and error. Something like: > > -bash: [: : integer expression expected > > > > echo 1 > > else > > echo 0 > > fi > > else > > fi > > Remove the else and let fall through here. > > > #If a valid file has not passed in, return modSec denied code > > echo 1 > > This is where you want to end up if you cannot read > > > > fi > > Move this up to replace else. > > > > > #### > > > > BTW thanks for putting those notes in to update the docs. I did > skim the > > processing phases section and I read through all the Configuration > > directives but I didn't connect the dots that > "SecRequestBodyAccess On" > > enabled access to uploaded files as well. I guess that's obvious (they > > are part of the POST after all) but since the note didn't > explicitly say > > so I figured there might be a seperate setting relating to file > uploads. > > So much for my knowledge of HTTP. :) > > > No problems. It is good to get comments. Add a comment to that ticket > if you find other issues. > > > -B > > > > > > > On Wed, Nov 12, 2008 at 3:05 PM, Brian Rectanus > > <Bri...@br... <mailto:Bri...@br...> > <mailto:Bri...@br... > <mailto:Bri...@br...>>> wrote: > > > > Justin Brown wrote: > > > Thanks for your response, please see my comments below: > > > > See below... > > > > > > > > > > > > > The docs for inspectFile are not very good. Actually, > they are > > > non-existant, heh. The script *must* print to stdout. > If the > > first > > > character output is '1' then the action is taken, otherwise > > (typically > > > outputting '0') the rule did not match and no action is > taken. > > Just > > > exiting with a return code of 0 or 1 is not sufficient. > > > > > > > > > My Bash script is echoing a 0 or 1 to stdout in addition to > > exiting with > > > those values. > > > > > > Additionally, your rule will only work if the body of the > > request has a > > > Content-Type of "multipart/form-data" and one of the > parts has a > > > Content-Disposition header with a filename= parameter (a > > > multipart/form-data file upload). The FILES_TMPNAMES is a > > collection of > > > all of these filenames and if the collection is empty, then > > the rule is > > > not even processed, which seems to be your case. > > > > > > > > > I tried both my own form and the one you provided below. Neither > > of them > > > caused any Multipart: entries to appear in the log. Have I > missed some > > > sort of configuration value I need to set in order for > mod_security to > > > handle file uploads? Here is my full configuration file that > Apache is > > > including: > > > > > > #### > > > LoadFile /opt/xml2/lib/libxml2.so > > > LoadFile /opt/lua/lib/liblua.so > > > LoadModule security2_module modules/mod_security2.so > > > <IfModule mod_security2.c> > > > SecRuleEngine On > > > # See > > > > > > http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf > > > # "Add the rules that will do exactly the same as the > directives" > > > # SecFilterCheckURLEncoding On > > > # SecFilterForceByteRange 0 255 > > > SecAuditEngine RelevantOnly > > > SecAuditLog logs/modsec_audit.log > > > SecDebugLog logs/modsec_debug_log > > > SecDebugLogLevel 0 > > > #SecDebugLogLevel 9 > > > SecDefaultAction "phase:2,deny,log,status:406" > > > SecRule REMOTE_ADDR "^127.0.0.1 <http://127.0.0.1> > <http://127.0.0.1> > > <http://127.0.0.1>$" nolog,allow > > > SecTmpDir /tmp > > > SecUploadDir /path/to/uploadtmp/ > > > SecUploadKeepFiles On > > > > > > I should have mentioned turning it on ;) > > > > # Allow access to the request body > > SecRequestBodyAccess On > > > > ### May want to look at these as well: > > # SecRequestBodyLimit <limit> > > # SecRequestBodyNoFilesLimit <limit> > > # SecRequestBodyInMemoryLimit <limit> > > > > # Allow access to the response body: > > # SecResponseBodyAccess On > > ### NOTE There are similar limits for response > > > > > > > SecRule FILES_TMPNAMES "@inspectFile > /usr/bin/modsecFileChecker.sh" \ > > > "auditlog,id:50,rev:1,severity:CRITICAL,msg:'PHP > file upload > > > attempt',phase:2,t:none" > > > </IfModule> > > > > > > #### > > > > > > And here is the full level 9 output of my test. > > > #### > > > > <snip> > > > > > Second phase starting (dcfg 8a313c8). > > > [domain.com/sid#919ce70][rid#942d5d8][/uptest/index.php][4 > <http://domain.com/sid#919ce70%5D%5Brid%23942d5d8%5D%5B/uptest/index.php%5D%5B4> > > > <http://domain.com/sid#919ce70%5D%5Brid%23942d5d8%5D%5B/uptest/index.php%5D%5B4> > > > > <http://domain.com/sid#919ce70][rid#942d5d8][/uptest/index.php][4 > <http://domain.com/sid#919ce70%5D%5Brid%23942d5d8%5D%5B/uptest/index.php%5D%5B4> > > > <http://domain.com/sid#919ce70%5D%5Brid%23942d5d8%5D%5B/uptest/index.php%5D%5B4>>] > > > Input filter: Request body access not enabled. > > > > Input filter: Request body access not enabled. > > > > This was the key. > > > > <snip> > > > > > > > > > > > > > > Check the debug log (level 9) for something like this: > > > > > > [9] Multipart: Added part header "Content-Disposition" > "form-data; > > > name=\"uploadFile\"; filename=\"xml-fix.diff\"" > > > [9] Multipart: Added part header "Content-Type" > "text/x-diff" > > > [9] Multipart: Content-Disposition name: uploadFile > > > [9] Multipart: Content-Disposition filename: xml-fix.diff > > > [4] Multipart: Created temporary file: > > > > /apps/tmp/20081112-113554-SRswGn8AAQEAAG0CYu8AAADB-file-rBf70z > > > [9] Multipart: Changing file mode to 0640: > > > > /apps/tmp/20081112-113554-SRswGn8AAQEAAG0CYu8AAADB-file-rBf70z > > > [9] Multipart: Added file part 19df328 to the list: name > > "uploadFile" > > > file name "xml-fix.diff" (offset 165, length 727) > > > [9] Multipart: Added part header "Content-Disposition" > "form-data; > > > name=\"uploadFile\"" > > > [9] Multipart: Content-Disposition name: uploadFile > > > [9] Multipart: Added data to variable: Upload File > > > [9] Multipart: Added part 19dfde0 to the list: name > > "uploadFile" (offset > > > 1007, length 11) > > > > > > > > > As you can see, none of the Multipart entries you mentioned are > > > appearing in my log. Any ideas? > > > > > > > You (actually everybody) should read the "Processing Phases" > section in > > the docs: > > > > > http://www.modsecurity.org/documentation/modsecurity-apache/2.5.7/html-multipage/processing-phases.html > > > > This should help alleviate some confusion (especially > migrating from > > 1.9.x). I made a note to update the docs to mention the > directives that > > control the body phases (access, limits, etc). > > > > https://www.modsecurity.org/tracker/browse/MODSEC-33 > > > > -B > > > > -- > > Brian Rectanus > > Breach Security > > > > > > > > -- > Brian Rectanus > Breach Security > > -- Brian Rectanus Breach Security |