Microsoft: piracy is getting virusy

[Bast]

FromTheRafters wrote:
> Bast submitted this idea :
>>
>> Virus Guy wrote:
>>> "David H. Lipman" wrote:
>>>
>>>>>> It it even possible that when launched from a media-player (such
>>>>>> as VLC) that there exists a class of avi, mp3, flac (etc) malware
>>>>>> that can leverage a player vulnerability and cause it to run
>>>>>> arbitrary code?
>>>>>
>>>>> Yes.
>>>>>
>>>>> Some specific players could be tricked into visiting a maliciously
>>>>> formed website embedded in the id3tags.
>>>
>>>>> The Wimad trojan
>>>
>>> So basically these boil down to browser exploits. A URL launched from
>>> Windoze Media Player is still a browser exploit.
>>>
>>> And they're not even exploits - they depend on user action in the
>>> browser to allow what-ever operation they're trying to accomplish (ie
>>> - social engineering).
>>>
>>> What I'm asking about is a media file that upon playing can cause any
>>> media player to run arbitrary code WITHOUT NEEDING THE USER'S HELP,
>>> and thereby cause the user's system to download secondary payloads,
>>> change registry settings, etc. All without enlisting the system's
>>> web-browser. Has there ever been a media file (mp3, avi, flac, etc) that
>>> could
>>> accomplish that?
>>
>>
>>
>>
>> Nope, not if a user has file types set.
>>
>> An exploit in widows can allow renaming a file extension from say .exe
>> to .mov
>> Or naming it with no extension at all.
>> And windows was stupid enough to recognize it as an .exe despite the
>> extension, and run it as such.
>
> Er, what is stupid is relying on the extension to mean anything. Now,
> it is usually the actual format of the file that tells the OS what it
> really is and how it should be handled.
>>
>> But that is almost impossible now, unless users manually allow that.
>
> Don't trust names to have any meaning, that goes for extensions too.




The whole point is if you set your system to specific applications for
certain extensions,.....you can't run into too many problems if say a file
with .mov or .avi, that is really a malware type .exe,.... automatically is
opened by a video player, all it will do is choke and throw an error without
doing any damage.

Let windows decide on it's own how to run it and you are begging for
problems

[FromTheRafters]

After serious thinking Dustin wrote :
> FromTheRafters <erratic@nomail.afraid.org> wrote in
> news:k5acms$d3p$1@dont-email.me:
>
>> Ant submitted this idea :
>>> "Virus Guy" wrote:
>>>
>>>> When a malicious process or mechanism has deposited an executable
>>>> file onto a system, and given the file some innocuous extention
>>>> (like .txt or .jpg), I'll take win-98 any day over NT because
>>>> win-98 will apparently NOT be tricked into running the malicious
>>>> file.
>>>
>>> Neither will NT, at least not W2k or XP. I don't know what system
>>> FTR is running but renaming an exe to txt or something else will not
>>> invoke the executable image loader but will start the application
>>> associated with the file extension; e.g. notepad. If an application
>>> can't handle the format, e.g. a media player, then an error message
>>> is given.
>>
>> Yes, it is equivalent to opening the default program to handle that
>> filetype and selecting the file-open dialog *if* that extension is
>> associated with that program in the registry. I have hide extensions
>> for known filetypes checked in my folder options so I wasn't *really*
>> changing the extension or the association - only how it appears to
>> the average user.
>>>
>>> If the behaviour of Windows since XP has changed, in that the format
>>> is examined to decide how to open it, then this is a very bad idea.
>>
>> As I recall, W98 did that with OLE2 files if extensionless. I think
>> the trouble comes from inconsistency between the two methods and not
>> that one method is wrong and the other right. Windows users are quite
>> used to the idea that a book can be judged by its cover, that is its
>> filename or its icon. What really counts is the actual type of
>> content.
>>
>>> When an advanced user sees a txt extension then he expects a doubl-
>>> click to open the file in a text editor irrespective of its format.
>>
>> Yes, but mostly because he is used to it being that way.
>>
>>> I say "advanced" because I'm talking about those who don't hide the
>>> file extensions. Obviously I'm not addressing the stupid situation
>>> where extensions are hidden and a file named as test.txt.exe (an
>>> executable) shows up as test.txt.
>>
>> I often wondered why MS decided to do that as the default condition.
>> Yes, that is why my calc.exe appeared to be calc.mp3 on my desktop.
>> The OS wasn't fooled into thinking it was an mp3 but the user might
>> well have been - even the "properties" dialog lies to the user. As I
>> recall, even the loaders do not depend upon filename extensions but
>> rather on actual file content when deciding if they can or cannot
>> handle the loading of that file's executable image, and even this has
>> caused some confusion where an exe renamed to bat or com can still
>> execute as if it hadn't been renamed.
>
> Gets more interesting..
>
> If you have calc.bat, calc.com and calc.exe
>
> which do you think executes? [g]

