Return-Path: harlequin...@gmail.com First off, my apologies for the confusion. This is my first time posting to a mailing list; I didn't really know how to handle the return path thing, so I had to start over. Is this better? The return path goes at the top of the message body, right? Or is it the subject line? The verbiage on the ML FAQ is a little ambiguous. To be honest, it would also help if a link to that FAQ page was included in the introductory mailing list email--and among the mailing list rules here:
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users I had to manually search out the following page in order to find the correct syntax for the return path: http://www.clamav.net/documents/mailing-lists-faq Not a big deal. Just an idea to help make things a little smoother for N00bs. Secondly, thank you, Al, for such a prompt response. All three of those MP4 entries in the database appear to pertain to Adobe Flash Player, which, by default, shouldn't affect most Linux users. Regarding the JPEG thing: I guess I misspoke. Sorry about that. It's actually a submodule. At least that's what stdout says when I run clamscan in debug mode: ... LibClamAV debug: Module OTHER: On LibClamAV debug: * Submodule UUENCODED: On LibClamAV debug: * Submodule SCRENC: On LibClamAV debug: * Submodule RIFF: On LibClamAV debug: * Submodule JPEG: On ... The impression I've gotten from general web-surfing is that there are a good number of anecdotal reports of media file trojans. Then again, there's a substantial difference between a personal anecdote and a formal signature that can be used by a malware scanner. :/ In cases as simple as a false file extension, would the scanner be able to identify the difference? What about a malicious header, a la CVE-2017-2992? I guess I'm just wondering where in the process the scanner decides that the file is a legitimate MP3/4 that doesn't need to be scanned. Even if all the metadata, header, footer, etc. were completely legitimate, wouldn't it still be theoretically possible to embed an executable deep within the actual media binary, where it would evade casual inspection? This is probably a stupid idea, but could some sort of heuristic be used to efficiently distinguish hidden executable code like that, or would the only solution thereof be a deep, slow scan? I draw some comfort from the strong division UNIX maintains between root and user accounts. Unless a separate privilege escalation vulnerability was simultaneously exploited, the amount of damage from a media trojan ought to be limited. But given that the browser is also a user-level application, would it be possible for a malicious media process to infect the browser and potentially sniff out passwords, etc.? Granted, the browser is run as a separate user, but it still seems like a massive attack surface. As I'm sure you can tell, I am still getting a feel for the security issues associated with UNIX, so I appreciate you folks bearing with me, here. I'm just trying to figure out how to achieve a reasonable degree of certainty that my media files are clean. Thus far, apart from the VirusTotal thing, I'm drawing a blank. One last thing worth noting: I uninstalled VLC when I ran debsecan and saw the numerous vulnerabilities associated with it. The replacement players don't seem to have nearly the same number of issues. Thank you so much! ~Crystalslave P.S. Since this message is starting the thread over, I had to manually include the two prior posts. I know the formatting is off, but at least it's all in the same place. Ugh... --- Al Varnell alvarnell at mac.com Tue Sep 19 02:45:20 EDT 2017 I'm not aware of a specific module devoted to JPEG files, although there are a handful of Jpeg related signatures, there is no mention of a separate module or engine in the Signatures documentation. Can you tell us where you learned of it? The topic of .MP3's has been discussed here before. They are being purposely ignored as evidenced by this section of the database: daily.ftm 0:0:494433:MP3:CL_TYPE_ANY:CL_TYPE_IGNORED 0:0:fffb90:MP3:CL_TYPE_ANY:CL_TYPE_IGNORED I don't believe anybody could come up with a malware sample to support changing this decision, but I don't believe anybody from the ClamAV stepped up to defend it. You can find a lot of speculation on how media files could contain malware, but the only description of actual malware involved files that were disguised with an .mp3 file name extension that were actually something like an windows .exe file. A search of VirusTotal shows over 2,000 hits, but after running through the top 20 hits, all actual media files were found to be clean by all scanners or simply had the letters mp3 in the file name of a non-media file. I've seen reports of several other scanners that purposely ignore .mp3 files, so that could be one reason. I was able to locate three signatures for MP4 malware in the database, but only one uses the byte code engine. The other two are hash values: BC.Mp4.Exploit.CVE_2017_2992-5819336-0 Mp4.Exploit.CVE_2015_8658-1 Mp4.Exploit.CVE_2016_1096-1 I was not able to locate any AVI specific signatures. That's all I have time for tonight. -Al- On Sep 18, 2017, at 10:28 PM, Crystalslave <harlequin738 at gmail.com> wrote: > Good evening, all. > > First off, my thanks to the development team for creating and > maintaining this great tool. > > This message is being sent out to express my concern over a potential > vulnerability that Clamscan doesn't currently seem to address. It is > particularly alarming, because, as far as I can tell, ClamAV is the > premiere malware scanner available for Linux (or at least for > Debian--my personal OS). > > For those Linux users who may have a substantial amount of old audio > and video files in their possession (many of them from their Windows > days), what is the suggested solution for retroactive scanning? > > I know there is a Clamscan module for JPEG files. To me, that seems to > constitute a tacit acknowledgement of the possibility that trojans can > be disguised within media files. But there isn't any equivalent module > for scanning MP3's, MP4's, AVI's, and other such files, is there? I've > seen no indication of such. > > As a stopgap measure for such Linux users, any newly-acquired files > could be sent to VirusTotal to be scanned there. But dependence upon a > cloud-based service hardly seems ideal to me, especially for those who > may have substantial numbers of old files already in > possession--mostly music, ponies, and anime that have all been legally > acquired over the years. > > I'm sure there must be some sort of significant hurdle associated with > this proposition. Would someone be willing to enlighten me to this > end? It seems too common-sense to ignore for frivolous reasons, > especially since such a media module would be useful for more than > just personal files. Enterprises could benefit as well. > > Thank you so much for your time. _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
