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)?
Asked
Active
Viewed 6,334 times
3 Answers
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.
forest
- 64,616
- 20
- 206
- 257
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
) 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. – 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 01 '18 at 02: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. – Feb 01 '18 at 03: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 01 '18 at 03:25
-
If you need actual proof that (correctly designed) exploits do not cause crashes, check out some of the links from https://security.stackexchange.com/a/175389/165253, which present not only exploits that do not crash, but in one case even bypass ASLR without any scripting. – forest Feb 01 '18 at 04:50
-
Forest, you keep persisting in your out-of-topic discussion. The question asked if djvu in its format can contain harmful instructions. This means, macro capability, ability to open a browser and pass an URL, ability to execute a script command. What you say is true, but unrelated to the djvu as being of higher abstraction. – Feb 02 '18 at 20:12
-
Regardless, your answer explains both macro capability (in the first sentence) and exploitation (in the rest), which just now according to you is "off-topic". Your fundamental understanding of exploitation is incorrect, and it reflected in your answer. That is all I am saying. You are right that DjVu files cannot contain malicious macros and I am not arguing against that. – forest Feb 03 '18 at 03:00
-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.
Aria
- 2,706
- 11
- 19
-
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
-
-
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