Since it is *really* an exefile, it is the exefile loader that actually
loads it and it is an exe that executes no matter what the name is.

The exe loader recognizes the exefile by its format and loads it. I'm
not sure which order the loaders are in, but all three extensions will
be associated with the chain. If the first loader doesn't recognize the
file as being something that it knows how to load, it passes it along
to the next loader and on down the line until one does recognize it.

This is the OS ultimately doing this, not the GUI shell. All I'm saying
is that filenames may or may not be indicative of what the file's
content actually is, and the actual content is what matters. If all
files had content in their headers that could be used in the same
manner as Windows uses filename extensions then there wouldn't be any
mismatches and icons and actions could be assigned based upon actual
filetype.

[FromTheRafters]

Bast expressed precisely :
>
> FromTheRafters wrote:
>> Bast submitted this idea :
>>>
>>> Virus Guy wrote:
>>>> "David H. Lipman" wrote:
>>>>
>>>>>>> It it even possible that when launched from a media-player (such
>>>>>>> as VLC) that there exists a class of avi, mp3, flac (etc) malware
>>>>>>> that can leverage a player vulnerability and cause it to run
>>>>>>> arbitrary code?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> Some specific players could be tricked into visiting a maliciously
>>>>>> formed website embedded in the id3tags.
>>>>
>>>>>> The Wimad trojan
>>>>
>>>> So basically these boil down to browser exploits. A URL launched from
>>>> Windoze Media Player is still a browser exploit.
>>>>
>>>> And they're not even exploits - they depend on user action in the
>>>> browser to allow what-ever operation they're trying to accomplish (ie
>>>> - social engineering).
>>>>
>>>> What I'm asking about is a media file that upon playing can cause any
>>>> media player to run arbitrary code WITHOUT NEEDING THE USER'S HELP,
>>>> and thereby cause the user's system to download secondary payloads,
>>>> change registry settings, etc. All without enlisting the system's
>>>> web-browser. Has there ever been a media file (mp3, avi, flac, etc) that
>>>> could
>>>> accomplish that?
>>>
>>>
>>>
>>>
>>> Nope, not if a user has file types set.
>>>
>>> An exploit in widows can allow renaming a file extension from say .exe
>>> to .mov
>>> Or naming it with no extension at all.
>>> And windows was stupid enough to recognize it as an .exe despite the
>>> extension, and run it as such.
>>
>> Er, what is stupid is relying on the extension to mean anything. Now,
>> it is usually the actual format of the file that tells the OS what it
>> really is and how it should be handled.
>>>
>>> But that is almost impossible now, unless users manually allow that.
>>
>> Don't trust names to have any meaning, that goes for extensions too.
>
>
>
>
> The whole point is if you set your system to specific applications for
> certain extensions,.....you can't run into too many problems if say a file
> with .mov or .avi, that is really a malware type .exe,.... automatically is
> opened by a video player, all it will do is choke and throw an error without
> doing any damage.
>
> Let windows decide on it's own how to run it and you are begging for problems

