Solved CVE_2013_3860-1 found in freebsd-update file

Anubas

Anubas

My ClamAV scan (engine version: 0.99.2) just found the following:

Code: 
/var/db/freebsd-update/files/c822bfa33df8b376f97c676f60f601bd091b3cfc51b4bcb73f01c6308432d37b.gz: Xml.Exploit.CVE_2013_3860-1 FOUND

I uploaded the file to https://www.virustotal.com and received a 0/54 detection ratio (their ClamAV rated the file harmless). The file was identified as billion-laughs.xml, which is an XML bomb or Exponential Entity Expansion attack per https://en.wikipedia.org/wiki/Billion_laughs. I checked the content of the file and it is an exponential entity expansion.

Has anyone else seen this? I am trying to figure out if freebsd-update really installed this file or not. The file timestamp reads Nov 3 2014.
 
Update: I checked my other servers and found the same file on all older boxes. I am thinking these are servers that were upgraded to FreeBSD 10.3 instead of having a clean FreeBSD 10.3 install. This make it seem likely that (1) the file really was created by freebsd-update and (2) the file is no longer circulating, which is what I was most worried about fixing.

Per the freebsd-update man page and https://forums.freebsd.org/threads/52830/, it is safe to delete files in the /var/db/freebsd-update directory as long you do not need to run freebsd-update rollback. File deleted.
 
False positive without a doubt. Virus scanners use what is known as "heuristic detection" and it misfires very often on random data files such as the one in this case.
 
ClamAV is mostly used to detect malware for other operating systems, not for threats against Unix / Linux servers. I wouldn't want to claim that it has absolutely no value scanning local-only files (I'd need to analyse its definitions in detail to be certain of that, and couldn't quickly find per-OS data for the definitions), but most of its purpose is for scanning files which will be accessed by a Windows client (and possibly OS X, iOS, Android, etc as well). I.e. there is little value in scanning non-shared filesystems, and anything flagged in non-shared filesystems will normally be a false positive which should be ignored. For this purpose, sharing is by any protocol, not just file sharing protocols, so also things like SMTP / POP3 / IMAP / HTTP / etc.

I certainly would not be routinely scanning all of /usr, /var, etc (on the assumption that those are either not shared, or only shared read only to other trusted Unix-like systems). If those system filesystems are writeable by remote systems (other than some quite narrow Unix-to-Unix cases and specific subdirectories), that is likely to be an invalid configuration which compromises the entire system. I would normally only ever use it to scan specific areas which contain remotely supplied/accessed data, to/from systems which do have the vulnerabilities that it scans for. Using it to scan Unix system filesystems would be a highly exceptional activity, and in response to something like recovery from a badly invalid config which allowed the possibility of Windows malware writing to those places.
 
You must log in or register to reply here.
Back
Top