4

PDF files can contains malicious JavaScript , open actions & etc. But what about djvu files ? If djvu can be malicious, then how to detect that manually (without opening malicious file of course)?

4

Yes, a DjVu file can be dangerous. While, as others have mentioned, it is designed not to have any executable code, a vulnerability in a DjVu parser can be used to exploit the viewer. Many viewers use the same library, making a vulnerability in a single library relevant to large number of viewers. A historical example is CVE-2012-6535, which affected the popular DjVuLibre library, used by many document viewers. The vulnerability, as reported by Microsoft, was a memory corruption bug that allowed for code execution. The CVE details page gives some general information about its impact:

DjVuLibre before 3.5.25.3, as used in Evince, Sumatra PDF Reader, VuDroid, and other products, allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via a crafted DjVu (aka .djv) file.

Unfortunately, it is not possible to manually detect a malicious file of this sort. They do not necessarily contain any tell-tale signs such as visible embedded scripts or suspicious strings, and antivirus will rarely be able to detect them. In fact, they usually skip files that are not executable.

This is not at all specific to DjVu. Any file format can be exploited, even ones you don't expect. The best way to reduce the risk of exploitation is to ensure all your software is up to date, so any discovered vulnerabilities are promptly fixed before they can be widely exploited.

0

By design a djvu file can not contain executable code or scripts. Still, it is possible that an attacker would provide a specially manipulated file which will normally make your viewer to crash. Instead of crashing, if your data execution bit protection is set to off, it is possible to execute code in user space of your user. This is a difficult attack, given the variety of djvu viewers, the attack being usually specific to one version of one viewer.

  • 1
    -1 This answer is, as it stands, incomplete and incorrect. First, an exploit caused by a maliciously designed file will not necessarily crash the target application. Second, even if DEP (NX) is enabled, it may be possible to execute code, for example using ROP. Third, even though there may be a variety of djvu viewers, they all likely use a very finite set of parsing libraries. A vulnerability in one parsing library would affect every single viewer. – forest Jan 28 '18 at 22:23
  • I disagree with the first point. The question was if the format allows the malicious commands (for example something think like exec <command>) which will run on the viewer side, and the answer was clearly no. I agree with the second, ROP is possible if DEP is enabled, but the attach is much more difficult. Third, except of the canonical library, there are other libraries, for example written in Javascript or Java, not relying on the original one. I don't have data on percentage of viewers and so, but I guess they are not relaying upon the same parser. – user166832 Jan 30 '18 at 21:52
  • The OP didn't read at all to me about officially supporting malicious commands, just if they can be malicious. As for ROP, it's not much more difficult given how common ROP compilers are. It's simple enough that people don't need to know how ROP works to get around DEP/NX now days. My main issue with the answer though was the claim that it would cause a crash (I can't think of many cases where a successful exploit causes a crash), and that DEP needs to be off to execute code in userspace. – forest Feb 1 '18 at 2:47
  • Whaterver wording you choose, the exploit we discuss about relies upon an error in programming the viewer, which would cause a segmentation fault. This is a generic problem, which happens independently of viewer, format or file. You can get it with a text file and your favorite text editor, if the programming error exists. The reference to djvu and the parallel between the ability of PDF to embed Javascript / actions is pretty clear that the question is explicit for djvu and not generic. – user166832 Feb 1 '18 at 3:21
  • An exploit would not cause a segmentation fault unless it is a very, very poorly written exploit. A segfault is a general protection fault, and #GP(0) is raised when, for example, an invalid memory access occurs (e.g. due to exploit code that incorrectly points to a bad address). Exploits do not necessarily cause a crash and in most cases cannot be detected when they succeed. This applies to any type of exploit, whether a buffer overflow, ROP, integer overflow, refcount overflow, use-after-free, or whatever. – forest Feb 1 '18 at 3:25
-1

Any file can be malicious. It's hard to detect it manually as the only thing it may contain is the shellcode. You can run unix strings command on it to see if it contains any malicious URLs or other suspicious strings like paths to windows files.

To lower your chances of exploitation, do not open this file in web browsers nor in the microsoft office suite.

  • Actually opening the file in web browsers is likely safer, as some browsers have very safe sandboxes built in. – forest Jan 28 '18 at 22:23
  • There's known bug in IE activex djvu component. – Aria Jan 29 '18 at 11:45
  • ActiveX isn't sandboxed, is it? I was talking more about things like Chrome, not the least secure plugin in one of the least secure browsers. – forest Jan 29 '18 at 23:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.