Right, but when you download a file you are not actually downloading a
file, you are downloading content from a remote file into a new local
file that may or may not even have the same naming convention. If
decisions were made as to what icon to present in the GUI or what
application to associate the file with are made with respect to the
content rather than the filename there would be less chance for
confusion. A exefile named benign.jpg would still be associated with
the loader chain and have an icon showing it as an executable.

Custom icons could still be used, but as with the little arrow that
Windows uses for shortcut icons - there could be a little star or
border or something to show it as an executable. That way, if an exe
had an icon like notepad and an extension of .txt it would *still* show
the user that it is an executable and it would still be loadable
because the OS uses the content rather than the name to make its
decisions about loading an executable image.

[Bast]

FromTheRafters wrote:
> Bast expressed precisely :
>>
>> FromTheRafters wrote:
>>> Bast submitted this idea :
>>>>
>>>> Virus Guy wrote:
>>>>> "David H. Lipman" wrote:
>>>>>
>>>>>>>> It it even possible that when launched from a media-player (such
>>>>>>>> as VLC) that there exists a class of avi, mp3, flac (etc) malware
>>>>>>>> that can leverage a player vulnerability and cause it to run
>>>>>>>> arbitrary code?
>>>>>>>
>>>>>>> Yes.
>>>>>>>
>>>>>>> Some specific players could be tricked into visiting a maliciously
>>>>>>> formed website embedded in the id3tags.
>>>>>
>>>>>>> The Wimad trojan
>>>>>
>>>>> So basically these boil down to browser exploits. A URL launched
>>>>> from Windoze Media Player is still a browser exploit.
>>>>>
>>>>> And they're not even exploits - they depend on user action in the
>>>>> browser to allow what-ever operation they're trying to accomplish
>>>>> (ie - social engineering).
>>>>>
>>>>> What I'm asking about is a media file that upon playing can cause
>>>>> any media player to run arbitrary code WITHOUT NEEDING THE USER'S
>>>>> HELP, and thereby cause the user's system to download secondary
>>>>> payloads,
>>>>> change registry settings, etc. All without enlisting the system's
>>>>> web-browser. Has there ever been a media file (mp3, avi, flac, etc)
>>>>> that could
>>>>> accomplish that?
>>>>
>>>>
>>>>
>>>>
>>>> Nope, not if a user has file types set.
>>>>
>>>> An exploit in widows can allow renaming a file extension from say
>>>> .exe to .mov
>>>> Or naming it with no extension at all.
>>>> And windows was stupid enough to recognize it as an .exe despite the
>>>> extension, and run it as such.
>>>
>>> Er, what is stupid is relying on the extension to mean anything. Now,
>>> it is usually the actual format of the file that tells the OS what it
>>> really is and how it should be handled.
>>>>
>>>> But that is almost impossible now, unless users manually allow that.
>>>
>>> Don't trust names to have any meaning, that goes for extensions too.
>>
>>
>>
>>
>> The whole point is if you set your system to specific applications for
>> certain extensions,.....you can't run into too many problems if say a
>> file with .mov or .avi, that is really a malware type .exe,....
>> automatically is opened by a video player, all it will do is choke and
>> throw an error without doing any damage.
>>
>> Let windows decide on it's own how to run it and you are begging for
>> problems
>
> Right, but when you download a file you are not actually downloading a
> file,


Whaaaaa ??????
You download a file, PERIOD.


you are downloading content from a remote file into a new local
> file that may or may not even have the same naming convention. If
> decisions were made as to what icon to present in the GUI or what
> application to associate the file with are made with respect to the
> content rather than the filename there would be less chance for
> confusion. A exefile named benign.jpg would still be associated with
> the loader chain and have an icon showing it as an executable.
>
> Custom icons could still be used, but as with the little arrow that
> Windows uses for shortcut icons - there could be a little star or
> border or something to show it as an executable. That way, if an exe
> had an icon like notepad and an extension of .txt it would *still* show
> the user that it is an executable and it would still be loadable
> because the OS uses the content rather than the name to make its
> decisions about loading an executable image.




