mlogc can't parse entry

[bozhinov]

Hello,

I have Apache 2.4.52 x64 from apachelounge.com with mod_security 2.9.5 (CRS 3.3.2), both of them compiled with PCRE 8.45

I get "Invalid entry (failed to match regex)" when trying to use mlogc

I m not even gonna pretend I can eval this regex:
https://github.com/SpiderLabs/ModSecurity/blob/a06d8f8ce74d423885a1f09a74c060bb21dd7485/apache2/mlogc-src/mlogc.c#L97

Here is my httpd.conf:
SecRuleEngine On
SecDataDir /tmp
Include conf/owasp-modsecurity-crs/crs-setup.conf
Include conf/owasp-modsecurity-crs/rules/*.conf
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^2-5
SecAuditLogParts ABCDEFGHZ
SecAuditLogType Serial
SecAuditLog "|bin/mlogc.exe conf/mlogc.conf"

and my mlogc.conf:
CollectorRoot "C:/APACHE/logs"
ConsoleURI "https://127.0.0.1:9000/rpc/auditLogReceiver"
SensorUsername "test"
SensorPassword "testtest"
LogStorageDir "data"
TransactionLog "mlogc-transaction.log"
QueuePath "mlogc-queue.log"
ErrorLog "mlogc-error.log"
LockFile "mlogc.lck"
KeepEntries 0
ErrorLogLevel 2
MaxConnections 10
MaxWorkerRequests 1000
TransactionDelay 50
StartupDelay 5000
CheckpointInterval 15
ServerErrorTimeout 60

I tried with different values for SecAuditLogParts but it did not seem to help

Log here:
https://bojinov.info/mlogc-error.log

Steps to reproduce the behavior:

A curl command line that mimics the original request and reproduces the problem
https://x.x.x.x/aphpfilethatdonotexist.php?something=../../etc

What am I doing wrong ?

Momchil

[martinhsv]

Hello @bozhinov ,

I haven't investigated your report in any detail, but ...

There are some line-length limits in the overall functionality, and some CRS rules can result in very long lines due to their use of tags. One thing you could try is to experimentally remove several of the 'tag:' lines from the relevant rules so that the resultant log line is much shorter. I'm not predicting that that is your problem, but it's something pretty easy to try and either confirm or rule out.

Something else curious is the mlogc.c that you linked to at the outset. I'm curious as to how you got there. It appears to be a much older version of mlog.c that is in v2/master (or v2.9.5), ... and with a different path ( https://github.com/SpiderLabs/ModSecurity/blob/1dd1c6defd635625537ff8865b1ee47a4d89c733/mlogc/mlogc.c#L96 )

[bozhinov]

I was looking for the source code for mlogc to check what that regex pattern was that failed
I was unable to find it in the master branch so I googled it :)
figured it wouldn't have changed much (the regex)

By the way I have a fairly standard setup - so I m guessing not much use of mlogc on Windows
I could use that v3 HTTPS option right about now.
.. or a persistent socket

Thank you for the tip. Will test is as soon as I can and provide feedback

[bozhinov]

OK. so no change after removing all tags from the rule I hit with the test url
I also tried removing the H part of the log as it contained the longest entries - Apache-Error & Message
Did not help either

[ABrauer-CPT]

I have the same error.
"Invalid entry (failed to match regex)"

I updated Apache and mod_security2. Before update everything was ok.
Before update without error:
Apache httpd 2.4.49 (Build from ApacheLounge)
mod_security2 2.9.3 (CRS 3.3.2)

After update with error:
Apache httpd 2.4.53 (Build from ApacheLounge)
mod_security2 2.9.5 (CRS 3.3.2)

[martinhsv]

Posting one or more (minimal, and without any secure information) log entries that cause this failure might help. Any nonprintable characters should be included clearly.

A likely avenue of investigation here is around line endings. This could be related to the normal difference between Windows and Linux, PCRE options related to line endings, or both.

[ABrauer-CPT]

@martinhsv It's not a particular entry. mlogc failed on every entry. I updated one of three apache server without configuration change. Before update the same entrys were transfered correctly.

[ABrauer-CPT]

@martinhsv
Example log line without ip's (mlogc-error.log):
Invalid entry (failed to match regex): - - [08/Apr/2022:11:50:09.-533325 +0200] "GET /downloads HTTP/2.0" 200 4268 "-" "-" YlAFT5Fwfo_g_Nujl-DDlAAB9X8 "-" /apacheservice/20220408/20220408-1150/20220408-115009-YlAFT5Fwfo_g_Nujl-DDlAAB9X8 0 6416

[ABrauer-CPT]

After some tests I think it is the log entries timestamps that triggers the regex error:
Log entry timestamp mod_security 2.9.3: [12/May/2022:10:59:43 +0200]
Log entry timestamp mod_security 2.9.5: [12/May/2022:10:27:55.867925 +0200]

[ABrauer-CPT]

The logline_pattern in mlogc.c should be modified:

mlogc.c line 99
- "\\ \\[([^:]+):(\\d+:\\d+:\\d+)\\ ([^\\]]+)\\]"
+ "\\ \\[([^:]+):(\\d+:\\d+:\\d+\\.\\d+)\\ ([^\\]]+)\\]"

or the timestamp format should be modified to the 2.9.3 format.

[ABrauer-CPT]

The new timesstamp format was added in mod_security 2.9.4 with issue #2095 .

[martinhsv]

Thanks for digging into that @ABrauer-CPT . I think you've found the explanation.

I'll put that into a pull request.

[ABrauer-CPT]

Hello @martinhsv,
that sounds good.

I don't really know if it's enough to change

mlogc.c line 99
to "\\ \\[([^:]+):(\\d+:\\d+:\\d+\\.\\d+)\\ ([^\\]]+)\\]"
or to something like "\\ \\[([^:]+):(\\d+:\\d+:\\d+\\.?\\d*)\\ ([^\\]]+)\\]" to catch the "old" and "new" format.

I could not determine how the timestamp regex-group would be processed in the rest of the code.

[martinhsv]

Thanks again.

Let me know if you encounter any difficulties.

[SteffenAL]

To test go to: download removed

[ABrauer-CPT]

Thanks @martinhsv and @SteffenAL .

I tested this patch.
At first it looks good. Entries were processed correct but i had cases with a negative value within the timestamp.

[12/May/2022:10:27:55.-123245 +0200]
In this cases the regex-pattern failed.

We should add something like "-?"
mlogc.c line 99 "\\ \\[([^:]+):(\\d+:\\d+:\\d+(?:[.]-?\\d+)?)\\ ([^\\]]+)\\]"

[ABrauer-CPT]

@martinhsv @SteffenAL

Or is this a bug and the timestamp should never include a negative value?

[martinhsv]

I cannot see any reason why the microsecond portion of the timestamp could ever make sense as a negative number. It smells like a bug independent of the regex adjusted as part of this issue.

[martinhsv]

I had a look at the code and did not see any obvious bugs.

Also I tried to reproduce the reported effect but, even with thousands of requests, I was not able to do so; the '-' never appeared.

[ABrauer-CPT]

I could reproduce this problem on Windows with this code snippet:
The middle part is copied from msc_util.c line 1128-1139.

#include "stdio.h"
#include "apr_time.h"
#include "apr_strings.h"

int main() {
    int i;
    for (i = 0; i < 200; i++)
    {
        apr_time_exp_t t;
        char tstr[100];
        apr_size_t len;

        apr_time_t now = apr_time_now();
        apr_time_exp_lt(&t, now);
        apr_strftime(tstr, &len, 80, "%d/%b/%Y:%H:%M:%S.", &t);
        apr_snprintf(tstr + strlen(tstr), 80 - strlen(tstr), "%06ld %c%.2d%.2d",
            ((long)now) % 1000000L,
            t.tm_gmtoff < 0 ? '-' : '+',
            t.tm_gmtoff / (60 * 60), (t.tm_gmtoff / 60) % 60);

        printf("time(tstr): %s\n", tstr);
        Sleep(50);
    }
    return 0;
}

[martinhsv]

I suspect the cast '(long)now'.

The value returned by apr_time_now() is explicitly 64 bits, but I expect in your case (on Windows) the type 'long' is only 32 bits. This would explain why my test on Linux+Apache+ModSecurity v2 did not have the problem.

[ABrauer-CPT]

I think you found the "bug".
If i change the datatype to 'long long' it seems to work correctly.

Perhaps someone with more programming experience could confirm this.

[martinhsv]

Hi @ABrauer-CPT

I have created a pull request ( #2753 ) for that issue if you want to test it out in Windows.

(I have run some tests on it but not in a Windows setup.)

[ABrauer-CPT]

Thanks @martinhsv
I have tested your code with my little code snippet and it worked as expected.

Perhaps @SteffenAL from Apachelounge could compile the modsecurity module with this patch to test the complete processing.

[SteffenAL]

For test, see https://www.apachelounge.com/viewtopic.php?p=41253#41253

[ABrauer-CPT]

I tested this patch in our environment and it works without errors. I have an eye on it in the next days but I think we found all bugs.

Many thanks to @martinhsv and @SteffenAL . Great work!

[martinhsv]

Thanks for the assistance with verification. #2753 has been merged.