maldet --clean gives file path error on /usr/local/maldetect/quarantine/., aborting.

[savvyaviator]

This is actually an old issue that was reported two years ago, but still hasn't been fixed.

The cause is pretty obvious: The function clean_hitlist() requires (but does not have) the same code that quar_hitlist() does in order to define the variables $file_name, $file_owner, $file_group, $rnd, etc. before it invokes clean() with arguments that use all those variables. Because $file_name is undefined at the time clean_hitlist() calls clean(), clean() gets a $1 parameter consisting solely of a "." and barfs when it discovers that /usr/local/maldetect/quarantine/. is not a file.

This means that the only way to clean is during a scan. You cannot scan without cleaning and then use maldet --clean SCANID afterwards as intended.

[mikeohara]

Can confirm. Happening for 1.5 - Ran a scan and now unsure how to recover the files other than to restore from backups

[rfxn]

@mikeohara this should be relative to post-run cleans only. If in doubt you can download / install LMD 1.6rc6 at https://github.com/rfxn/linux-malware-detect/releases/tag/1.6-rc6. On install it should import all your quarantine and session information and then you can run a 'maldet --restore SCANID'.

Thanks

[ghost]

Thanks @rfxn! I will give it a shot.

[Gazoo]

Unfortunately this still isn't fixed with the 1.6 release. I did a fresh install and tested:

HOST:      el7p17.test.com
SCAN ID:   170320-2319.3090
STARTED:   Mar 20 2017 23:19:13 -0600
COMPLETED: Mar 20 2017 23:19:14 -0600
ELAPSED:   1s [find: 0s]

PATH:          /var/www/vhosts/example.com/
TOTAL FILES:   100
TOTAL HITS:    1
TOTAL CLEANED: 0

FILE HIT LIST:
{CAV}Eicar-Test-Signature : /var/www/vhosts/example.com/httpdocs/eicar.com.txt => /usr/local/maldetect/quarantine/eicar.com.txt.2996118952
===============================================
Linux Malware Detect v1.6 < [email protected] >

#  maldet --clean 170320-2319.3090
Linux Malware Detect v1.6
            (C) 2002-2017, R-fx Networks <[email protected]>
            (C) 2017, Ryan MacDonald <[email protected]>
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(3625): file path error on /usr/local/maldetect/quarantine/., aborting.

[markyama]

I'm also getting this with v1.6:

./maldet --clean 170321-0911.2035

Linux Malware Detect v1.6
(C) 2002-2017, R-fx Networks [email protected]
(C) 2017, Ryan MacDonald [email protected]
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(20608): file path error on /usr/local/maldetect/quarantine/., aborting.

Also, not sure why the clean does not happen on the scan as I think I have the conf setup to clean on scan:
quarantine_hits="1"
quarantine_clean="1"

Thanks-
Mark

[ericknyoto]

I'm also getting this error with v1.6

[Gazoo]

Considering that this has been broken for almost 2 years now wouldn't it be better to just deprecate and remove this functionality from maldet now? Really bad that this wasn't fixed in 1.6 as it makes the project look bad and confuses users :(

[SilverNodashi]

Having the same issues with V1.6. Does it mean that the quarantine function doesn't actually work? Which in turn probably means cleaning doesn't work either?

[leefenix]

I am having the same issues as everyone above on 1.6.1 still. Does not matter if its a post-run clean or if I had the config set to auto quarantine and clean. Same issue.

[gdb721]

Same issue here on v 1.6.2:

maldet --clean 170719-1131.29879

Linux Malware Detect v1.6.2
(C) 2002-2017, R-fx Networks [email protected]
(C) 2017, Ryan MacDonald [email protected]
This program may be freely redistributed under the terms of the GNU GPL v2

maldet(12781): file path error on /usr/local/maldetect/quarantine/., aborting.

[saadismail]

Same issue here on v1.6.2

[Gibsonion]

Yep same here 1.6.2

[Gibsonion]

What happens if I just delete all the files in quarantine? would that for all intents and purposes clean them? Or are the files in the quarantine only reference files?

[JamesAndresCM]

Same issue ( v1.6.2 ), but i think that problem can be validation argv $file "/usr/local/maldetect/quarantine/."

---

function clean() if [ -d "$cldir" ] && [ "$quarantine_clean" == "1" ] && [ "$quarantine_hits" == "1" ] && [ -f "$file" ];

---

I debugging and the results are :

cldir= /usr/local/maldetect/clean
quarantine_clean = 1
quarantine_hits = 1
file =/usr/local/maldetect/quarantine/. <--- ¿?

[lucianlazar1983]

I confirm the same problem, also when run from inotify does not detect viruses anymore. It is really inconsistent and we will be forced to look for alternative solutions. Too bad, a good project left for dead.

[teachblue]

I just wanted to add that I am facing the same problem, too, on an Ubuntu 14.04 LTS server running v1.6.2 of Maldet.

root@username:~#
maldet --clean 180409-0948.9791
Linux Malware Detect v1.6.2
(C) 2002-2017, R-fx Networks [email protected]
(C) 2017, Ryan MacDonald [email protected]
This program may be freely redistributed under the terms of the GNU GPL v2
maldet(14840): file path error on /usr/local/maldetect/quarantine/., aborting.

I had set ClamAV as the scanning engine and enabled the option to quarantine and clean automatically, but the malware files got quarantined with a message that cleaning failed. Then, I changed the maldet config file to not use ClamAV as the scanning engine and ran Maldet again and it didn't find any malware files on the scanned directory, so it looks like the original scan worked.

I am not sure if deleting the malware files from quarantine will ensure they are gone for ever. One other thing I noticed is that using Maldet without ClamAV as the scan engine takes nearly 10 times as long to scan the same folder. See the time difference in the scan reports below:

root@username:~#
maldet --report list
Linux Malware Detect v1.6.2
(C) 2002-2017, R-fx Networks [email protected]
(C) 2017, Ryan MacDonald [email protected]
This program may be freely redistributed under the terms of the GNU GPL v2
Apr 9 2018 14:44:35 | SCANID: 180409-1444.27847 | RUNTIME: 18109s | FILES: 255424 | HITS: 0 | CLEANED: 0
Apr 9 2018 09:48:11 | SCANID: 180409-0948.9791 | RUNTIME: 2280s | FILES: 255717 | HITS: 4 | CLEANED: 0

It is a bit disheartening that this particular issue hasn't been fixed for nearly two years.

[rfxn]

This has been fixed in master relative commits ed6a406 and b6a3428. Thank you all for your patience, this will push to stable release 1.6.4 in the coming days.

[leemathewbrooks]

This still appears to be an issue and 1.6.4 hasn't been released yet - do you happen to have an eta?

[alvahdati]

The same issue even on1.6.4 after maldet -u. Seems this has not been fixed yet. @rfxn

[0d0a]

Confirm problem still exists

[Achaean]

+1 from me too (an a Debian oldstable based system).
Sometimes it detects the directory, sometimes not.

I think it would be a good addition, an option, for scanning the current directory.

[Maryam-Nasseri]

This problems still exists in v1.6.4 because maldetect is automatically installed in home directory (I'm referring to Ubuntu 20.04 now), not in usr/local/as it used to be installed. Even when I specify the full path to maldet, it still says that it cannot find the command; it cannot also find the 'intcnf' which in this version, is stored in 'internals' as 'internals.conf'. I guess they did not update their code accordingly to be able to find the files.

[10corp]

Restoring a Files accidentally removed with Maldet & all files are in /usr/local/maldetect/quarantine/. How to restore.Also how to find all SCANID