FILE ICONS are created and placed by your own system, they are not
downloaded with files.
Website icons are downloaded only when you view a webpage but are only saved
and read by a browser.

[Shadow]

On Sat, 13 Oct 2012 09:08:32 -0400, "Bast" <fakename@nomail.invalid>
wrote:

>FILE ICONS are created and placed by your own system, they are not
>downloaded with files.

Huh ? Maybe in linux, but most Windows icons are in the
(downloaded) executables .....
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

[Dustin]

FromTheRafters <erratic@nomail.afraid.org> wrote in news:k5bmn3$8h8$1
@dont-email.me:

> After serious thinking Dustin wrote :
>> FromTheRafters <erratic@nomail.afraid.org> wrote in
>> news:k5acms$d3p$1@dont-email.me:
>>
>>> Ant submitted this idea :
>>>> "Virus Guy" wrote:
>>>>
>>>>> When a malicious process or mechanism has deposited an executable
>>>>> file onto a system, and given the file some innocuous extention
>>>>> (like .txt or .jpg), I'll take win-98 any day over NT because
>>>>> win-98 will apparently NOT be tricked into running the malicious
>>>>> file.
>>>>
>>>> Neither will NT, at least not W2k or XP. I don't know what system
>>>> FTR is running but renaming an exe to txt or something else will
not
>>>> invoke the executable image loader but will start the application
>>>> associated with the file extension; e.g. notepad. If an application
>>>> can't handle the format, e.g. a media player, then an error message
>>>> is given.
>>>
>>> Yes, it is equivalent to opening the default program to handle that
>>> filetype and selecting the file-open dialog *if* that extension is
>>> associated with that program in the registry. I have hide extensions
>>> for known filetypes checked in my folder options so I wasn't
*really*
>>> changing the extension or the association - only how it appears to
>>> the average user.
>>>>
>>>> If the behaviour of Windows since XP has changed, in that the
format
>>>> is examined to decide how to open it, then this is a very bad idea.
>>>
>>> As I recall, W98 did that with OLE2 files if extensionless. I think
>>> the trouble comes from inconsistency between the two methods and not
>>> that one method is wrong and the other right. Windows users are
quite
>>> used to the idea that a book can be judged by its cover, that is its
>>> filename or its icon. What really counts is the actual type of
>>> content.
>>>
>>>> When an advanced user sees a txt extension then he expects a doubl-
>>>> click to open the file in a text editor irrespective of its format.
>>>
>>> Yes, but mostly because he is used to it being that way.
>>>
>>>> I say "advanced" because I'm talking about those who don't hide the
>>>> file extensions. Obviously I'm not addressing the stupid situation
>>>> where extensions are hidden and a file named as test.txt.exe (an
>>>> executable) shows up as test.txt.
>>>
>>> I often wondered why MS decided to do that as the default condition.
>>> Yes, that is why my calc.exe appeared to be calc.mp3 on my desktop.
>>> The OS wasn't fooled into thinking it was an mp3 but the user might
>>> well have been - even the "properties" dialog lies to the user. As I
>>> recall, even the loaders do not depend upon filename extensions but
>>> rather on actual file content when deciding if they can or cannot
>>> handle the loading of that file's executable image, and even this
has
>>> caused some confusion where an exe renamed to bat or com can still
>>> execute as if it hadn't been renamed.
>>
>> Gets more interesting..
>>
>> If you have calc.bat, calc.com and calc.exe
>>
>> which do you think executes? [g]
>
> Since it is *really* an exefile, it is the exefile loader that
actually
> loads it and it is an exe that executes no matter what the name is.

I agree. However, if you have all three files with the same
aforementioned names and you don't specify the extension, the load order
is bat, com and finally *.exe. So.. if you mark .bat.com hidden!, the
user doesn't know he/she isn't running what they thought they were. [g]

> is that filenames may or may not be indicative of what the file's
> content actually is, and the actual content is what matters. If all
> files had content in their headers that could be used in the same
> manner as Windows uses filename extensions then there wouldn't be any
> mismatches and icons and actions could be assigned based upon actual
> filetype.

