5

My Exchange Admin is setting up 2013, and it is set to block txt file attachments specifically (as well as others).

I have tried searching for risks associated with txt attachments but could not find any. Are there any risks I need to be aware of surrounding txt attachments?

EDIT

The Admin did not set up the rules for blocking, but found that this was the default rule for Exchange 2013 during a migration from 2010. It was causing problems in our environment, so he asked me to approve the whitelisting of .txt files.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 1
    Have they actually chosen to block `.txt` OR have they blocked *everything* and only whitelisted certain file/mime types? The latter would be my guess. – James Snell Jul 27 '14 at 21:47

4 Answers4

8

I've been supporting and administering email for 18 years, and never had a valid reason to block text attachments. Here are some issues that I can think of, that aren't exclusive to TXT attachments alone, but rather regard attachments in general

Unicode parsing

The only two issues I've come across is this unicode bug but it's theoretically possible that other applications that have issues parsing and/or displaying unicode.

MIME-type vs file extension

Attachments in SMTP include not only a file extension .txt but also a MIME-Type and a corresponding encoding (as mentioned above). Should any of these "metadata" not match up (vbscript with a mime of Text, or vice versa) it's possible to get unexpected results from a client.

Issues may include

  • File attachment icons appearing like a TXT file in the client, but are really an EXE
  • Clients (or services) improperly handling the attachment, potentially executing it
  • A variation of the above that causes the client (outlook / thunderbird, etc) to download an image, or verify a DKIM signature, losing the anonymity of the client.

Outlook

Since the most common client in an Exchange 2013 environment is Outlook, I'll focus on that, even though most of the issues here have been thoroughly looked at and is no longer an issue (as long as you're on a current and patched build).

Outlook Preview Pane Risk

The Outlook preview pane uses a special, locked down version of IE. Given that IE could execute "text" data as if it were HTML/XSS or any other active content, this could pose as a security risk. (Outlook vulnerabilities as the preview pane has happened in the past)

WebReady Exchange Server Risk

A similar attachment to HTML parser is installed on the Exchange server itself called WebReady, and it converts attachments into HTML for Outlook Web Access clients. This has already been an issue in the past, causing vulnerabilities and executable code to run in the context of the Exchange Server itself. Read more about this security feature here.

Summary

In my opinion, before your admin blocks TXT attachments they should consider disabling Webready and address the lower hanging fruit first:

  • Improved authentication for end users (smartcard etc)
  • AV/AS on the server, and gateway
  • SMTP security including DMARC, DKIM, SPF, and Opportunistic / Secure TLS where possible
  • Content scanning
  • On demand portal encryption, SMIME or PGP encryption

If they are disabling attachments as a form of information management, to prevent the disclosure (or liability of receiving ) data, then they should consider alternate controls.

If they are disabling TXT attachments for security / encryption reasons and want all data encrypted, know that some encryption software sends the encrypted payload or public to the clients using TXT data. Conversely, banning this activity is easy since there is a string in the file that can be scanned for.

Just for clarification, by "blocking" do you mean classifying it as a Level 1 or Level 2 attachment in Outlook?

Glorfindel
  • 2,235
  • 6
  • 18
  • 30
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 2
    I'm with you - I've been supporting email for 13 years and I've never heard of a risk (except for parsing vulns). – schroeder Jul 10 '14 at 15:22
  • What about the simple hiding of file extensions? malicious.txt.exe ? Does exchange account for this? – avgvstvs Jul 27 '14 at 21:31
  • 1
    Exchange does account for that and `exe` is blocked out of the box. – James Snell Jul 27 '14 at 21:45
  • Excellent analysis. From my point of vue, risk n°1 within a context of `Outlook` clients is: **Outlook Preview Pane Risk**, where a `.txt` is in fact containing `HTML` attack code. If this `previewer` is hard to block, another approach consists in blocking every format which may lead to an `HTML` interpretation with the risks involved. – dan Jul 28 '14 at 08:51
2

In addition to makerofthings7's very thorough answer, another reason could be to prevent phishing attacks which tunnel dangerous content in the TXT attachment.

For example, if you send a file called ILOVEYOU.EXE.TXT, sign it as "grandma", and instruct the user to save and rename the file - some percentage of users will happily follow those instructions to see what "grandma" sent them.

Jeff-Inventor ChromeOS
  • 1,313
  • 9
  • 10
  • The phrase "dangerous content in the TXT attachment" is misleading and overreaching. Based on this argument, no data may be transmitted between computer systems because the associated byte-array may contain 'dangerous content'. Any file can be given any name and meta-data having nothing to do with the content. It is the association of executable rendering programs to file-extensions that is key. Had the above example remained "ILOVEYOU.EXE", having blocked file-extensions TXT would not have made the exchange any more secure. – Darrell Teague Jun 24 '16 at 15:37
1

There are no specific risks associated with plain text attachments as defined by the RFC.

Ref: https://www.rfc-editor.org/rfc/rfc2046

Operating systems like Windows associate the "txt" extension of the file-name to the text/plain MIME type and have executable association on-click/open with some defined program (like notepad/wordpad, etc).

By default on most operating system clients (Windows and many others) this association program does not have published security vulnerabilities resulting in opening a plain-text file. Indeed, if they did, no email message could ever be opened/previewed for fear that simply rendering the text would execute malicious software.

Assessment: Administrator has made an error blocking files with a TXT extension.

Further analysis: File extensions are inherently meaningless.

An operating system executable virus for example can be given ANY file-name/extension. When clicked/opened, that file content will be processed by some reader program associated with the extension.

Indeed, it is common practice in corporate environments to bypass Exchange file-extension blocking rules by simply renaming files with a different extension or just zipping the content (giving the file a ".zip" extension) so that the reader may receive it.

For example, it is not uncommon for developers to exchange language source files/snippets over email. Such files are of the MIME type "plain/text" yet many Exchange administrators will block ".c" or ".cpp" named files, believing incorrectly that language source files are somehow inherently executable.

Community
  • 1
Darrell Teague
  • 454
  • 3
  • 6
  • I made an edit to the question to clarify that the blocking is done by default on Exchange 2013. Yes, I know that file extensions are meaningless, but the question is about the risks of text files themselves. – schroeder Jul 28 '14 at 15:18
  • 2
    The answer is "there are no specific risks associated with plain text attachments". This is not to say there are no risks to reading/rendering ANY content... but there are definitely no known specific risks with TXT files (versus EXE files by comparison - that launch a different executable to process that content by default). – Darrell Teague Jul 28 '14 at 15:19
0

It's also possible that all attachment's are being blocked - regardless of extension. Or, there may be an organizational policy that permits only certain file types - maybe only .pdf has been approved, and so .txt is explicitly blocked.

While not necessarily a security issue, there is the possibility that someone could send a lot of very large .txt files that consume a lot of storage space. Similarly, opening a large .txt file can cause system resource issues. For example, opening a .txt file that has 250MB of data all on a single line causes issues in Notepad.exe...

But these may be obscure examples/justifications.

Nick
  • 437
  • 2
  • 9