OK, I see that there have been some major improvements with file scanning in 1.5.1.0 build 1.03. Thank you.
Now, the command line is launched correctly, and the regexes match as they should. There is a new issue, though, with the SMTP error code that is returned to the sending MTA on detecting an infection. NDRs generated contain something like the following: Reporting-MTA: dns;blu0-omc2-s21.blu0.hotmail.com Received-From-MTA: dns;BLU144-W44 Arrival-Date: Mon, 23 Mar 2009 04:57:17 -0700 Final-Recipient: rfc822;[email protected] Action: failed Status: 5.7.1 Diagnostic-Code: smtp;554 5.7.1 Mail appears infected with 'a virus' - <path>\a.1.49215.eml: <full scan results> Where <fn> is the local path on the server to the temp file created by ASSP for scanning, and <full scan results> contains the *complete* multi-line textual output of the command line scanner. This exposes part of the server's internal file structure someone sending a virus, and also exposes potentially significant details about the antivirus installed on the server. This information could be potentially very valuable to an attacker. Please, remove this from the SMTP response. Since the ASSP code is not able to grab an infection name from the command line scanner (though it might be possible using a group in the regex, albeit admittedly placing an overly complex task on the ASSP admin), why not just write: 554 5.7.1 Mail appears infected with a virus -----Original Message----- From: Steve Moss Sent: Sunday, March 22, 2009 8:39 PM To: '[email protected]' Subject: RE: [Assp-test] Antwort: Here's Just How Bad DoFileScan Is ... and while you are looking at all the other issues, here's another one: your change in build 1.01 that targets a fix for the invalid SMTP error response, now returns this to the sending MTA: Reporting-MTA: dns;bay0-omc2-s41.bay0.hotmail.com Received-From-MTA: dns;BAY116-W24 Arrival-Date: Sun, 22 Mar 2009 13:34:09 -0700 Final-Recipient: rfc822;[email protected] Action: failed Status: 5.7.1 Diagnostic-Code: smtp;554 5.7.1 Mail appears infected with '' - Ignoring the trailing " -" (which also needs fixing), the infection name part is obviously missing. Looking at the ASSP code, this is not surprising. The code uses a variable called $infection to include the found infection, but (a) there is nowhere in ASSP that this variable gets set, and (b) the GUI provides no way for the name of the infection to be returned from the command line scanner anyway. Would it not be best simply to remove all this code to do with DoFileScan, and wait until it has been thought through properly, integrated properly with ASSP and tested properly? Trying to slip this in at the end of a beta test cycle isn't the right way, and can only result in this kind of very poor quality. -----Original Message----- From: Steve Moss Sent: Sunday, March 22, 2009 4:53 PM To: 'ASSP development mailing list' Subject: RE: [Assp-test] Antwort: Here's Just How Bad DoFileScan Is Well, even with the 'fixes' you propose, this leaves some issues. The regexes I specify are actually correct, and when the command is run correctly, STDOUT does contain the match strings as specified. Your code is still not running the correct commands (actually - it is running NO command, see below. Proving this with ASSP's logging isn't possible, though, because it fails to log the command it runs to either the ASSP log file (even with ScanLog set to 'diagnostic') or to the debug file, when DEBUG logging is enabled. I can run the correct command *manually*, and it always writes one of the regex matches to STDOUT. I would suggest that your code still fails to run the correct command. I can see from monitoring processes on our server, ASSP never actually runs the command it is supposed to. This is also confirmed by the ASSP log entries... Mar-22-09 16:46:56 id-40406-03347 65.54.246.173 <[email protected]> to: [email protected] diagnostic: FileScan will run Mar-22-09 16:46:56 id-40406-03347 65.54.246.173 < [email protected] > to: [email protected] diagnostic: FileScan returned ... notice the timing of the log entries: they are both timed at 16:46:56, suggesting the command finishes in less than half a second. It doesn't. If run manually, the command takes around 7 seconds to complete. Even if you get your code to run the file scan command, note the following line in your code: $runfile = "'" . $runfile ."'" if $runfile =~ / /; In Windows, filenames with spaces need to be quoted with *double quote* characters, not single quote. There really is no substitute for you actually *testing* your code. -----Original Message----- From: Thomas Eckardt/eck [mailto:[email protected]] Sent: Sunday, March 22, 2009 11:28 AM To: ASSP development mailing list Subject: [Assp-test] Antwort: Here's Just How Bad DoFileScan Is I've just looked in to the V2 code and I'm missing a line ($this->{averror}=$AvError . " - $res";) - I think while doing some cosmetics after testing, I've deleted this line, so the SMTP responds is wrong for this reason. The code is ported from V2 in to V1 - and you are right, &ThreadYield() is only available (and needed) in V2 - Fritz will change this. >FileScanBad:=Infected files: [1-9]+ >FileScanGood:=Infected files: 0 If you are using both - both must match / not match! The checks are : failed if FileScanBad is defined and matches failed if FileScanGood is defined and does not match <- this is the case in your log so defining both, does not make sense in 95% cases. >The FileScanBad regex matches erroneously >to: [email protected] diagnostic: FileScan returned <- here should follow the returned string !!!! What should we do, if nothing returns from the command? I recommend writing your own small shell script to do the scan stuff and writing there some usefull strings to STDOUT or STDERR! Thomas "Steve Moss" <[email protected]> 22.03.2009 11:30 Bitte antworten an ASSP development mailing list <[email protected]> An <[email protected]> Kopie Thema [Assp-test] Here's Just How Bad DoFileScan Is OK, here's a more comprehensive report of the multiple problems with DoFileScan in ASSP 1.5.1.0 0.08. 1. asspl.pl contains calls to $ThreadYield(), on lines 17786 and 17794, but $ThreadYield is not defined anywhere. For further testing I commented out these two bad lines. 2. The FileScanBad regex matches erroneously, as the following log lines suggest (email addresses changed for privacy reasons): Mar-22-09 10:09:34 id-16573-07653 65.54.246.175 <[email protected]> to: [email protected] MessageScore is now -25, after adding -25 (SPFpass) Mar-22-09 10:09:34 id-16573-07653 65.54.246.175 <[email protected]> to: [email protected] diagnostic: FileScan will run Mar-22-09 10:09:34 id-16573-07653 65.54.246.175 <[email protected]> to: [email protected] diagnostic: FileScan returned Mar-22-09 10:09:34 id-16573-07653 65.54.246.175 <[email protected]> to: [email protected] FileScan: scanned 4069 bytes in whitelisted message Mar-22-09 10:09:34 id-16573-07653 65.54.246.175 <[email protected]> to: [email protected] MessageScore is now 25, after adding 50 (virus detected: 'FileScan' - ) Mar-22-09 10:09:34 id-16573-07653 [VIRUS] 65.54.246.175 <[email protected]> to: [email protected] [spam found] (virus detected: 'FileScan' - ) [Test]; The relevant config settings are as follows: DoFileScan:=1 FileScanDir:=d:\assp\virusscan FileScanCMD:="C:\Program Files\ClamWin\bin\ClamScan.exe" -d "C:\Documents and Settings\All Users\.clamwin\db" --remove --stdout FILENAME FileScanBad:=Infected files: [1-9]+ FileScanGood:=Infected files: 0 3. ASSP returns an invalid SMTP response to the sending MTA, as seen here by the NDR generated by the sender's MTA: Reporting-MTA: dns;bay0-omc2-s39.bay0.hotmail.com Received-From-MTA: dns;BAY116-W52 Arrival-Date: Sun, 22 Mar 2009 03:09:32 -0700 Final-Recipient: rfc822;[email protected] Action: failed Status: 5.5.0 Diagnostic-Code: smtp;500 Non RFC-compliant response received ---- It is clear this code has not been tested in the slightest, and I am amazed it could be offered as part of a so-called RC release. ------------------------------------------------------------------------ ------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test DISCLAIMER: ******************************************************* This email and any files transmitted with it may be confidential, legally privileged and protected in law and are intended solely for the use of the individual to whom it is addressed. This email was multiple times scanned for viruses. There should be no known virus in this email! ******************************************************* ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Assp-test mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/assp-test