Yep.


--
There ain't no rest for the wicked. Money don't grow on trees. I got
bills to pay. I got mouths to feed. Ain't nothing in this world for
free. Oh No. I can't slow down, I can't hold back though you know I wish
I could. Oh no there ain't no rest for the wicked, until we close our
eyes for good.

[Ant]

"FromTheRafters" wrote:

> Ant submitted this idea :
>> "Virus Guy" wrote:
>>> I'll take win-98 any day over NT because win-98 will apparently
>>> NOT be tricked into running the malicious file.
>>
>> Neither will NT, at least not W2k or XP. I don't know what system FTR
>> is running but renaming an exe to txt or something else will not invoke
>> the executable image loader but will start the application associated
>> with the file extension; e.g. notepad. If an application can't handle
>> the format, e.g. a media player, then an error message is given.
>
> Yes, it is equivalent to opening the default program to handle that
> filetype and selecting the file-open dialog *if* that extension is
> associated with that program in the registry. I have hide extensions
> for known filetypes checked in my folder options

I am surprised. Why would you hide those extensions?

> so I wasn't *really*
> changing the extension or the association - only how it appears to the
> average user.

Then I don't see your point of disagreement with VG. You and he are
advanced users so I would expect you both not to allow the OS to hide
extensions or any other type of file (system or hidden).

>> If the behaviour of Windows since XP has changed, in that the format
>> is examined to decide how to open it, then this is a very bad idea.
>
> As I recall, W98 did that with OLE2 files if extensionless.

So does NT - and also for OLE2 files with unregistered extensions. I
think that's also a bad idea. Fortunately it's rare, the icon will be
the default unknown-type icon (so the user won't have the expectation
of a particular application starting), and it's pretty much restricted
to MS Office docs.

> I think the
> trouble comes from inconsistency between the two methods and not that
> one method is wrong and the other right.

It's a mistake. The OLE2 thing is an aberration.

> Windows users are quite used
> to the idea that a book can be judged by its cover, that is its
> filename or its icon.

Exactly; "the principal of least surprise" I think it's called.

> What really counts is the actual type of content.

What counts is a double-click doing what you expect it to do. If you
hide file extensions all bets are off.

>> When an advanced user sees a txt extension then he expects a doubl-
>> click to open the file in a text editor irrespective of its format.
>
> Yes, but mostly because he is used to it being that way.

Because it has always been that way in Windows and apparently still is.
Other OS's may behave differently.

>> I say "advanced" because I'm talking about those who don't hide the
>> file extensions. Obviously I'm not addressing the stupid situation
>> where extensions are hidden and a file named as test.txt.exe (an
>> executable) shows up as test.txt.
>
> I often wondered why MS decided to do that as the default condition.

Probably because the marketoons got their way over the tech people.
Windows seems to be aspiring to look like what it isn't, e.g. MacOS.

> Yes, that is why my calc.exe appeared to be calc.mp3 on my desktop. The
> OS wasn't fooled into thinking it was an mp3

Of course not because you didn't change the extension.

> but the user might well have been

Of course, the average user has no hope!

> - even the "properties" dialog lies to the user.

The properties shown should have been for the exe, no?

> As I recall,
> even the loaders do not depend upon filename extensions but rather on
> actual file content when deciding if they can or cannot handle the
> loading of that file's executable image, and even this has caused some
> confusion where an exe renamed to bat or com can still execute as if it
> hadn't been renamed.

Files like bat, com, exe, scr and pif are all handled by the OS and
not associated with an application. The expectation should be that
code will be loaded and run.

[FromTheRafters]

