Prevent allocating more than 1GB regardless of what is requested.
RAR dictionary sizes may not be larger than 1GB, at least in the current
version.
This is a cherry-pick of commit 9b444e7e02
This is a cherry-pick of commit 24f225c21f
Modification to unrar codebase allowing skipping of files within
Solid archives when parsing in extraction mode, enabling us to skip
encrypted files while still scanning metadata and potentially
scanning unencrypted files later in the archive.
UnRAR logic replaces directory symlinks found within archive file entry
file paths with actual directories by deleting them after they're
extracted.
Unfortunately, this logic extends to deleting existing directories if you
set the `DestName` instead of the `DestPath` in this API:
rc = RARProcessFile(hArchive, RAR_EXTRACT, NULL, destFilePath);
In the future UnRAR may change to disable the `LinksToDirs()` feature
if using the `DestName` parameter. In the meantime, this commit
completely disables it for our use case.
json-c 0.17 defines the ssize_t type using a typedef on Windows.
We have been setting ssize_t for Windows to a different type using
a #define instead of a typedef.
We should have been using a typedef since it is a type.
However, we must also match the exact type they're setting it to or else
the compiler will baulk because the types are different.
Note: in C11, it's fine to use typedef the same type more than once, so
long as you're defining it the same every time.
Having the filename is useful for certain callbacks, and will likely be
more useful in the future if we can start comparing detected filetypes
with file extensions.
E.g. if filetype is just "binary" or "text" we may be able to do better
by trusting a ".js" extension to determine the type.
Or else if detected file type is "pe" but the extension is ".png" we may
want to say it's suspicious.
Also adjusted the example callback program to disable metadata option.
The CL_SCAN_GENERAL_COLLECT_METADATA is no longer required for the Zip
parser to record filenames for embedded files, and described in the
previous commit.
This program can be used to demonstrate that it is behaving as desired.
Previously clamd would report "Cannot allocate memory" when a file
exceeded max file size. This commit corrects it to report
"Heuristics.Limits.Exceeded.MaxFileSize."
Fixes: https://github.com/Cisco-Talos/clamav/issues/670.
Commit d1656ee increased the default scan limits. We updated them in the
clamd manpages but forgot to update them in the clamscan and
clamav-milter manpages.
Note that I'm also removing the "max: <4 GB" annotations because of the
change in commit 2962509 that removed the artificial 4 GB limit on
sizes that most notably increases the max-scansize to make it easy to
scan very large archives comprised of more than 4 GB worth of stuff.
There is no specific limit now on these size options.
When decompressing a zlib stream, it's possible to reach end of stream
before running out of available bytes. In the DMG parser, this may cause
an infinite loop.
This commit adds a check for the condition where stream has ended before
running out of input.
Fixes: https://github.com/Cisco-Talos/clamav/issues/925
Somehow forgot to save and commit final error handling check on the new
set_tls_client_certificate() function.
This change is needed to have Freshclam fail if you try to use the new
client certificate environment variables incorrectly.
In aspack decrypt function, there's a check to make sure that backbytes
doesn't exceed 57, because it is used as an index in init_array.
However, it is mathematically impossible.
So this commit removes the check.
`cli_getpagesize()` may return -1 in an error condition.
If it does, let's just treat it as 4096.
I believe the actual coverity complaint is a false positive, but it's
fair to account for the error case and this should shut it up.
The bytes_remaining variable may be set negative by mistake, when really
we just want to decrement it.
This issue may result in a 1-byte over read but does not cause any
crash.
We determined that this issue is not a vulnerability.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58475
Some change in Cargo/Rust version 1.70 or 1.71 appears to have broken
the build on Windows because we are incorrectly attempting to check the
native static libraries by compiling an empty file (/dev/null) which
does not exist on Windows.
A simple fix is to make an empty file of our own and use that instead.
Fixes: https://github.com/Cisco-Talos/clamav/issues/990
In `cli_scanudf()` it's possible to `goto done;` before memset'inng the
fileIdentifierList and fileEntryList. This would likely cause
uninitialized pointer reads.
Instead of memset, just initialize the structs with `= {0};`
Also:
- Rename to use FRESHCLAM_CLIENT_CERT, FRESHCLAM_CLIENT_KEY instead
prefixing with "CURL_". Unlike CURL_CA_BUNDLE, these variable names
are not used by the `curl` program and so do not piggyback on that
existing functionality.
- Add FRESHCLAM_CLIENT_KEY_PASSWD environment variable to support
password protected private key PEM files, as described in:
https://curl.se/libcurl/c/CURLOPT_SSLCERT.html
- Document the new environment variable options in the manpage and in
the `freshclam --help` message. Also add missing documentation in the
freshclam and clamsubmit help-messages for CURL_CA_BUNDLE.
- Update the NEWS.md file to credit jedrzej for the new feature.
These symbols are used by an internal python tool for generating
signatures:
- fuzzy_hash_calculate_image
- ffierror_fmt
`ffierror_fmt` is required to free the error structure passed back in
case of an error.
Since version 1.1.0 started using libclamav.map again, we need to
explicitly export these symbols.
This limit is internally "long long", so >=64-bit even on 32-bit platforms.
Also fixes a related issue where limits could have been set to negative
values on 64-bit platforms where setting a "long long" (64-bit signed) can
overflow if assigned from an "unsigned long" (64-bit unsigned).
Resolves: https://github.com/Cisco-Talos/clamav/issues/809
The checks for the encryption info cspName and encryption verifier don't
have the size of the overall file available for the check and may
overflow.
This commit passes in the size of the file to the
initialize_encryption_key() function and does all size checks within
that function instead of doing the overall size check before that
function.
Resolves: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60563
The prior fix for the wwunpack overread in commit
89cd0df3d7 was a little too late, but
also removed an earlier, smaller guard for a write.
This commit just moves the larger guard a little earlier to protect
against both.
Resolves: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60655
When switching to openssl 3.x, linking with clamsubmit fails with
undefined openssl symbols. The error message from Xcode is crazy obtuse:
ld: initializer '_OPENSSL_cpuid_setup' is >4GB from start of image in 'anon' from /Users/clamav_jenkins_svc/clamav-mussels-cookbook/test/install-x86_64/lib/libcrypto.a(libcrypto-lib-x86_64cpuid.o)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Anyhow... It seems that we must explicitly link clamsubmit with openssl
now in order for this to work.
In addition to this change, I also found that the CMake FindRust.cmake
module breaks the ability to build specifically for just x86_64 or arm64
(i.e. possibly cross-compiling.
This commit includes a change to accommodate that scenario.
If a signature has a pattern that is too short will fail to load the
signature but does not cause the entire load process to abort.
This is bad for two reasons:
1) It is not immediately apparent that the signature is bad, and so it
could be published accidentally.
2) The signature is partially loaded by the time the bad pattern is
observed and that may cause a crash later.
Because of (1), it is not worth it to try to unload the first part of the
signature. Instead, we should just abort the signature load.
Fixes: https://github.com/Cisco-Talos/clamav/issues/923
We should also abort loading if the filter pattern for the boyer-moore
matcher is shorter than 2 bytes.
Also, do not print the final "Loading" progress bar if an error occurred.
A buffer over-read may occur when unpacking wwpack'd PE files if the
file is very small.
This commit adds a CLI_CONTAINS buffer wrap check to ensure we aren't
reading beyond the exe buffer.
We determined that this issue is not a vulnerability.
Resolves: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=57374
Micah Snyder