Release notes

MetaDefender Core is now manageable on My OPSWAT / Central Management v8 for following product functionalities:

• Workflow rules configurations.
• Product license activation.
• Engine module update.
• Processing history browsing.
• Processing details of each scan.
• Dashboard overview with processing statistics.

• "Sandbox" engine is now displayed as "Adaptive Sandbox".
• New filtration setting to allow triggering Adaptive Sandbox engine to run when hitting "Blocked Verdict by Deep CDR" result determined by Deep CDR.

• Upgraded to Cyrus SASL 2.1.27 for vulnerabilities.
• Upgraded to libpng 1.6.43 for vulnerabilities.
• Upgraded to zlib 1.3.1 for vulnerabilities.

• Allow setting Multiscanning AV related timeout settings less than 1 minute (in seconds), applicable to both "Per AV" and "Global timeout" settings. Note: upgrade process will convert 0 (min) value to 1 min.
• Make "others_time" more granular and precise in case of processing archives.
• Retry mechanism with License Manager to handle any potential unstable network issue better.
• Distinguish Multiscanning AV's "wait_time" and "scan_time" in case of scan timeout.
• Separate Multiscanning AV's wait_time from "others_time".
• No longer flag Reputation engine's database outdated.
• Default non-admin roles now can be deleted completely.

• Optimized algorithm to boost parallel performance when functionning with 20+ Multiscanning engines.
• Resolved slow responsing and reducing memory usage for file submission.
• Optimized communication channel between MetaDefender Core service and its engineprocesses for product resilience under load.
• Improved a mechanism to ensure engine initialization can be executed even when Windows ever runs out of resources.
• Applied thread-pool mechanism in task management to reduce resource consumption and improve file processing performance.
• Optimized workflow logic to maximize the utilization of system resources.

• Supported non-root use case.
• Supported to start shared-DB instances in a parallel way when using an internal (bundled) PostgreSQL user.
• Supported YARA rule settings import.

• Logs now can be rorated by day and size, at 1GB.
• Data retention: keeping the last 30 days of log files.
• Standardized key format in log file: "data_id".
• Distinguished "Unexpected server response" from "Invalid deployment ID" error.
• Ensure log message from Multiscanning engines should not mess up product log format.
• Track timestamps of first chunk received and last chunk received in millisecond.
• Track which AV engine takes most scan time (max_scan_time) and wait time (max_wait_time).

• Change the term "Waiting child files" to "Nested files".
• Some minor UI changes.

1. When users cancel a request or terminate a connection in the middle, temp files of the cancelled/terminated requests could be left over.
2. When users cancel an archive file processing which is being extracted, it causes temp child files might be remaining while root file can be removed in advance.
3. When there are numerous archive timeouts, then required further commands cannot be sent to Archive Extraction engine for temporary file cleanup.

• Fixed issues caused by archive engine timeout and threshold exceeding that negatively impacted performance, and potentially caused memory leak issue.
• Fix issue that Multiscanning engines sometimes cannot active back after a timeout or failure termination.
• Status code and response body does not reflect Synchronous Scan timeout result.
• Fix issue that support package script overwrited new-location logs with the default-location logs.
• MetaDefender Core container cannot start when UID and GID are different.
• Fix issue that MetaDefender Core container could not auto deactivate.
• Multiscanning exclusion setting did not work properly when configured engine(s) are "Inactive".

Since introduced in v5.8.0, this feature helps improve overall performance and reduce considerable load when processing similar files.

However, we have realized this feature might run slowly in high load against large DB size.

Working on improving the feature. Stay tuned for next update.

Only happen to containerized environments.

If config zip file include non-empty required_enginessetting, MetaDefender Core will reject importing the file.

Workaround:

1. Extract config zip file.
2. Open "export_settings.json" and set "required_engines" an empty array.
3. Recompress files into a new zip.
4. When executing docker run command, set the following environment variables: MDCORE_HEALTH_CHECK, MDCORE_REQUIRED_ENGINES. More details at Health check settings.

When modifying settings in Workflow Rule, sometimes button "Revert to Default" disappears and cannot work properly. This behavior might be encountered in version 5.5.0.

This issue is addressed and resolved in version 5.6.0.

We have observed that the Engine Update feature may not work properly in an environment that is protected by a [Palo Alto firewall](Palo Alto firewall). In log file, you might find this message "SslHandshakeFailedError".

In case that upgrading to the latest version of MetaDefender Core does not help, please consider setting up MetaDefender Update Downloader product. This product is responsible for downloading engines, and MetaDefender Core will pick and update its engines from there.

MetaDefender Core 5.5.0 introduces a lot of changes for supporting UI accessibility. Unfortunately, this leads to an inconvenience issue when displaying Workflow Rule on small/zoomed-in resolution screen. Some tabs at the bottom of the list will not be displayed properly. Workaround: zooming out a little bit on the browser.

This issue is addressed and resolved in version 5.5.1.

This issue is addressed and resolved in MD Core v5.5.0 and Archive v6.2.1.

• If using MetaDefender Core 5.4.1, then you can update Archive Extraction engine version to 6.2.1 or newer without waiting for MetaDefender Core 5.5.0 release.
• If using MetaDefender Core 5.4.0 or older, then you can upgrade it to version 5.4.1 or newer, and update Archive Extraction engine to 6.2.1 or newer. If you are not able to upgrade MetaDefender Core, then you should stick around on Archive engine 6.0.2, until you are able to upgrade Core.

FileType version 6.0.2 sometimes created malformed data. After being written into PostgreSQL database, those malformed data cause negative impacts to MetaDefender Core v5.4.0 or older:

• Executive Report in Dashboard gets frozen and changed back to zero.
• CPU usage will go too high.
• A dramatical decrease in file processing performance.

If you encounter similar symptoms, please find the following troubleshooting to resolve the issue: Rectify malformed FileType data in PostgreSQL database

This issue is addressed and resolved in version 5.4.1.

MetaDefender Core 5.2.1 or above might not be able to work properly with Red Hat /Cent OS with its kernel 372.13.

The vendor Red Hat seems to be fixing the issues with the kernel. Please try upgrading to kernel version 372.26.

In containerized environment, MetaDefender Core 5.2.0 or newer cannot work properly when:

• Linux kernel version of host machine is newer than 4.18.0. This also includes 5.x.y and 6.x.y.
• And Docker base image is CentOS 7.
• And using bundled PostgreSQL (DB_TYPE=local).

Workarounds:

1. Switch to use Docker base image RHEL 8 or Debian.
2. Switch to use a remote PostgreSQL.

On MetaDefender Core 5.2.0 or newer, OpenSSL 1.x is replaced by OpenSSL 3.x within the product and other dependencies (PostgreSQL, NGINX) as a security improvement, and prevent known vulnerabilities found on OpenSSL 1.x

NGINX's OpenSSL 3.x on MetaDefender Core has the enforcement in place to reject all weak cipher suites. It only accepts "HIGH" encryption cipher suites https://www.openssl.org/docs/man1.1.1/man1/ciphers.html (MD5 and SHA1 hashing based will not be accepted as well).

As a result, if you already configured MetaDefender Core for HTTPS connection, but using a weak SSL cipher with your certificate, then MetaDefender Core will not be able to start due to NGINX's OpenSSL 3.x enforcement.

For prevention and remediation before upgrading MetaDefender Core, learn more at HTTPS Failure on MetaDefender Core 5.2.0 (or newer)