Dustin pretended :
> FromTheRafters <erratic@nomail.afraid.org> wrote in news:k5bmn3$8h8$1
> @dont-email.me:
>
>> After serious thinking Dustin wrote :
>>> FromTheRafters <erratic@nomail.afraid.org> wrote in
>>> news:k5acms$d3p$1@dont-email.me:
>>>
>>>> Ant submitted this idea :
>>>>> "Virus Guy" wrote:
>>>>>
>>>>>> When a malicious process or mechanism has deposited an executable
>>>>>> file onto a system, and given the file some innocuous extention
>>>>>> (like .txt or .jpg), I'll take win-98 any day over NT because
>>>>>> win-98 will apparently NOT be tricked into running the malicious
>>>>>> file.
>>>>>
>>>>> Neither will NT, at least not W2k or XP. I don't know what system
>>>>> FTR is running but renaming an exe to txt or something else will not
>>>>> invoke the executable image loader but will start the application
>>>>> associated with the file extension; e.g. notepad. If an application
>>>>> can't handle the format, e.g. a media player, then an error message
>>>>> is given.
>>>>
>>>> Yes, it is equivalent to opening the default program to handle that
>>>> filetype and selecting the file-open dialog *if* that extension is
>>>> associated with that program in the registry. I have hide extensions
>>>> for known filetypes checked in my folder options so I wasn't *really*
>>>> changing the extension or the association - only how it appears to
>>>> the average user.
>>>>>
>>>>> If the behaviour of Windows since XP has changed, in that the format
>>>>> is examined to decide how to open it, then this is a very bad idea.
>>>>
>>>> As I recall, W98 did that with OLE2 files if extensionless. I think
>>>> the trouble comes from inconsistency between the two methods and not
>>>> that one method is wrong and the other right. Windows users are quite
>>>> used to the idea that a book can be judged by its cover, that is its
>>>> filename or its icon. What really counts is the actual type of
>>>> content.
>>>>
>>>>> When an advanced user sees a txt extension then he expects a doubl-
>>>>> click to open the file in a text editor irrespective of its format.
>>>>
>>>> Yes, but mostly because he is used to it being that way.
>>>>
>>>>> I say "advanced" because I'm talking about those who don't hide the
>>>>> file extensions. Obviously I'm not addressing the stupid situation
>>>>> where extensions are hidden and a file named as test.txt.exe (an
>>>>> executable) shows up as test.txt.
>>>>
>>>> I often wondered why MS decided to do that as the default condition.
>>>> Yes, that is why my calc.exe appeared to be calc.mp3 on my desktop.
>>>> The OS wasn't fooled into thinking it was an mp3 but the user might
>>>> well have been - even the "properties" dialog lies to the user. As I
>>>> recall, even the loaders do not depend upon filename extensions but
>>>> rather on actual file content when deciding if they can or cannot
>>>> handle the loading of that file's executable image, and even this has
>>>> caused some confusion where an exe renamed to bat or com can still
>>>> execute as if it hadn't been renamed.
>>>
>>> Gets more interesting..
>>>
>>> If you have calc.bat, calc.com and calc.exe
>>>
>>> which do you think executes? [g]
>>
>> Since it is *really* an exefile, it is the exefile loader that actually
>> loads it and it is an exe that executes no matter what the name is.
>
> I agree. However, if you have all three files with the same
> aforementioned names and you don't specify the extension, the load order
> is bat, com and finally *.exe.

Thanks, I had forgotten the order. So in DOS it's batfile (bat),
internal command (com), external command (com) and then exefile. I knew
that some exes could be renamed to comfile to avoid some old appkillers
(filters?) - in fact didn't MBAM at one time suggest that method for
those having trouble with their exe not running?

> So.. if you mark .bat.com hidden!, the
> user doesn't know he/she isn't running what they thought they were. [g]

I really liked the ADS running on XP with a text file showing in the
process list. You remember benign.txt:some.exe and when running the
process showed as benign.txt. Yeah, they fixed that, but I thought it
was cool.
>
>> is that filenames may or may not be indicative of what the file's
>> content actually is, and the actual content is what matters. If all
>> files had content in their headers that could be used in the same
>> manner as Windows uses filename extensions then there wouldn't be any
>> mismatches and icons and actions could be assigned based upon actual
>> filetype.
>
> Yep.

Well, I suspect another executable format will come - maybe newnewexe.

[FromTheRafters]

