3 ms·

Some of these attacks, such as the exe.doc one, are the fault of the use of in-band signaling by Windows to indicate that a file is executable. You can't do tha

by api 13y ago

Some of these attacks, such as the exe.doc one, are the fault of the use of in-band signaling by Windows to indicate that a file is executable. You can't do that on OSX or Linux, where attributes determine execute capability. The equivalent domain name issues are a lot tougher, and are going to require a character lookalike table or some other system of rules to warn the user.

notJim 13y ago
I was pretty skeptical of that particular example anyway. If a user is opening random files from untrusted sources, security has already gone out the window.
- jakub_g 13y ago
  Well on a mass scale you're right, but if you're targeting a particular person X, you may create a throwaway gmail account impersonating X's friend Y, and send an innocuously looking pdf/doc/xls/lolcat gif as an attachment. IMO lots of people may fall prey to this kind of attack if the email looks legit.
- logicallee 13y ago
  are you kidding? there's a huge difference between parsing a document with a program you've already trusted and installed, and running an executable. your web browser literally downloads and parses documents all day long. pdf and .doc files might be marginally less secure, but they're by no means supposed to be executable. if windows refuses to display the correct extension, I suppose you have to manually open them from whatever you want to view them with (File|Open) after downloading them to a certain folder. I'd have zero qualms about doing this with a .txt file on windows for example - wouldn't you?
MichaelGG 13y ago
That's not quite accurate. NTFS has fine-grained permissions, including execute (which is independent of read/open). If a program decides to download or save an attachment and leave execute permissions set, then yes, you can execute it. It'd not be any different on Linux if your email client saved attachments and marked them +x. Now as a matter of defaults, sure Windows is different.
- jve 13y ago
  Oh, thanks for pointing out - actually I thought it would be a pretty good thing to deny executing by default in folders used by Email clients, Instant messengers, browsers and removable drives. Still someone could save file in different location and execute it. Is there a way to identify which program generated specific file? Or perhaps we could solve this by allowing these programs (like Skype.exe) save files only in specific folders. Is that possible?
  - MichaelGG 13y ago
    It's hard to retroactively implement this model on Win32 desktop apps. Some programs (Skype, for instance) actually create and run executables on-the-fly (for their stupid obfuscation stuff). Files should inherit the folder ACL, so a deny execute on a folder would work nicely, but end up breaking things for users. Microsoft addresses these issues with the "WinRT" platform and sandboxed/appstore model.

by api 13y ago

notJim 13y ago

I was pretty skeptical of that particular example anyway. If a user is opening random files from untrusted sources, security has already gone out the window.

jakub_g 13y ago
Well on a mass scale you're right, but if you're targeting a particular person X, you may create a throwaway gmail account impersonating X's friend Y, and send an innocuously looking pdf/doc/xls/lolcat gif as an attachment. IMO lots of people may fall prey to this kind of attack if the email looks legit.
logicallee 13y ago
are you kidding? there's a huge difference between parsing a document with a program you've already trusted and installed, and running an executable. your web browser literally downloads and parses documents all day long. pdf and .doc files might be marginally less secure, but they're by no means supposed to be executable. if windows refuses to display the correct extension, I suppose you have to manually open them from whatever you want to view them with (File|Open) after downloading them to a certain folder. I'd have zero qualms about doing this with a .txt file on windows for example - wouldn't you?

MichaelGG 13y ago

That's not quite accurate. NTFS has fine-grained permissions, including execute (which is independent of read/open). If a program decides to download or save an attachment and leave execute permissions set, then yes, you can execute it. It'd not be any different on Linux if your email client saved attachments and marked them +x. Now as a matter of defaults, sure Windows is different.

jve 13y ago
Oh, thanks for pointing out - actually I thought it would be a pretty good thing to deny executing by default in folders used by Email clients, Instant messengers, browsers and removable drives. Still someone could save file in different location and execute it. Is there a way to identify which program generated specific file? Or perhaps we could solve this by allowing these programs (like Skype.exe) save files only in specific folders. Is that possible?
- MichaelGG 13y ago
  It's hard to retroactively implement this model on Win32 desktop apps. Some programs (Skype, for instance) actually create and run executables on-the-fly (for their stupid obfuscation stuff). Files should inherit the folder ACL, so a deny execute on a folder would work nicely, but end up breaking things for users. Microsoft addresses these issues with the "WinRT" platform and sandboxed/appstore model.