[clamav-users] CVE verification

Micah Snyder micasnyd at sourcefire.com
Thu Jul 5 15:22:11 EDT 2018


Apologies for the delay.  I believe you also asked this question in #clamav in IRC as well.

It is not 100% clear if the CVE's in question affect ClamAV because unrar diverged from the version we package with clamav as "libclamunrar" when they rewrote their C library in C++.  It's certainly difficult to say without the PoC files used to test it.

For #41: They changed a bunch of things in unpack20.cpp.  A part of that included changing their "DDecode" table from signed to unsigned.   Our ddecode table still uses signed integers, as theirs used to before the vuln patch.  I don't really know if that was the issue in question for #41 or if it's one of the other checks they added/modified. 

For #42: It appears that the patch is mainly adding the "& 0xff" bitmask:

-  ChSetB[DistancePlace]=ChSetB[NewDistancePlace];
+  ChSetB[DistancePlace & 0xff]=ChSetB[NewDistancePlace];

libclamunrar's equivalent already has a similar bitmask:
    unpack_data->chsetb[distance_place & 0xff] = unpack_data->chsetb[new_distance_place & 0xff];

In summary, I believe ClamAV 0.100.0 is not affected by CVE-2017-12942, but without some time consuming research or a Proof-of-Concept sample to test with I can't be certain if libclamunrar is affected by CVE-2017-12941.


Am 30.06.2018 um 22:04 Dajuan Mcdonald:
> Hi,
> Regarding CVE-2017-12941 and CVE-2017-12942, unrar-5.5.6 is affected.
> There is a fixed version of unrar-5.5.7. I am asking:
> [1] are the CVEs known to affect any versions of clamav, if so which
> versions are not affected? 
> [2] These are the vulnerable code examples:
> #Vulnerable unrar function (CVE-2017-12941)
> int DistNumber=DecodeNumber(Inp,&BlockTables.DD);
> unsigned int Distance=DDecode[DistNumber]+1;
> # Vulnerable unpack longlz (CVE-2017-12942)
> //ChSetB[DistancePlace]=ChSetB[NewDistancePlace];
> --------------------------------------------------
> I found this in clamav 0.100.0:
> ## ClamAV code: unpack20.c
> //int rar_unpack20(int fd, int solid, unpack_data_t *unpack_data)
> { ...
>     unsigned int bits, distance;
> dist_number = rar_decode_number(unpack_data, (struct Decode
> *)&unpack_data->DD);
> distance = ddecode[dist_number] + 1
> #ClamAV unpack longlz
> //static void long_lz(unpack_data_t *unpack_data)
> unpack_data->chsetb[distance_place & 0xff]
> chsetb[new_distance_place & 0xff] = distance;
> chsetb[distance_place & 0xff] = unpack_data->chsetb[new_distance_place
> & 0xff];
> it isn't clear to me (as I cannot read C code very well) if these are
> indeed affected by the CVEs mentioned above. Any one able to clarify?
> [3] Any commits one can point me to for varification of changes if any?
> Thank you and apologies if this is old or redundant news already
> resolved.
> Referece:  http://seclists.org/oss-sec/2017/q3/290
>  domhnall

More information about the clamav-users mailing list