Patch provides more insight into error conditions which may arise
when adding a directory to the watch hierarchy. If a specific file
caused the issue, the filename is provided to help users with any
troubleshooting needed.
I found that the `url(data:` type does not matter to a browser.
In addition, whitespace may be placed in a few locations and the browser
will ignore it.
This commit accounts for this, and updates the test accordingly.
This commit adds a feature to find, decode, and scan each image found
within HTML <style> tags where the image data is embedded in `url()`
function parameters a base64 blob
In C in the html normalization process we extract style tag contents
to new buffer for processing. We call into a new feature in Rust code to
find and decode each image (if there are multiple).
Once extracted, the images are scanned as contained files of unknown
type, and file type identifcation will determine the actual type.
The verdict is being recorded before the preclass bytecode hook meaning
that the final verdict may come back as "clean" in allmatch mode,
even if the preclass bytecode hook matches something.
This commit moves the verdict check to occur AFTER the preclass bytecode
hook executes.
While searching for the end of the character class ']', there was no
bounds checking to prevent reading past the end of the regular
expression.
This commit fixes the issue by adding length checking to regex_parsing.
Resolves: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47780
On distros with multiple python impls it can be useful to select
a specific version rather than whatever CMake thinks is appopriate.
This patch enables users to instruct CMake to look for a specific
version of python by passing `-DPYTHON_FIND_VER`.
Building with these will fail for Clang because _GNU_SOURCE is not
defined.
-Werror=implicit-function-declaration
-Werror=implicit-int
-Werror=strict-prototypes
Also added fix to use "MATCHES" instead of "EQUALS" in FindLLVM where
the same sort of logic is used.
The change to define _GNU_SOURCE means that the compiler knows that
syscall returns a long, not an int -- so then it warns about the wrong
format characters for printing that value.
Prototypes (or the declarations themselves, if there is no
corresponding prototype) for functions that take no arguments are
required by the C standard to specify (void) as their argument list;
for example,
regex_pcre.h:79:1: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
79 | cl_error_t cli_pcre_init_internal();
Future versions of clang may become strict about this, and there's no
harm in conforming to the standard right now, so we fix all such
instances in this commit.
On Linux, thpool.c uses syscall() from unistd.h, but that function is
not defined without _GNU_SOURCE:
c-thread-pool/thpool.c: In function 'jobqueue_pull':
c-thread-pool/thpool.c:474:105: error: implicit declaration of function
'syscall' [-Werror=implicit-function-declaration]
In general that's not great, because it hinders some compiler diagnostics,
but it will also cause problems down the road if (for example) clang-16
decides to enable -Werror=implicit-function-declaration by default.
This commit changes the _POSIX_C_SOURCE definition at the top of
thpool.c to _GNU_SOURCE, as in the syscall(2) man page.
The libclamav SO ABI has changed since 0.103 due to:
- Removal of the CLAMAV_PUBLIC namespace by no longer using libclamav.map
- Change of: extern const char *cl_strerror(int clerror);
To: extern const char *cl_strerror(cl_error_t clerror);
See: e66c00f41c/libclamav/clamav.h (L1203)
- Introduction of Rust symbols to namespace.
Ref: https://github.com/Cisco-Talos/clamav/issues/775
As such, it seems fair to increase the SO version.
This is an amendment to this prior change for the ClamAV 1.0.0
version bump:
0dd6ab3f16
Instead of incrementing SO Current version to 11, and Age to 2,
we'll increment SO Current version to 11, and reset Age to 0.
So the SO version will effectively go from:
9.1.0
to:
11.0.0
The supported Docker files used to build the official clamav images are
now located here: https://github.com/Cisco-Talos/clamav-docker
Also fix some minor errors in the INSTALL.md file.
clamscan_test.py was accidentally re-introduced with commit
35ccb49f38
All of the tests in this file are covered in other _test.py files
in the unit_tests/clamscan directory.
The bytecode compiler has a bug that was observed to cause a crash
with a specific signature when testing on FreeBSD.
This PR adds an index size check when looking up a constant to
prevent this crash in case a bugged signature gets through QA.
An additional NULL check is added just to be safe.
The CVD/CLD unpack calls performed by sigtool didn't used to verify the
CVD. If working with a CLD, verifying will fail, such as when using
`sigtool --find-sig` when daily is a CLD.
This commit reverts that behavior for sigtool unpack operations.
A race condition existed where clamonacc would call logg and attempt to
write to a logfile either before the logg interface had been initialized
or after it had been cleaned up.
This happens due to logg calls at cleanup during asynchronous thread
shutdowns, and during startup when watching directories with ongoing
event triggers.
This resulted in new files with garbage-filled names being created and
written to under the initial process' runtime path.
Changes:
Move logg setup to start of clamonacc.c main()
Change all raceable calls to logg to mprintf instead
If the image decoders (i.e. jpeg, tiff, png, etc.) fail to load an image
due to a panic, the application will crash.
This commit attempts to catch those panics and handle the error.
While reviewing scan time performance, the time limit checks have a
notable effect on scan time. I tested reducing the number of time checks
to every n'th signature evaluation. For the given sample which has a
large number of very tiny embedded scans, I found that overall scan time
was best when checked every 10th signature. Reducing the number of
checks any further had no noticable effect.
Bear in mind that these numbers include daily/main/bytecode CVD load
time:
| current | mod 2 | mod 10 |
| ----------------- | ----------------- | ----------------- |
| 63.848 s ±1.188 s | 61.773 s ±0.652 s | 59.831 s ±0.975 s |
| mod 50 | mod 100 | mod 1000 |
| ----------------- | ----------------- | ----------------- |
| 59.279 s ±1.652 s | 59.198 s ±1.147 s | 59.440 s ±1.304 s |
ClamAV requires non-default build options for TomsFastMath to support
bigger floating point numbers. Without this change, database and
Windows EXE/DLL authenticode certificate validation may fail.
The option to build with an external TomsFastMath library should be
removed. The `ENABLE_EXTERNAL_TOMSFASTMATH` build should be ignored,
with some sort of warning.
This commit removes the option. If used, the build will not fail, but
CMake will print a warning that the unused option was ignored.
This bug was introduced during 1.0 development and does not affect any
stable release.
An OLE2 document that claims to have a sector size (big block size) over
28 will cause a signed integer overflow for our local off_t variable,
when multiplied by 4. This will then result in an invalid read and
segfault.
The fix is two-fold:
1. Make sure the sector size (big block size) is not greater
than 28, so we don't accidentaly overflow an int32_t.
2. Perform the size check _before_ using the variable.
This commit also fixes some variable types from `unsigned int` or
`off_t` over to the more appropriate `size_t`, and from `int` or
`uint32_t`, over to `bool`.
Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=52639
When adding the `cl_cvdunpack()` API that (optionally) verifies the
database signature, we used it in libfreshclam in a place where it may
also unpack CLD database archives. CLD's may not be verified, because
the signature information is no longer valid after incremental update.
This commit fixes the issue by only verifying the unpack if the file is
a CVD and not a CLD.
If you run clamdscan with the --allmatch option, it will cause all
subsequent clamdscan scans to have all-match mode enabled.
This bug is specific to clamd / clamdscan and does not affect clamscan.
The problem was introduced when we converted the scan options from a
single integer bitfield to a struct. The scan options set by the
clamdscan parameters should be saved in a local copy of the scan
options, but instead it is saving a copy of the pointer to the scan
options struct, and so any changes to the scan options affect future
scans.
Micah Snyder