It happens that Ant formulated :
> "FromTheRafters" wrote:
>
>> Ant submitted this idea :
>>> "Virus Guy" wrote:
>>>> I'll take win-98 any day over NT because win-98 will apparently
>>>> NOT be tricked into running the malicious file.
>>>
>>> Neither will NT, at least not W2k or XP. I don't know what system FTR
>>> is running but renaming an exe to txt or something else will not invoke
>>> the executable image loader but will start the application associated
>>> with the file extension; e.g. notepad. If an application can't handle
>>> the format, e.g. a media player, then an error message is given.
>>
>> Yes, it is equivalent to opening the default program to handle that
>> filetype and selecting the file-open dialog *if* that extension is
>> associated with that program in the registry. I have hide extensions
>> for known filetypes checked in my folder options
>
> I am surprised. Why would you hide those extensions?

Maybe I should make an image *after* I set things up correctly.
>
>> so I wasn't *really*
>> changing the extension or the association - only how it appears to the
>> average user.
>
> Then I don't see your point of disagreement with VG. You and he are
> advanced users so I would expect you both not to allow the OS to hide
> extensions or any other type of file (system or hidden).

My disagreement is in thinking that filenames have meaning. Why can't
there be some sort of internal 'content type' metadata being used
instead of relying on a filename extension? That way, the 'content
type' travels *with* the content it describes and the name doesn't
matter.

The problem isn't that the OS gets tricked into running something, it
is that the *user* does because of the name and the icon associated
with that name. If the icon was associated with the *content* instead
of the name wouldn't it be that much clearer what one is about to
double-click on?
>
>>> If the behaviour of Windows since XP has changed, in that the format
>>> is examined to decide how to open it, then this is a very bad idea.
>>
>> As I recall, W98 did that with OLE2 files if extensionless.
>
> So does NT - and also for OLE2 files with unregistered extensions. I
> think that's also a bad idea. Fortunately it's rare, the icon will be
> the default unknown-type icon (so the user won't have the expectation
> of a particular application starting), and it's pretty much restricted
> to MS Office docs.

I didn't know that was still the way it worked. If they're going to use
filename extensions to associate, they should do it across the board
and not be so inconsistent. This only serves to confuse matters I
think.
>
>> I think the
>> trouble comes from inconsistency between the two methods and not that
>> one method is wrong and the other right.
>
> It's a mistake. The OLE2 thing is an aberration.
>
>> Windows users are quite used
>> to the idea that a book can be judged by its cover, that is its
>> filename or its icon.
>
> Exactly; "the principal of least surprise" I think it's called.
>
>> What really counts is the actual type of content.
>
> What counts is a double-click doing what you expect it to do. If you
> hide file extensions all bets are off.

Back in the day, I remember it being said that to open a text file (or
just about any file) you should go to the application and use the file
open dialog from the pulldown menu instead of relying on double-click
association with a default editor. Even so, it was so much more
convenient to just double-click and trust that everything went okay.
>
>>> When an advanced user sees a txt extension then he expects a doubl-
>>> click to open the file in a text editor irrespective of its format.
>>
>> Yes, but mostly because he is used to it being that way.
>
> Because it has always been that way in Windows and apparently still is.
> Other OS's may behave differently.
>
>>> I say "advanced" because I'm talking about those who don't hide the
>>> file extensions. Obviously I'm not addressing the stupid situation
>>> where extensions are hidden and a file named as test.txt.exe (an
>>> executable) shows up as test.txt.
>>
>> I often wondered why MS decided to do that as the default condition.
>
> Probably because the marketoons got their way over the tech people.
> Windows seems to be aspiring to look like what it isn't, e.g. MacOS.
>
>> Yes, that is why my calc.exe appeared to be calc.mp3 on my desktop. The
>> OS wasn't fooled into thinking it was an mp3
>
> Of course not because you didn't change the extension.
>
>> but the user might well have been
>
> Of course, the average user has no hope!
>
>> - even the "properties" dialog lies to the user.
>
> The properties shown should have been for the exe, no?

No, it displayed calc.mp3 but described it correctly as an application.

http://i47.tinypic.com/2s8k9ig.jpg

Applying the 'do not hide stuff' has the name in the dialog box as
calc.mp3.exe like it should.

[...]

[FromTheRafters]

Bast brought next idea :
>
> FromTheRafters wrote:
>> Bast expressed precisely :
>>>
>>> FromTheRafters wrote:
>>>> Bast submitted this idea :
>>>>>
>>>>> Virus Guy wrote:
>>>>>> "David H. Lipman" wrote:
>>>>>>
>>>>>>>>> It it even possible that when launched from a media-player (such
>>>>>>>>> as VLC) that there exists a class of avi, mp3, flac (etc) malware
>>>>>>>>> that can leverage a player vulnerability and cause it to run
>>>>>>>>> arbitrary code?
>>>>>>>>
>>>>>>>> Yes.
>>>>>>>>
>>>>>>>> Some specific players could be tricked into visiting a maliciously
>>>>>>>> formed website embedded in the id3tags.
>>>>>>
>>>>>>>> The Wimad trojan
>>>>>>
>>>>>> So basically these boil down to browser exploits. A URL launched
>>>>>> from Windoze Media Player is still a browser exploit.
>>>>>>
>>>>>> And they're not even exploits - they depend on user action in the
>>>>>> browser to allow what-ever operation they're trying to accomplish
>>>>>> (ie - social engineering).
>>>>>>
>>>>>> What I'm asking about is a media file that upon playing can cause
>>>>>> any media player to run arbitrary code WITHOUT NEEDING THE USER'S
>>>>>> HELP, and thereby cause the user's system to download secondary
>>>>>> payloads,
>>>>>> change registry settings, etc. All without enlisting the system's
>>>>>> web-browser. Has there ever been a media file (mp3, avi, flac, etc)
>>>>>> that could
>>>>>> accomplish that?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Nope, not if a user has file types set.
>>>>>
>>>>> An exploit in widows can allow renaming a file extension from say
>>>>> .exe to .mov
>>>>> Or naming it with no extension at all.
>>>>> And windows was stupid enough to recognize it as an .exe despite the
>>>>> extension, and run it as such.
>>>>
>>>> Er, what is stupid is relying on the extension to mean anything. Now,
>>>> it is usually the actual format of the file that tells the OS what it
>>>> really is and how it should be handled.
>>>>>
>>>>> But that is almost impossible now, unless users manually allow that.
>>>>
>>>> Don't trust names to have any meaning, that goes for extensions too.
>>>
>>>
>>>
>>>
>>> The whole point is if you set your system to specific applications for
>>> certain extensions,.....you can't run into too many problems if say a
>>> file with .mov or .avi, that is really a malware type .exe,....
>>> automatically is opened by a video player, all it will do is choke and
>>> throw an error without doing any damage.
>>>
>>> Let windows decide on it's own how to run it and you are begging for
>>> problems
>>
>> Right, but when you download a file you are not actually downloading a
>> file,
>
>
> Whaaaaa ??????
> You download a file, PERIOD.

Okay.
>
> you are downloading content from a remote file into a new local
>> file that may or may not even have the same naming convention. If
>> decisions were made as to what icon to present in the GUI or what
>> application to associate the file with are made with respect to the
>> content rather than the filename there would be less chance for
>> confusion. A exefile named benign.jpg would still be associated with
>> the loader chain and have an icon showing it as an executable.
>>
>> Custom icons could still be used, but as with the little arrow that
>> Windows uses for shortcut icons - there could be a little star or
>> border or something to show it as an executable. That way, if an exe
>> had an icon like notepad and an extension of .txt it would *still* show
>> the user that it is an executable and it would still be loadable
>> because the OS uses the content rather than the name to make its
>> decisions about loading an executable image.
>
>
>
>
> FILE ICONS are created and placed by your own system, they are not downloaded
> with files.

Some are, some aren't.

> Website icons are downloaded only when you view a webpage but are only saved
> and read by a browser.

Okay.