Feature Request: PUA tuning #5
Comments
|
Thank you for reporting this. Can you open a ticket in our BugZilla tracker at bugzilla.clamav.net? Thanks. |
|
Request has been posted as entry ID 11055 |
yht
pushed a commit
to kalamangga-net/clamav-devel
that referenced
this issue
Apr 24, 2022
Looking through the list of issues, I spotted some easy ones and submitted
some fixes:
- 225229 - In cli_rarload: Leak of memory or pointers to system resources.
If finding the necessary libunrar functions fails (should be rare),we now
dlclose libunrar.
225224 - In main (freshclam.c): A copied piece of code is inconsistent with
the original (CWE-398). A minor copy-paste error was present, and optOutList
could be cleaned up in one of the failure edge cases.
225228 - In decodecdb: Out-of-bounds access to a buffer (CWE-119). Off by one
error when tokenizing certain CDB sig fields for printing with sigtool. Ex:
$ cat test.cdb
a:CL_TYPE_7Z:1-2-3:/.*/:1-2-3:1-2-3:0:1-2-3::
$ cat test.cdb | ../installed/bin/sigtool --decode
VIRUS NAME: a
CONTAINER TYPE: CL_TYPE_7Z
CONTAINER SIZE: WITHIN RANGE 1 to 2
FILENAME REGEX: /.*/
COMPRESSED FILESIZE: WITHIN RANGE 1 to 2
UNCOMPRESSED FILESIZE: WITHIN RANGE 1 to 2
ENCRYPTION: NO
FILE POSITION: =================================================================
==17245==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffe3136d10 at pc 0x7f0f31c3f414 bp 0x7fffe3136c70 sp 0x7fffe3136c60
WRITE of size 8 at 0x7fffe3136d10 thread T0
#0 0x7f0f31c3f413 in cli_strtokenize ../../libclamav/str.c:524
Cisco-Talos#1 0x559e9797dc91 in decodecdb ../../sigtool/sigtool.c:2929
Cisco-Talos#2 0x559e9797ea66 in decodesig ../../sigtool/sigtool.c:3058
Cisco-Talos#3 0x559e9797f31e in decodesigs ../../sigtool/sigtool.c:3162
Cisco-Talos#4 0x559e97981fbc in main ../../sigtool/sigtool.c:3638
Cisco-Talos#5 0x7f0f3100fb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
Cisco-Talos#6 0x559e9795a1d9 in _start (/home/zelda/workspace/clamav-devel/installed/bin/sigtool+0x381d9)
Address 0x7fffe3136d10 is located in stack of thread T0 at offset 48 in frame
#0 0x559e9797d113 in decodecdb ../../sigtool/sigtool.c:2840
This frame has 1 object(s):
[32, 48) 'range' <== Memory access at offset 48 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../libclamav/str.c:524 in cli_strtokenize
- 225223 - In cli_egg_deflate_decompress: Reads an uninitialized pointer or
its target (CWE-457). Certain fail cases would call inflateEnd on an
uninitialized stream. Now it’s only called after initialization occurs.
- 225220 - In buildcld: Use of an uninitialized variable (CWE-457). Certain
fail cases would result in oldDir being used before initialization. It now
gets zeroed before the first fail case.
- 225219 - In cli_egg_open: Leak of memory or pointers to system resources
(CWE-404). If certain realloc’s failed, several structures would not be cleaned up
- 225218 - In cli_scanhwpml: Code block is unreachable because of the syntactic
structure of the code (CWE-561). With certain macros set, there could be two
consecutive return statements.
shutton
added a commit
to shutton/clamav
that referenced
this issue
Jan 9, 2024
…authors Update authors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
have the ability to fine tune the PUA detection I just recently built a custom live ISO image for my family including ClamAV after running a scan in Windows 7 using McAfee we then scanned the windows drive from the LiveOS using ClamAV
McAfee 229168 total scanned 0 threats
ClamAV 187125 total scanned (3503749 signatures loaded) 2204 threats detected
almost all of them were PUAs
now I know that McAfee is most likely not a good scanner to use (its not looked at with high regards in my circle of IT guys)
I will try and test against Avast and a few others to see a broader range of results to compare with.
also why is there such a big difference in the total number of scanned files? McAfee also scanned the registry and boot sector but I have no idea what would be the cause of the large difference in files. as far as I know Clam scanned everything on the drive but if it helps I will post the used options here
clamscan --recursive --verbose --detect-pua=yes /media/UUID_NUM
where UUID_NUM is the UUID of the mounted drive
The text was updated successfully, but these errors were encountered: