. Re: Detection in windows but not Linux (Kurt Fitzner)
>> 7. Re: Detection in windows but not Linux (Kurt Fitzner)
>>
>>
>> --------------
>>
>> Message: 1
>> Date: Sun, 13 Dec 2015 17:42:32 +000
; Date: Sun, 13 Dec 2015 17:42:32 + (GMT)
> From: "G.W. Haywood"
> To: clamav-users@lists.clamav.net
> Subject: Re: [clamav-users] Detection in windows but not Linux
> Message-ID:
>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> Hi the
To my embarrassment, the Windows/Linux detection issue was mostly of my
making. WinSCP does CR/LF translation of text files by default. The rest
you can now all guess. I transferred the malware from my Linux box using
a LF -> CR/LF translation mode by mistake. It is the CR/LF version that
is det
The file is the classic "FilesMan" backdoor. It's been around for a
while. I always look at VT for anything suspicious, but I just re-ran it
through. 15 out of 54 AV's surveyed find it stinky. Here's the link:
https://www.virustotal.com/en/file/6e709d5679eac7c8d844f849b0c6e95f4b3f8b716fbae4c27
I didn't expect the test signature to be successful as my understanding of the
way the scanner works requires an exact match to the ASCII string. My
familiarity is with ClamXav for OS X which uses an unmatched version of the
UNIX ClamAV engine and have no idea what ClamWin uses that might cause
Hi Al,
Just got home ans was able to test. Test signature from Steve fails to
detect on both Linux and Windows. Tested on Linux with 0.98.7 supplied
Debian binaries, and 0.99 binary compiled by myself. Tested in Windows
with ClamWin supplied binary.
Should I submit my copy of the malware som
I would want to know the results of using the test signature on both systems
first, and file a bug report if it turns out to be a ClamAV problem.
Sent from Janet's iPad
-Al-
On Dec 13, 2015, at 11:49 AM, Kurt Fitzner wrote:
> The question remains as to why the signature correctly leads to a mat
The question remains as to why the signature correctly leads to a match in
Windows but not Linux. If carriage return linefeed handling differences
between the two OSes are to blame, then I suggest a two pronged approach.
Correct the signatures, AND patch clamav so that the signatures as writte
Hi there,
On Sun, 13 Dec 2015, Arnaud Jacques wrote:
For me PHP.Shell-83 is wrong. It contains 0d0a. It means it has been created
with a non-normalized ascii file.
I guess it should be corrected.
In my current main.cld, 4636 of the approximately 2.4 million
signatures in the file contain the
On Sun, December 13, 2015 2:25 am, Kurt Fitzner wrote:
>
> The file is definitely malware - it was injected through a WordPress
> vulnerability. I have a virus scan that runs hourly on my wordpress folder
> just for that reason, but this one slipped through the cracks. I want to
> find out what
I guess I don’t know what a “non-normalized ascii file” is. 0d0a is just an
ASCII carriage return & line.
It’s also a relatively old signature, so one would hope that if it needed
correction that would have happened by now.
-Al-
On Dec 12, 2015, at 11:50 PM, Arnaud Jacques / SecuriteInfo.com
Hello Kurt,
> is detecting as PHP.Shell-83,
For me PHP.Shell-83 is wrong. It contains 0d0a. It means it has been created
with a non-normalized ascii file.
I guess it should be corrected.
Best regards,
Arnaud Jacques
SecuriteInfo.com
Facebook : https://www.facebook.com/pages/SecuriteInfocom/1
Hello,
I am trying to identify what kind of support is missing from a Linux
binary of ClamAV. I have a file that clamscan for windows (from ClamWin)
is detecting as PHP.Shell-83, but where clamscan on Linux Debian won't
detect anything. Both are using the same engine version (0.98.7), and
whil
13 matches
Mail list logo
