Is it ever safe to open a suspicious HTML file (e.g. email attachment)?

Question

If I receive an email that has an attachment called something like safe-link.html would it ever be safe to open this file?

Clearly, HTML files may have malicious scripts embedded that could run when opened with a browser. However, I'm wondering if any breaches could occur upon downloading the file and then opening it in Notepad / other basic text editor rather than a web browser?

Background

I'm only asking because the company I work for like to send out 'test' phishing emails from time to time, and the latest had an HTML attachment. I suspected the email immediately (so didn't click to open the attachment in a browser), but I was intrigued to see if it actually was another test!

So I suggested to colleagues that the file be opened with Notepad. We’re all savvy enough to read HTML, so would immediately spot the usual "If this wasn't just a test, your computer would be compromised!”, but they were extremely concerned that I had thought to interact with the file at all.

I'm reasonably confident that any malicious script in an html file would have to be opened in a web browser for it to have any effect.

Are my colleagues being too cautious, or was I being overzealous?

I'm an advocate of "better safe than sorry", so I don't think they were wrong not to open it; I just also don't believe it was completely unsafe to open with something like Notepad. I am very intrigued to find out!

"Gotchas" I'm aware of:

I believe editing it in a more complex website development tool (that actually renders the page in a preview) could be dangerous.

Also, I'm aware that simply double clicking the file (even if the default "open with" is set to be a text editor) could be dangerous. This is because something like readme.txt could actually be readme.txt.exe with file extensions hidden in something like Windows File Explorer.

