14

I recently found out pdf's can contain viruses, and from the impression I got its more than a buffer overflow error (I heard it may visit urls automatically but the person sounded unsure)

What are some formats that I should be wary of until everything is patched?

I remember at one point there was something in a vb6 project that would execute code on project loadup (without running). That was dangerous.

Improve this question
6
  • .ini files. Any sort of configuration file. .reg files
    – user606723
    Oct 24, 2011 at 15:02
  • 4
    I'd say ini-files aren't really dangerous, as they usually are opened as plain-text.
    – sshow
    Oct 24, 2011 at 15:27
  • But they could reference other things that are dangerous. ie. change the URL an application goes to for an update. Obviously, you'd have to install it first.. but still.
    – user606723
    Oct 24, 2011 at 15:31
  • 2
    @user606723 I think you're thinking of .INF files; .INI files are just configuration files, they aren't installable.
    – nandhp
    Oct 24, 2011 at 15:36
  • 1
    @user606723: .reg files cause a huge UAC warning in newer Windows versions that makes them unsuitable for anything malicious. If somebody sends you a .reg file and you open it without suspecting anything you will most definitely not give it privileges. You are again mixing up things that might theoretically be dangerous and ones that are really dangerous because commonly used for malicious purposes (due to the large attack surface).
    – Wladimir Palant
    Oct 24, 2011 at 16:35

3 Answers 3

Reset to default
24

Some formats can be called inherently insecure due to their complexity and their history of use as attack vectors. Adobe PDF and MS Office files come to mind. Any kind of binary executable is certainly problematic unless sandboxing is deployed.

But in general it depends on the application that is used to open the file, not the file itself. Even simple formats that cannot embed executable code can be parsed by an application in the wrong way, leading to bugs and potential vulnerabilities. Similarly, the sandboxing application may have bugs that allow executable code to escalate its privileges, so I would rate a sandboxed executable about as dangerous as complex file formats.

It may be possible to have relatively secure file formats by using a data format that can be checked automatically, using an automatically generated parser that does not need any information about the file type except the used grammar. I think the ASN.1 format is a candidate for this. But this kind of technology is used almost nowhere.

Improve this answer
4
  • +1. Completely depends on the programs used to open the file. Wasn't there a PNG or JPEG virus that went around for some time that affected only IE?
    – Earlz
    Oct 24, 2011 at 18:22
  • 1
    ASN.1 is rather similar to XML in this respect. You can test the file, the format constraints are trivial. But the problem is indeed not in data files, but in applications that improperly process them. E.g. Linux had an security-critical ASN.1 bug in 2.6.25, in the cifs and ip_nat_snmp_basic modules
    – MSalters
    Oct 25, 2011 at 8:11
  • 1
    I'm not an expert on this and can't find good sources that explain the issue, I only remember this discussion: lists.randombit.net/pipermail/cryptography/2011-July/… I think it boils down to the fact that in XML you can put arbitrary stuff into your environments, including binary. Although the xml schemes should bring this closer to ASN and make it more well-defined, no?
    – pepe
    Oct 25, 2011 at 10:13
  • Even plain ol' ASCII text files can be used as vector for shellcode attacks (and that's not juat a Unix/Linux thing - not only are there existing attacks against powershell, but Microsoft's new terminal emulator is vulnerable)
    – symcbean
    Sep 9, 2019 at 18:19
17

In theory, any format that requires complicated processing or allows embedding of other formats (especially Flash) can be dangerous. The most relevant issues right now are however:

  • Any Microsoft Office files (not so much because of Office vulnerabilities but because these files can embed Flash and exploit its vulnerabilities)
  • PDF files
  • Obviously, any files that can execute by themselves (executables and batch files of all kinds). "Batch" files on Windows are not only *.bat files but also JavaScript files *.js, Visual Basic Script files *.vbs, Windows Script files *.wsf and PowerShell with its various file extensions.
  • Archive files (mostly ZIP or RAR) because these are commonly used to compress file types mentioned above and to sneak past filters.
Improve this answer
8
  • 2
    Since when is flash insecure? You might as well add .html, etc. to your list as well? Office files are dangerous because they can contain VB macros.
    – user606723
    Oct 24, 2011 at 14:30
  • 9
    @user606723: See RSA hack for example. Flash is a commonly used attack vector, especially when not kept up to date (which happens often due to the crappy updater). There are lots more Flash vulnerabilities being discovered than those VB macro issues. And - yes, the only reason attackers prefer Office files over HTML is that they are less suspicious and that Internet Explorer won't automatically run Flash in local HTML files.
    – Wladimir Palant
    Oct 24, 2011 at 14:36
  • Add postscript to your list.
    – user606723
    Oct 24, 2011 at 14:40
  • 1
    @user606723: Postscript is covered by the first sentence. It is a theoretical danger but practically irrelevant because there is no widespread application to attack.
    – Wladimir Palant
    Oct 24, 2011 at 14:43
  • What now? postscripts can actually be malicious in nature. Take a read here: umech.mit.edu/aja/linux/postscript.php If someone forgets to run gs with -dSAFER, they could be running a script that can do literally anything their user can.
    – user606723
    Oct 24, 2011 at 14:50
7

The PDF problem is probably a reference to an old problem whereby pre-installed PDF plugins would automatically execute JavaScript specified in the URL fragment.

There is no comprehensive list of file formats that are dangerous. Not only is this blacklisting, it also ignores polyglots:

The term is sometimes applied to programs that are valid in more than one language, but do not strictly perform the same function in each.

For example, it is possible to construct a GIF that is also JavaScript and an HTML page that is also a JPEG. Any file format that is safe but for which it is possible to write a polyglot with another unsafe language, is potentially unsafe.

When a server sends a file, it also sends that file’s MIME type in a Content-Type header. All is well when the Content-Type the server asserts is consistent with the expected context in which that content gets used. What happens when the server does not send a Content-Type? What happens when a file with one Content-Type is sent when a different type is expected?

Sadness happens.

Some browsers consider the content-type the server asserts to be authoritative and if the content fails to parse as that type, the content is not rendered. Others ignore the server asserted type and try to guess (sniff the content) for its type. This sniffing can take the form of heuristics like the suffix of the file name in the URL that specifies it, the “magic” first couple of bytes of the content, or simply trying to parse the file with different parsers until one fits. The type of parser tried is sometimes constrained by the particular tag (fr’instance content expected by an img tag would only attempt to be parsed according to native image formats supported by the browser.). The problem is further exacerbated by plugins like Java and Flash and by different types of caches and “file save” feature in browsers which may or may not remember what content-type was asserted by the server.

Further, any binary file format can potentially escalate privileges by tickling buffer overflows in code that decodes it.

If you are trying to serve content from untrusted sources, you need to proxy and normalize it.

Improve this answer
2
  • The polyglot aspect is interesting, especially when considering the fact that Windows APIs would guess file types. Nontheless, the very definition of "dangerous" is problematic in regard to computer security - without having constructed an attack tree with possible threats for a particular system (or at least having a vague idea of how it might look like) there is no spoon.
    – syneticon-dj
    Oct 24, 2011 at 21:02
  • 1
    @syneticon-dj, while I agree that "dangerous" has to be defined in terms of desired security properties, if an attacker can escalate privileges to violate frequently desired security properties then it makes sense to call that content "dangerous" in the absence of a particular set of security properties. I think the examples above meet this because frequently applications are concerned about exfiltration of secrets, and arbitrary code exploits allow exfiltration of secrets.
    – Mike Samuel
    Oct 24, 2011 at 21:19

Your Answer

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