Sometimes PDF claims the zlib data is longer/shorter than it really is.
We always prefer the longest one, which can lead zlib to return an error
when we run off the end.
So dump the remaining extracted data from zlib's buffer to disk, it usually
contains all we need already (and if not we're going to dump the raw inflate
stream anyway).
This fixes 3 missed samples of Exploit.PDF-60 in the regression test.
Now you can call it both from a normal lsig triggered BC, and from a PE hook BC.
The normal lsig triggered BC has exe_info (but not PE info) which allows it to
invoke the icon matcher API.
Also putting ICONGROUP1 into the ldb trigger of the bytecode works.
It is a compiler bug, shortcircuiting the bigendian path to
return 0xdead11.
Since this test is meant to test libclamav, disable this test for now.
When the compiler is fixed (bb #2157) the test can be readded.
Seems to extract most pdf/openaction/and streams (flate, ascii85, asciihex).
Doesn't normalize extracted JS, that will be done once bytecode hooks are added.
pointers in the interpreter are of the form:
| pointer id | pointer offset |, where pointer id is an offset into an array
that contains information about the pointer like its bounds.
The last commits broke it: we store bytecode constants little-endian-like,
so an 8-bit constant is at offset 0, a 16-bit one at offsets 0,1; a 32-bit one
at 0,1,2,3; and a 64-bit one 0,1,2,3,4,5,6,7,8.
Of course the constant itself is in host-endianness.
For these commits:
e67790c658 Add clamd handling.
d049a2f72b Make bytecode tests use testmode if they want.
9f3afdb874 Add clamscan flag --bytecode-mode.
b1018ea52e Fix another interpreter bug accessing structs.
669623d5a6 Fix computation of type sizes in interpreter.
9f1715ccea Add new bytecode APIs to access the environment.
0d4c99465e Add the builtin bytecode.
d5ffa2acff Introduce BC_STARTUP bytecode (bb #2101, #2078).
927d054838 Add engine param to bytecode, and remove dconf from _init.
ed6cd43ef0 Make clamconf use cli_detect_environment.
78f73f0f77 Add new files to build system.
c85060ff79 Move environment detection code to bytecode_detect.c.
It was not computing the size of structs.
Bug: all bytecodes that had structs on the stack failed with internal
out-of-bounds errors.
Workaround: compiler will need to avoid putting structs on stack, or do so only
for FLEVEL == 0.96.2
check_platform(...) is an API that can be used to:
- blacklist JIT/bytecode on just a very specific platform (not recommended)
- mask (with 0xf/0xff) some fields, and keep just the flags that uniquely
identify the system where a bug occurs (for example linux + ppc32).
- it returns a bool so you can do further checks if needed.
The bytecode also has access to all the information collected from the
environment, so it can make more detailed decisions (based on CPU, presence of
SELinux/PaX, etc.).
You can't introduce new detections via bytecode, but you can write new
conditions using existing ones.
The previously added builtin bytecode moved all the JIT disable logic to
bytecode for easy updating.
This bytecode will be run in interpreter mode on startup:
it can disable the JIT, or disable all further bytecodes.
There will be a builtin copy of it that is loaded if
no BC_STARTUP bytecodes were loaded (like filetypes_int.h and daily.ftm).
Only one BC_STARTUP bytecode is accepted, so as soon as bytecode.cvd will
contain one, it won't be overridable!
This bytecode will replace all the JIT checks (CPU, selinux, pax) etc.,
and allows to disable the JIT on just specific OS/arch/compiler/etc.
combinations. There are too many combinations to have a dconf flag for each.
Also fix the bytecode dconf so that the individual JIT_* flags actually work
(previously we could disable the entire JIT, or none at all).
Also introduce preliminary support for bytecode test mode (we already have
auto, jit and interpreter mode, introducing another mode here is easiest).
The test mode doesn't actually compare the outputs yet, but it does fail if
the JIT is disabled / falls back to interpreter.