clamav

mirror of https://github.com/Cisco-Talos/clamav.git synced 2025-10-19 10:23:17 +00:00

Author	SHA1	Message	Date
Val S.	82a321a589	Fix embedded RAR archive extraction issue If the current layer has a file descriptor, ClamAV is passing the path for that file to the UnRAR module, even if the RAR we want to scan is just some small embedded bit (e.g. detected by RARSFX signature). We need to drop the RAR portion to a new file for the UnRAR module because it does not accept file buffers to be scanned, only file paths. CLAM-2900	2025-10-13 23:44:45 -04:00
Val S.	4395c4bac1	Update Rust dependencies; Fix image fuzzy hash values Large range testing identified some files where image fuzzy hashing produces different hashes with ClamAV 1.5 vs 1.4. With my investigation, I found the issue is with changes in Rust library dependencies, though it actually wasn't any change with the 'image' or 'jpeg-decoder' crates. After running a simple `cargo update` to update all non-pinned versions. I confirmed that this does not affect the minimum supported Rust version (MSRV). CLAM-2899	2025-10-13 15:10:58 -04:00
Val S.	1b96e96c5c	Fix compiler warning Mismatched declaration and definition.	2025-10-13 15:10:58 -04:00
Val S.	f184a1e776	Increase limit for finding PE files embedded in other PE files I am seeing missed detections since we changed to prohibit embedded file type identification when inside an embedded file. In particular, I'm seeing this issue with PE files that contain multiple other MSEXE as well as a variety of false positives for PE file headers. For example, imagine a PE with four concatenated DLL's, like so: ``` [ EXE file \| DLL #1 \| DLL #2 \| DLL #3 \| DLL #4 ] ``` And note that false positives for embedded MSEXE files are fairly common. So there may be a few mixed in there. Before limiting embedded file identification we might interpret the file structure something like this: ``` MSEXE: { embedded MSEXE #1: false positive, embedded MSEXE #2: false positive, embedded MSEXE #3: false positive, embedded MSEXE #4: DLL #1: { embedded MSEXE #1: false positive, embedded MSEXE #2: DLL #2: { embedded MSEXE #1: DLL #3: { embedded MSEXE #1: false positive, embedded MSEXE #2: false positive, embedded MSEXE #3: false positive, embedded MSEXE #4: false positive, embedded MSEXE #5: DLL #4 } embedded MSEXE #2: false positive, embedded MSEXE #3: false positive, embedded MSEXE #4: false positive, embedded MSEXE #5: false positive, embedded MSEXE #6: DLL #4 } embedded MSEXE #3: DLL #3, embedded MSEXE #4: false positive, embedded MSEXE #5: false positive, embedded MSEXE #6: false positive, embedded MSEXE #7: false positive, embedded MSEXE #8: DLL #4 } } ``` This is obviously terrible, which is why why we don't allow detecting embedded files within other embedded files. So after we enforce that limit, the same file may be interpreted like this instead: ``` MSEXE: { embedded MSEXE #1: false positive, embedded MSEXE #2: false positive, embedded MSEXE #3: false positive, embedded MSEXE #4: DLL #1, embedded MSEXE #5: false positive, embedded MSEXE #6: DLL #2, embedded MSEXE #7: DLL #3, embedded MSEXE #8: false positive, embedded MSEXE #9: false positive, embedded MSEXE #10: false positive, embedded MSEXE #11: false positive, embedded MSEXE #12: DLL #4 } ``` That's great! Except that we now exceed the "MAX_EMBEDDED_OBJ" limit for embedded type matches (limit 10, but 12 found). That means we won't see or extract the 4th DLL anymore. My solution is to lift the limit when adding an matched MSEXE type. We already do this for matched ZIPSFX types. While doing this, I've significantly tidied up the limits checks to make it more readble, and removed duplicate checks from within the `ac_addtype()` function. CLAM-2897	2025-10-13 15:10:58 -04:00
Val S.	f7e9c511fc	Loosen restrictions on embedded file identification In regression testing against a large sample set, I found that strictly disallowing any embedded file identification if any previous layer was an embedded file resulted in missed detections. Specifically, I found an MSEXE file which has an embedded RAR, which in turn had another MSEXE that itself had an embedded 7ZIP containing... malware. sha256: c3cf573fd3d1568348506bf6dd6152d99368a7dc19037d135d5903bc1958ea85 To make it so ClamAV can extract all that, we must loosen the restriction and allow prior layers to be embedded, just not the current layer. I've also added some logic to prevent attempting to extract an object at the same offset twice. The `fpt->offset`s appear in order, but if you have multiple file type magic signatures match on the same address, like maybe you accidentally load two different .ftm files, then you'd get duplicates and double-extraction. As a bonus, I found I could also skip over offsets within a valid ZIP, ARJ, and CAB since we now have the length of those from the header check and as I know we don't want to extract embedded contents in that way.	2025-10-13 15:10:55 -04:00
Val S.	97f89f43e7	Fix issue detecting VBA projects Previously for documents containing VBA projects, the VBA was treated as an object within the document and not as a normalized version of the document. I apparently switched it say that the VBA is a normalized version of the document. This kind of makes sense in that presently Javascript extracted from HTML is treated as a normalized version of the HTML. But it probably shouldn't. Normalized layers are treated as the same file as the parent. So now those older signatures that match on VBA projects using "Container:CL_TYPE_MSOLE2" are failing to match. So this commit switches it back. VBA project bits written out to a temp file for scanning will be treated as being contained within the document. CLAM-2896	2025-10-13 15:10:29 -04:00
Val S.	045a809645	Fix issue recording OOXML document metadata The ZIP single record search feature is used to find specific files when parsing OOXML documents. I observed that the core properties for a PowerPoint file were missing in a test as compared with the previous release. The error handling check for the unzip search returns CL_VIRUS when there is a match, not CL_SUCCESS! CLAM-2886	2025-10-13 15:10:28 -04:00
Val S.	ea2ad8c879	Scan performance optimization for TNEF message scans Uncompressed ZIP-based TNEF message attachments, like OOXML office document attachments, get double-extracted because of embedded file type recognition. To prevent excessive scan times, disable embedded file type recognition for TNEF files and relay on TNEF parsing to extract attachments. CLAM-2885	2025-10-13 15:10:28 -04:00
Val S.	90949e434f	Fix ZIP parser issue recording empty file entries If csize (and usize) are 0, like with a directory or other empty file entry, then the functionionality to record file record information when indexing the central directory and each associated file record will neglect to store the `local_header_offset` or `local_header_size`. That causes problems later after sorting the file records and then checking for overlapping files. CLAM-2884	2025-10-13 15:10:26 -04:00
Val S.	92b4a3e291	Fix ZIP parser issue using central directory The function which indexes a ZIP central directory is not advancing to the next central directory record thus exceeding the max-files scan limit for many ZIPs. CLAM-2884	2025-10-13 15:09:36 -04:00

2 changed files with 573 additions and 429 deletions

992

Cargo.lock generated

View file

File diff suppressed because it is too large Load diff

									
										10

libclamav/scanners.c
									
										View file
										
				@ -534,9 +534,15 @@ static cl_error_t cli_scanrar(cli_ctx *ctx)

				    int tmpfd     = -1;

				#ifdef _WIN32

				    if ((SCAN_UNPRIVILEGED) || (NULL == ctx->fmap->path) || (0 != _access_s(ctx->fmap->path, R_OK))) {

				    if ((SCAN_UNPRIVILEGED) ||

				        (NULL == ctx->fmap->path) ||

				        (0 != _access_s(ctx->fmap->path, R_OK)) ||

				        (ctx->fmap->nested_offset > 0) || (ctx->fmap->len < ctx->fmap->real_len)) {

				#else

				    if ((SCAN_UNPRIVILEGED) || (NULL == ctx->fmap->path) || (0 != access(ctx->fmap->path, R_OK))) {

				    if ((SCAN_UNPRIVILEGED) ||

				        (NULL == ctx->fmap->path) ||

				        (0 != access(ctx->fmap->path, R_OK)) ||

				        (ctx->fmap->nested_offset > 0) || (ctx->fmap->len < ctx->fmap->real_len)) {

				#endif

				        /* If map is not file-backed have to dump to file for scanrar. */

				        status = fmap_dump_to_file(ctx->fmap, ctx->fmap->path, ctx->this_layer_tmpdir, &tmpname, &tmpfd, 0, SIZE_MAX);

Compare commits

10 commits

e98b0075e6 ... 82a321a589

992

Cargo.lock generated

View file

10

libclamav/scanners.c

View file

Rows
Columns

Compare commits

10 commits e98b0075e6 ... 82a321a589

992 Cargo.lock generated View file

10 libclamav/scanners.c Unescape Escape View file

10 commits

e98b0075e6 ... 82a321a589

992

Cargo.lock generated

View file

10

libclamav/scanners.c

View file