Is it ever safe to open a suspicious HTML file (e.g. email attachment)? The Next CEO of Stack OverflowHow do I safely inspect a suspicious email attachment?Have i been phished?What vulnerability is this malicious document attempting to exploitWhy do email programs block xml files?One of my open files turned into a list of URLs and codes after clicking a link on a phishing email?Fake PayPal email with (presumably) malicious JS codeUsing Noscript while opening linksMy company sent a phishing email - can they see if I saved the attachment?Accidently opened a phishing email, is my computer infected by malware?How can I securely edit an Office file that I downloaded from the Internet?
Won the lottery - how do I keep the money?
Cannot shrink btrfs filesystem although there is still data and metadata space left : ERROR: unable to resize '/home': No space left on device
Does Germany produce more waste than the US?
Why is information "lost" when it got into a black hole?
Why did early computer designers eschew integers?
Inductor and Capacitor in Parallel
Is a distribution that is normal, but highly skewed, considered Gaussian?
IC has pull-down resistors on SMBus lines?
The Ultimate Number Sequence Puzzle
(How) Could a medieval fantasy world survive a magic-induced "nuclear winter"?
Which Pokemon have a special animation when running with them out of their pokeball?
What difference does it make using sed with/without whitespaces?
What's the commands of Cisco query bgp neighbor table, bgp table and router table?
Lucky Feat: How can "more than one creature spend a luck point to influence the outcome of a roll"?
What does "shotgun unity" refer to here in this sentence?
Can you teleport closer to a creature you are Frightened of?
Is it convenient to ask the journal's editor for two additional days to complete a review?
Is there a way to save my career from absolute disaster?
Asymptote: 3d graph over a disc
Yu-Gi-Oh cards in Python 3
Is there a difference between "Fahrstuhl" and "Aufzug"?
Why am I getting "Static method cannot be referenced from a non static context: String String.valueOf(Object)"?
Traveling with my 5 year old daughter (as the father) without the mother from Germany to Mexico
Would a grinding machine be a simple and workable propulsion system for an interplanetary spacecraft?
Is it ever safe to open a suspicious HTML file (e.g. email attachment)?
The Next CEO of Stack OverflowHow do I safely inspect a suspicious email attachment?Have i been phished?What vulnerability is this malicious document attempting to exploitWhy do email programs block xml files?One of my open files turned into a list of URLs and codes after clicking a link on a phishing email?Fake PayPal email with (presumably) malicious JS codeUsing Noscript while opening linksMy company sent a phishing email - can they see if I saved the attachment?Accidently opened a phishing email, is my computer infected by malware?How can I securely edit an Office file that I downloaded from the Internet?
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 opened the file with Notepad and saw the first few lines "If this wasn't just a test, your computer would be compromised!". After informing colleagues that it was another test, they were extremely concerned that I had interacted with the file at all.
I'm reasonably confident that any malicious script 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.
email malware phishing
migrated from serverfault.com 2 days ago
This question came from our site for system and network administrators.
|
show 5 more comments
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 opened the file with Notepad and saw the first few lines "If this wasn't just a test, your computer would be compromised!". After informing colleagues that it was another test, they were extremely concerned that I had interacted with the file at all.
I'm reasonably confident that any malicious script 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.
email malware phishing
migrated from serverfault.com 2 days ago
This question came from our site for system and network administrators.
20
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.
– Putvi
2 days ago
1
A famous example isAnnaKournikova.jpg.vbs
(Anna Kournikova (computer virus))
– Peter Mortensen
2 days ago
6
@PeterMortensen : A VBS file is not an HTML file…
– Jerry B
yesterday
3
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
yesterday
2
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
17 hours ago
|
show 5 more comments
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 opened the file with Notepad and saw the first few lines "If this wasn't just a test, your computer would be compromised!". After informing colleagues that it was another test, they were extremely concerned that I had interacted with the file at all.
I'm reasonably confident that any malicious script 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.
email malware phishing
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 opened the file with Notepad and saw the first few lines "If this wasn't just a test, your computer would be compromised!". After informing colleagues that it was another test, they were extremely concerned that I had interacted with the file at all.
I'm reasonably confident that any malicious script 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.
email malware phishing
email malware phishing
edited yesterday
Peter Mortensen
70649
70649
asked 2 days ago
UPChooUPChoo
18123
18123
migrated from serverfault.com 2 days ago
This question came from our site for system and network administrators.
migrated from serverfault.com 2 days ago
This question came from our site for system and network administrators.
20
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.
– Putvi
2 days ago
1
A famous example isAnnaKournikova.jpg.vbs
(Anna Kournikova (computer virus))
– Peter Mortensen
2 days ago
6
@PeterMortensen : A VBS file is not an HTML file…
– Jerry B
yesterday
3
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
yesterday
2
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
17 hours ago
|
show 5 more comments
20
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.
– Putvi
2 days ago
1
A famous example isAnnaKournikova.jpg.vbs
(Anna Kournikova (computer virus))
– Peter Mortensen
2 days ago
6
@PeterMortensen : A VBS file is not an HTML file…
– Jerry B
yesterday
3
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
yesterday
2
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
17 hours ago
20
20
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.
– Putvi
2 days ago
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.
– Putvi
2 days ago
1
1
A famous example is
AnnaKournikova.jpg.vbs
(Anna Kournikova (computer virus))– Peter Mortensen
2 days ago
A famous example is
AnnaKournikova.jpg.vbs
(Anna Kournikova (computer virus))– Peter Mortensen
2 days ago
6
6
@PeterMortensen : A VBS file is not an HTML file…
– Jerry B
yesterday
@PeterMortensen : A VBS file is not an HTML file…
– Jerry B
yesterday
3
3
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
yesterday
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
yesterday
2
2
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
17 hours ago
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
17 hours ago
|
show 5 more comments
7 Answers
7
active
oldest
votes
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).
New contributor
7
Buffer overflow in a text editor?
– Putvi
2 days ago
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
2 days ago
17
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
2 days ago
10
@Putvi: Here's the list of vulnerabilities for vim : cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/… . It lists quite a few...
– sleske
2 days ago
17
@Numeri: This one for example: 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
2 days ago
|
show 7 more comments
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!
1
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
yesterday
@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
yesterday
6
@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
yesterday
add a comment |
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. ;)
add a comment |
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: whycat
beforeless
? Because I noticed thatless
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.
3
You want to unsetLESSOPEN
andLESSCLOSE
at the very least if you useless
. Also, it might be better to usecat -v
to avoid exploiting unicode or control code handling vulnerabilities in your terminal emulator.
– forest
2 days ago
add a comment |
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 will do.
– Marc.2377
4 hours ago
add a comment |
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.
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
2 days ago
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
2 days ago
9
Are you really advocating for security through obscurity? -1
– forest
2 days ago
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
yesterday
2
@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities.
– user23013
yesterday
|
show 2 more comments
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.
New contributor
add a comment |
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "162"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206364%2fis-it-ever-safe-to-open-a-suspicious-html-file-e-g-email-attachment%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
New contributor
7
Buffer overflow in a text editor?
– Putvi
2 days ago
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
2 days ago
17
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
2 days ago
10
@Putvi: Here's the list of vulnerabilities for vim : cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/… . It lists quite a few...
– sleske
2 days ago
17
@Numeri: This one for example: 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
2 days ago
|
show 7 more comments
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).
New contributor
7
Buffer overflow in a text editor?
– Putvi
2 days ago
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
2 days ago
17
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
2 days ago
10
@Putvi: Here's the list of vulnerabilities for vim : cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/… . It lists quite a few...
– sleske
2 days ago
17
@Numeri: This one for example: 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
2 days ago
|
show 7 more comments
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).
New contributor
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).
New contributor
edited 2 days ago
New contributor
answered 2 days ago
ThomasThomas
40113
40113
New contributor
New contributor
7
Buffer overflow in a text editor?
– Putvi
2 days ago
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
2 days ago
17
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
2 days ago
10
@Putvi: Here's the list of vulnerabilities for vim : cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/… . It lists quite a few...
– sleske
2 days ago
17
@Numeri: This one for example: 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
2 days ago
|
show 7 more comments
7
Buffer overflow in a text editor?
– Putvi
2 days ago
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
2 days ago
17
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
2 days ago
10
@Putvi: Here's the list of vulnerabilities for vim : cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/… . It lists quite a few...
– sleske
2 days ago
17
@Numeri: This one for example: 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
2 days ago
7
7
Buffer overflow in a text editor?
– Putvi
2 days ago
Buffer overflow in a text editor?
– Putvi
2 days ago
8
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
2 days ago
@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
2 days ago
17
17
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
2 days ago
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
2 days ago
10
10
@Putvi: Here's the list of vulnerabilities for vim : cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/… . It lists quite a few...
– sleske
2 days ago
@Putvi: Here's the list of vulnerabilities for vim : cvedetails.com/vulnerability-list/vendor_id-8218/opec-1/… . It lists quite a few...
– sleske
2 days ago
17
17
@Numeri: This one for example: 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
2 days ago
@Numeri: This one for example: 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
2 days ago
|
show 7 more comments
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!
1
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
yesterday
@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
yesterday
6
@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
yesterday
add a comment |
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!
1
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
yesterday
@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
yesterday
6
@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
yesterday
add a comment |
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!
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!
edited 12 hours ago
Andrew Morton
1436
1436
answered 2 days ago
George MGeorge M
32915
32915
1
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
yesterday
@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
yesterday
6
@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
yesterday
add a comment |
1
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
yesterday
@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
yesterday
6
@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
yesterday
1
1
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
yesterday
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
yesterday
@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
yesterday
@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
yesterday
6
6
@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
yesterday
@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
yesterday
add a comment |
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. ;)
add a comment |
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. ;)
add a comment |
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. ;)
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. ;)
answered yesterday
Lightness Races in OrbitLightness Races in Orbit
1,82411115
1,82411115
add a comment |
add a comment |
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: whycat
beforeless
? Because I noticed thatless
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.
3
You want to unsetLESSOPEN
andLESSCLOSE
at the very least if you useless
. Also, it might be better to usecat -v
to avoid exploiting unicode or control code handling vulnerabilities in your terminal emulator.
– forest
2 days ago
add a comment |
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: whycat
beforeless
? Because I noticed thatless
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.
3
You want to unsetLESSOPEN
andLESSCLOSE
at the very least if you useless
. Also, it might be better to usecat -v
to avoid exploiting unicode or control code handling vulnerabilities in your terminal emulator.
– forest
2 days ago
add a comment |
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: whycat
beforeless
? Because I noticed thatless
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.
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: whycat
beforeless
? Because I noticed thatless
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.
answered 2 days ago
reedreed
2,9593825
2,9593825
3
You want to unsetLESSOPEN
andLESSCLOSE
at the very least if you useless
. Also, it might be better to usecat -v
to avoid exploiting unicode or control code handling vulnerabilities in your terminal emulator.
– forest
2 days ago
add a comment |
3
You want to unsetLESSOPEN
andLESSCLOSE
at the very least if you useless
. Also, it might be better to usecat -v
to avoid exploiting unicode or control code handling vulnerabilities in your terminal emulator.
– forest
2 days ago
3
3
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
2 days ago
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
2 days ago
add a comment |
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 will do.
– Marc.2377
4 hours ago
add a comment |
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 will do.
– Marc.2377
4 hours ago
add a comment |
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.
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.
answered yesterday
taskettasket
913
913
If OP is using Windows, Sandboxie will do.
– Marc.2377
4 hours ago
add a comment |
If OP is using Windows, Sandboxie will do.
– Marc.2377
4 hours ago
If OP is using Windows, Sandboxie will do.
– Marc.2377
4 hours ago
If OP is using Windows, Sandboxie will do.
– Marc.2377
4 hours ago
add a comment |
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.
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
2 days ago
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
2 days ago
9
Are you really advocating for security through obscurity? -1
– forest
2 days ago
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
yesterday
2
@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities.
– user23013
yesterday
|
show 2 more comments
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.
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
2 days ago
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
2 days ago
9
Are you really advocating for security through obscurity? -1
– forest
2 days ago
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
yesterday
2
@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities.
– user23013
yesterday
|
show 2 more comments
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.
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 2 days ago
Peter Mortensen
70649
70649
answered 2 days ago
OvermindOvermind
4,559718
4,559718
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
2 days ago
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
2 days ago
9
Are you really advocating for security through obscurity? -1
– forest
2 days ago
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
yesterday
2
@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities.
– user23013
yesterday
|
show 2 more comments
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
2 days ago
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
2 days ago
9
Are you really advocating for security through obscurity? -1
– forest
2 days ago
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
yesterday
2
@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities.
– user23013
yesterday
18
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
2 days ago
"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
2 days ago
16
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
2 days ago
"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
2 days ago
9
9
Are you really advocating for security through obscurity? -1
– forest
2 days ago
Are you really advocating for security through obscurity? -1
– forest
2 days ago
1
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
yesterday
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
yesterday
2
2
@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities.
– user23013
yesterday
@Twometer I'm comparing it with edit.exe, arguably more likely to have vulnerabilities.
– user23013
yesterday
|
show 2 more comments
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.
New contributor
add a comment |
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.
New contributor
add a comment |
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.
New contributor
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.
New contributor
New contributor
answered yesterday
AnonSecurityUser95AnonSecurityUser95
111
111
New contributor
New contributor
add a comment |
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f206364%2fis-it-ever-safe-to-open-a-suspicious-html-file-e-g-email-attachment%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
20
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.
– Putvi
2 days ago
1
A famous example is
AnnaKournikova.jpg.vbs
(Anna Kournikova (computer virus))– Peter Mortensen
2 days ago
6
@PeterMortensen : A VBS file is not an HTML file…
– Jerry B
yesterday
3
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
yesterday
2
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
17 hours ago