We will review for 0.99.4.

0.99.4 is out. Any update on this.

An encrypted/password-protected PDF is *NOT* an encrypted *archive*, thus "ArchiveBlockEncrypted" settings should not block that.

Hi Gandalf,

If you look at our recent changes to naming convention changes here: http://blog.clamav.net/2018/01/clamav-version-number-adjustment.html

You'll see that the most recent 0.99.4 is simply a security release with no new features added.

We still plan to look into this issue during what would have been 0.99.4 or what now groks to 0.101.0 which comes after the imminent 0.100.0 release.

I hope that clears things up. =)

-Mickey

I see. But this is very critical to me (and many others, mostly italian users), there are tons of legit password protected PDF (like every salary receipt sent in Italy) that are password protected and currently blocked by a bad option.

I've looked at sources and it should be a trivial fix in "pdf.c" by changing references to DETECT_ENCRYPTED constant to something different like DETECT_NOTDECRYPTABLE_PDF and then setting that constant in the rest of code.

I understand your concern, but 0.100 is in code freeze and in final stages of release.

That said, I will bring up your concerns when we go over planning for 0.101 and will discuss if this change is suitable for a bugfix release under 0.100.x so that hopefully you will see it much sooner rather than later.

I do apologize that this bug fell through the cracks. We're trying to be better about that now and into the future.

So I've gone ahead and investigated this problem a bit, and it looks the reason this hasn't been done is that we only have one free bit left in the engine scan options field.

That's almost certainly why this heuristic feature was applied to both archives and pdfs. Once we're out, we can no longer add engine functionality without extending the field to 64-bits which will impact engine performance on 32-bit machines, since processor instructions for each options field access will be doubled on those systems.

This fix seems like it would play more into a potential rework/restructuring of how engine options are handled/organized in Clam. As of right now, it is difficult to justify using our final slot for the sake of increased granularity.

In the short term, we could fix semantics and change "ArchiveBlockEncrypted" to simply "BlockEncrypted" and make a note that it also blocks encrypted PDFs.

Additionally, work was done in 0.100 to improve/fix decryption of encrypted pdfs (if they can be decrypted). There was also some general work that had begun wherein users could provide passwords to attempt to decrypt password protected files. Would a fix along those lines be more in line with your use cases?

Or is having increased option granularity a bigger need?

Your input is important as we start nailing down plans for 0.101 and beyond.

(In reply to Mickey Sola from comment #7)
> In the short term, we could fix semantics and change "ArchiveBlockEncrypted"
> to simply "BlockEncrypted" and make a note that it also blocks encrypted
> PDFs.
> 
> Additionally, work was done in 0.100 to improve/fix decryption of encrypted
> pdfs (if they can be decrypted). There was also some general work that had
> begun wherein users could provide passwords to attempt to decrypt password
> protected files. Would a fix along those lines be more in line with your use
> cases?

Honestly, I don't agree with this proposal.
Assured that "ArchiveBlockEncrypted" also blocking PDFs is absolutely bad, if adding a new flag is not possible, I think we should stay on the safe side avoiding any false-positives.

I don't have any real data to compare but I think that malware send via an encrypted archive vs malware sent via password-protected PDF (if any) is something around 100:1

The current implementation block almost everything (and *all* password protected PDFs, like commercial invoices, monthly statements and so on) for what? protecting users from being infected by a very very very very rare virus ?

I've never ever seen any malware sent via an encrypted PDFs in all of my IT-life (about 15 year) but I can see about 20-30 hits per day for encrypted archives like zip/rar and so on.

So, if adding a new flag is not possible, please remove PDFs from this check, because you are making tons of false positives.

> Or is having increased option granularity a bigger need?

I think yes, but as wrote above, if not possible, please drop PDF from this flag (and then keeping the "ArchiveBlockEncrypted" option name exactly for what it means: block encrypted ARCHIVES, not documents)

Currenty, with Clam, the only way to send a password protected PDF is to disable the "ArchiveBlockEncrypted" check, allowing malware inside encrypted archives.

I think it's obvious that this is non-sense.

Unfortunately, using Adobe provided RC4 and AES password-less encryption is a fairly common, low level evasion technique malware authors use to obfuscate their embedded js exploits.

Potentially being unable to scan files which use this technique (in cases where our decryption efforts fail) will need to be considered carefully. Any potential changes will need to undergo more stringent and targeted regression testing than usual.

To fix this issue, and given your feedback, I do think increasing granularity of engine options is the correct path forward. This will take some time given how much refactoring and design work is required. We have other feature requests in the 0.101 pipeline that may require additional engine options as well, which means this fix is likely to get done alongside that work.

Good morning!

We've just added in a change coming in ClamAV 0.101 that will have a new separate scan options:

`--alert-encrypted`         (clamd.conf option: AlertEncryptedDoc)
`--alert-encrypted-archive` (clamd.conf option: AlertEncryptedArchive)
`--alert-encrypted-doc`     (clamd.conf option: AlertEncryptedDoc)

I hope this resolves the issue you were facing with password-protected PDF's getting blocked. 

In this commit, we are also changing the names of the "block" and "heuristic" options in an effort to make the verbiage more consistent.

For details, here is the github commit with the changes:

https://github.com/Cisco-Talos/clamav-devel/commit/c6cea234deaf9f1a7d2333d3ffef78089a63a5ae