All these answers are way to extreme. If you want to open a html file in a text editor go ahead, as long as there is nothing executable with it. — Vit, Mar 29 '19 at 17:48
A famous example is `AnnaKournikova.jpg.vbs` (*[Anna Kournikova (computer virus)](https://en.wikipedia.org/wiki/Anna_Kournikova_(computer_virus))*) — Peter Mortensen, Mar 30 '19 at 00:43
Yes. It the file is a test, and you open it, and see that it is a test, then you may be tempted to tell others. Thus destroying the efficacy of the test. Also if people are being punished for making mistakes, then your company can not learn; mistakes will be covered up. — ctrl-alt-delor, Mar 30 '19 at 15:09
@mckenzm: did you look at the existing answers before commenting? The question is not *that* trivial to answer "no" to. A bug in handling invalid UTF-8 sequences could exist, for example. — Peter Cordes, Mar 31 '19 at 00:47
@ Peter Cordes The question seeks a binary yes/no answer. Looking at TNEP text or filtered (sed) cat of the content is safe, as is printing it to paper. It has to be transport neutral (Base64, say), and there is always hexdump. So yes, there are safe ways. It does not have to be nano/pico/vi/emacs/gedit. — mckenzm, Mar 31 '19 at 02:28
If you’re in the kind of environment where opening a html file in a text editor is considered risky, you’re in an environment that shouldn’t have access to the internet in the first place. — Sebastiaan van den Broek, Mar 31 '19 at 13:05
@mckenzm Peter's point, and he's correct, is that _if_ we reduce this to a binary yes/no answer, the answer is _NO_ (as in, _no_ it's not safe). But, in reality few things are binary yes/no, and the true answer here, per my post, is that this is well below the threshold for tolerance in my view. — Lightness Races in Orbit, Mar 31 '19 at 13:59
I also have a sneaking suspicion that the colleagues' reactions were not due to a risk analysis of opening HTML source in a text editor (or sedding to screen), but due to a lack of understanding. Though that's hard to prove of course. — Lightness Races in Orbit, Mar 31 '19 at 14:02
_with file extensions hidden in something like Windows File Explorer._ Even if you set it to show full file extensions, it could still be an executable with unicode reversal characters in the filename. I wrote an example of that in [an unrelated answer](https://security.stackexchange.com/a/187859/165253). — forest, Apr 02 '19 at 00:49

Thomas · Answer 1 · 2019-03-29T13:10:06.890

40

Editors, and common libraries used by editors, may have vulnerabilities like buffer overflows. Your attacker would need to know (or guess) what editor you use and craft an exploit specifically for that editor (different editors are unlikely to have the same vulnerabilities unless the vulnerability resides in a library they have in common). An attack may be aimed at a popular editor and send out to as many people as possible, essentially turning it into a "spray-n-pray" attack.

Attack Surface

A very simple editor like Microsoft's Notepad has a smaller attack surface than a more advanced editor (like Visual Studio Code). More code generally means more potential vulnerabilities.

Mitigations

Certain mitigation techniques like Address Space Layout Randomization (ASLR), Data Execution Prevention and having an anti-virus with an "exploit blocker" (these are generally capable of recognizing basic overflow attacks, among others) may help to render certain attacks useless.

Software Updates

All of these techniques are of course no substitute to keeping your software (ALL your software I might add) up-to-date. Keeping your software updated is the best security strategy one can have. This is sometimes overlooked or trivialized due to its lack of feedback. An anti-virus yelling at you that "You are protected!" sends out a much stronger signal than a software update that silently patches vulnerabilities in the background. I tend to compare an anti-virus program with a person sticking their fingers in the holes of a dike to prevent the water coming through. It does its best to keep the flood out but chances are it's not going to have enough fingers to fill all the holes (or miss a few altogether). Software patches fixes those holes.

Bottom Line

You can never be sure you aren't going to have a bad day by opening any type of file in any type of program. However, some programs (like editors) are much harder to attack due to their small footprint or secure design and therefore are less likely to be targeted for mass attacks (especially because an attacker is likely to assume their evil .html file is going to be opened in a browser, not in an editor).

edited Mar 29 '19 at 13:10

answered Mar 29 '19 at 12:54

Thomas

509
3
3

7

Buffer overflow in a text editor? – Vit Mar 29 '19 at 17:38
8

@Putvi Why the surprise? The primary function of a text editor is to manipulate buffers, it's very easy to sneak in buffer overflows if you're not careful. – Cubic Mar 29 '19 at 17:56
1

Do you have any examples? – Vit Mar 29 '19 at 17:57
23

I have **never** heard of an attack against a text editor. It is certainly in the realm of possibility, but I would be very surprised to see a practical example of it. – Max Mar 29 '19 at 19:42
10

@Putvi: Here's the list of vulnerabilities for vim : https://www.cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/VIM.html . It lists quite a few... – sleske Mar 29 '19 at 22:54
@sleske Most of those have to do with vimscripts. How many would actually allow a file to harm you just by being viewed/opened and navigated? – Numeri Mar 30 '19 at 00:02
17

@Numeri: This one for example: https://www.cvedetails.com/cve/CVE-2016-1248/ - "execution of arbitrary code if a file with a specially crafted modeline is opened". So just opening a file is enough. – sleske Mar 30 '19 at 00:26
1

@Numeri You can execute shell commands from VimScript. – Brian McCutchon Mar 30 '19 at 06:29
3

Since you can execute code as a normal function, vim is not *just* an editor. The part being attacked is the non-editor part. Are there any vulnerabilities for plain editors? – Jerry B Mar 30 '19 at 08:09
So if I use a really underground text editor (that is really really unpopular) I would be safe by opening it on this editor? – ihavenoidea Mar 30 '19 at 19:25
1

It is true that you can never be 100% safe. But, also not, you might get exploited even *without* opening any attachment, just by clicking at email (or, depending on how lousy your email client is, even just by receiving email without any additional action from your side) – Matija Nalis Mar 30 '19 at 22:31
5

@ihavenoidea **No!** That would be security through obscurity, which is a bad thing. An obscure text editor would likely have _more_ vulnerabilities, potentially even ones that work on multiple text editors, not just one. – forest Mar 31 '19 at 02:28
I think text editors are pretty safe, since, when sending an HTML file, one usually does expect it to be opened in a browser. [However, thats Security by Hope, which is definitely the worst approach there is] – Hobbamok Apr 01 '19 at 10:04

score 20 · Answer 2 · edited Mar 31 '19 at 17:49

Oh, these answers are way too sophisticated for your situation. It's highly unlikely that your IT department would be using some fancy workaround assuming they know what editor you're using, their point is not to actually mess up your systems. Notepad isn't going to be doing anything with any image or attachment, no matter what, and the text you saw certainly didn't do anything reprehensible to your system. Nor would it have been likely to, even if it had been a real attack, as editors are very personal tools and there are lots and lots of them that'd have to be covered for anything like this to have any sort of detectable effect.

Tell your coworkers to get off your back, and to be more careful themselves. Let me just point out that you dug yourself into this hole though, and achieved the opposite of what was intended…. If you hadn't announced that you looked and what you saw, people who clearly don't know a thing about IT security wouldn't be harassing you and feeling superior about it. Instead, some of them would have opened the attachment and seen the message, and gotten a bit chastened themselves. So you've messed up IT's test all the way down the line, emphasizing the Dunning-Kruger effect which is no doubt the cause of sending out these tests. Stop it!

I do not think this answer is useful. The question is about the security implications of opening such a file in a text editor. And if what you're working on is important enough, it is well possible that you get such targeted attacks. And if you're just a generic person, it is still possible the receive a file that targets notepad++ (at least in theory. I don't know any vulns) — lucidbrot, Mar 30 '19 at 09:37
@lucidbrot: notepad++ does syntax highlighting and stuff. This answer is about Microsoft Notepad that comes with Windows. The attack surface is probably limited to very long lines, very large files, or maybe UTF-8 stuff. Maybe an evil filename. But since it ships with Windows, it's *hopefully* been well audited? — Peter Cordes, Mar 31 '19 at 00:43
@PeterCordes I'm confident that the Notepad program is less vulnerable than the indexer, thumbnail generator, antivirus parser, and everything else that sees the file before Notepad. — forest, Mar 31 '19 at 02:27

score 20 · Answer 3 · answered Mar 30 '19 at 20:05

Okay, so, technically, you're never 100% safe. Yes, there could be attempted attacks on your text editor/ASCII viewer. Yes, someone could have somehow magically snuck a DLL into your temporary directory in order to mess with MS Notepad delay loading.

But in practice, when you receive an HTML file in a phishing email, it's going to contain some malicious JavaScript or more likely redirect you to a website online that tries to persuade you to hand over your credit card details / logins.

So, in practice, examining such a file in Notepad++ is a perfectly reasonable way to see what's been sent to you. The reaction of your colleagues seems unfair, unless you are working in a nuclear silo … and if your job is really that mission/safety critical, why are there emails at all? Why would there be internet access? And, if there isn't, why would you need phishing audits/tests/honeypots? Someone somewhere is being overly paranoid.

We can try to reduce our risk to zero but the only way to achieve that is to not use a computer.

All that being said, though, you will always have to deal with silly people so perhaps keep this activity to yourself next time. ;)

score 7 · Answer 4 · answered Mar 29 '19 at 17:32

In general it's not safe because if you get a suspicious or unexpected email, whatever the attachment is, it shouldn't be opened. That's the safest thing to do. Especially if you are on Windows, which is notorious for executing stuff when it should not, and which is the most targeted OS by attackers, running the most targeted applications.

But if you want to open it anyway, maybe because you are an INFOSEC enthusiast or you think you are (or want to be) smarter than the average user, here's some advice:

Consider reading the source code of the email, instead of opening it. You might be able to do so directly from the webmail interface, or by reading the text files on your server, etc.
Consider downloading the attachment from the source, by copying and pasting its base64 representation. This will just be simple ASCII text. You can then convert it back to binary with some tools.
Consider renaming the file, saving it as potentially-malicious.txt instead of .html or whatever name and extension it has.
Consider opening the txt file with very basic text editors, or even hex-editors, or even with very simple basic tools available on the command line that will only display ASCII characters. An example could be cat file.txt | less on Linux. (Note: why cat before less? Because I noticed that less parses and converts some stuff by default sometimes, like converting PDFs to TXTs. So just be careful, better check what the commands do by default on your system anyway).
Consider opening the file in virtual machine, which should be up-to-date and also disconnected from the network.
Consider doing most of this at home and never tell your boss or your colleagues about it. They might see it as dangerous behavior, a violation of the security policy, or something that might cause you trouble anyway.

You want to unset `LESSOPEN` and `LESSCLOSE` at the very least if you use `less`. Also, it might be better to use `cat -v` to avoid exploiting unicode or control code handling vulnerabilities in your terminal emulator. — forest, Mar 30 '19 at 03:33

score 6 · Answer 5 · answered Mar 30 '19 at 13:58

Its situations like this, where risk for particular objects is an unknown quantity, that a strongly compartmentalized OS like Qubes excels. Qubes uses a hardened bare-metal hypervisor to keep risky stuff isolated from sensitive areas (like personal files and the core OS). It even isolates risky devices. This isolation is expressed and controlled through the GUI in a fairly user-friendly fashion:

In the above example, right-clicking on an html file in KDE Dolphin lets you choose options like "Edit In DisposableVM" and "View In DisposableVM". Clicking on either one of these will automatically instantiate a disposable virtual machine (dispvm), then send the file to the dispvm and load it in the associated app. This takes only seconds. When you're done with the editing app, the edited version will be returned to the calling VM and the dispvm will be instantly destroyed. Note, however, this process by itself does not make an untrusted file into a trusted file.

For certain file types (currently images and pdfs) there is also a menu option for converting a file to a trusted state... i.e. a dispvm is used to process an untrusted pdf and construct a sanitized version that is loaded back and can be used without risk to your regular VMs where you normally work. This is possible because the originating sanitizing tool accepts only the most predictable representation of the requested data back from the dispvm, such as uncompressed bitmaps of exactly an expected number of pixels and bytes; once the raw sanitized version is received back, it is then re-compressed into the expected format.

Its worth noting that you could emulate the type of security described above using more familiar tools like VirtualBox and VMware, but the degree and quality of the isolation is unlikely to match the levels attained by a dedicated system like Qubes.

If OP is using Windows, [Sandboxie](https://www.sandboxie.com/) will do. — Marc.2377, Apr 01 '19 at 02:27

score 3 · Answer 6 · answered Mar 31 '19 at 02:21

While others are pointing out flaws, I would say you did the right thing.

While your other colleagues took the route of assuming its bad, you used your skill set to analyse the situation and verify its malicious intent.

You had an understanding that you should not allow the browser to open the file, but instead use something that it was not intended for it be opened with by the recipient. You analysed the code, and you were able to verify that it had malicious intent ( in this case, only a warning by your IT team ).

If you are skilfull enough to analyse the files and make the correct judgement call, I would find that more ensuring that you have a good understanding of protecting yourself against malicious users and using your skillset to ensure your safety.

How ever if you do not have the skill to verify the HTML and JavaScript code is not malicious, you should just not open it and assume it is malicious as you can not guarantee its safety even if you opened it in notepad.

Only attempt to analyse a situation in which you have the appropriate skill set to analyse, and only analyse the situation if you expecting the email or it is from a known source.

score 1 · Answer 7 · edited Mar 30 '19 at 03:26

1

Yes, breaches could occur upon downloading the file and then opening it in Notepad / other basic widely-used text editor, because payloads can be specifically crafted to interact upon such editors as Notepad.

Example: Notepad.exe, like many of the Windows programs, uses system libraries. One of those system libraries loads shdocvw.dll (Internet Explorer related component). shdocvw.dll has a delay-load dependency on a library called 'ieshims.dll'.

This .dll could be searched in the current directory and loaded from there. So if an attacker would deploy it along with the .txt file, it could use this setup as an exploit to load its .dll and then go from there.

The solution to this: use your own text editor/viewer that is not dependent on any Windows components / libraries. Mine is just called Edit.ExE, 100% independent of any external resources and 100% safe regarding processed content (reads everything directly as ASCII / text with no content detection). You don't have one; use a very obscure one no one would bother to exploit.

edited Mar 30 '19 at 03:26

Peter Mortensen

877
5
10

answered Mar 29 '19 at 12:42

Overmind

8,779
3
19
28

18

"This .dll could be searched in the current directory and loaded from there." So if the only thing that's in the directory of the html file is that html file, then you're not exposed to this attack? Seems like an easier fix than writing your own text viewer. – UKMonkey Mar 29 '19 at 14:54
16

"100% independent of any external resources " - so you read the file by direct access to the disk sectors, in case your OS is compromised? And you don't even use the OS to load Edit.ExE, in case it was compromised to recognize that file name as being an obvious name for a file editor? Security is one thing, but paranoia is something else. – alephzero Mar 29 '19 at 18:26
9

Are you really advocating for **security through obscurity**? -1 – forest Mar 30 '19 at 03:27
@alephzero : I think the point is that *this* email attachment couldn't have compromised his editor before he has opened it, and his editor doesn't rely on other code that is *inherently* compromised. – Jerry B Mar 30 '19 at 08:20
1

It's theoretically possible. But it's also possible that you get hacked without doing anything, including downloading the file. If you want to prevent this possibility, it is more practical to write a program to insert an underscore after each character, which would destroy most malicious code, and open it with a familiar editor. – user23013 Mar 30 '19 at 13:20
@user23013 The underscore program would have to load the file, what if someone exploits this program? – Twometer Mar 30 '19 at 14:10
2

@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities. – user23013 Mar 30 '19 at 14:18
An ASCII-reading custom designed .exe cannot have any vulnerability since it does not interpret anything in the content and does not load any OS-linked files (like .dlls). – Overmind Apr 08 '19 at 08:14

score 0 · Answer 8 · answered Apr 01 '19 at 13:15

If you're a paranoid nuclear scientist working in a secret base in Antarctica, maybe. Otherwise, nobody is going to spend the time to implement buffer overflows, etc.

The first thing that comes to most people's minds when they see an HTML file is probably to open it with a browser. If they wanted to "trick" you into editing it with Notepad++ or similar, it would likely be a text file, JSON file, etc.

So no, you probably aren't at risk, but yes, you could be.