The plugin has a simple mechanism to prevent it from using too many resources during a scan. However, implementing an optimized high-level garbage collector in a scripting language like PHP is very difficult if not impossible. The limits set before the scan can be affected by other operations [1].
The warning that you got in “fileinfo.lib.php” line 427 [2] hints us that the problem is during the reading of a file. The file seems to be so big that it doesn’t fit in the memory space allocated by the PHP interpreter.
However, the error is not necessarily with this code, the plugin could be allocating more memory elsewhere and is just here where the PHP interpreter decided to stop the process because it already reached the limit set by “memory_limit” [3].
The solution is not to increase your memory limit, but to modify the file reader to take in consideration the amount of memory available. The problem with this approach is that a hacker can inject a file big enough to be skipped by the scanner, and then put the malicious code at the end.
For now, I suggest you to use the “Ignore Files And Folders During The Scans” panel located in the settings page to instruct the plugin which folder(s) can be skipped during a scan. This will —hopefully— reduce the memory consumption and maybe fix the problem until I can design a better scanner.
I will keep investigating.
[1] https://en.wikipedia.org/wiki/Race_condition
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ceaf0d2/src/fileinfo.lib.php#L417-L428
[3] http://www.php.net/manual/en/ini.core.php#ini.sect.resource-limits
Great answer and explanation of the issue! This helps to identify the file and exclude it (or possibly reduce its size) myself.
Thank you! 🙂
Hi @yorman
I had time to investigate the issue and could find the reason as well as a possible fix, that seems secure:
On my site I found two rather large log files in the uploads/sucuri folder, namely sucuri-oldfailedlogins.php (with more than 300 MB!) and sucuri-auditqueue.php (roughtly 60 MB).
The function SucuriScanFileInfo::fileLines() would try to read the whole file at once, which is not possible with most memory settings.
My solution was, to simply delete those files, as I did not need the audit/login history.
This looks like an issue that will appear again in the future, as those logs start to increase in size again. Possibly we need a way to prevent those files getting too big or the option to move those logs to the DB…
Philipp 🙂
Hello @strackerphil-1 , your investigation was very helpful.
I will implement the code to prevent the Sucuri logs from taking so much space.
I will try to have these changes ready before the next version is released.
Marking ticket as “not resolved” while I work on this case.
Thank you
Had the same issue. Finally found this thread and deleting those two files solved the issue. I’m guessing a fix hasn’t been pushed out yet.
