FromTheRafters wrote:
>Applying the 'do not hide stuff' has the name in the dialog box as
>calc.mp3.exe like it should.
Yup. That's why I do it.
FromTheRafters wrote:
>Applying the 'do not hide stuff' has the name in the dialog box as
>calc.mp3.exe like it should.
Yup. That's why I do it.
FromTheRafters wrote:
> 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.
I am pointing out that if you simply download a file of data, you don't get
a file icon with it.
Unless you download a .zip and it's in there.
However you can download ICON FILES as prepared graphics (.ico) , but then
you have to manually assign them to a file type
But in the context of this thread you have virtually no chance of
downloading an .Mp3 or .avi and having an icon come in with it.
>
>> Website icons are downloaded only when you view a webpage but are only
>> saved and read by a browser.
>
> Okay.
FromTheRafters wrote:
> >> 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.
> >
> > The properties shown should have been for the exe, no?
>
> No, it displayed calc.mp3 but described it correctly as an
> application.
>
> Applying the 'do not hide stuff' has the name in the dialog box as
> calc.mp3.exe like it should.
So you can't really change the extension from .exe to .jpg under XP
then?
If not, then this whole idea of file-extensions and how they're handled
under user control is moot.
Virus Guy <Virus@Guy.com> wrote in news:507AB5E5.F621CFD5@Guy.com:
> FromTheRafters wrote:
>
>> >> 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.
>> >
>> > The properties shown should have been for the exe, no?
>>
>> No, it displayed calc.mp3 but described it correctly as an
>> application.
>>
>> Applying the 'do not hide stuff' has the name in the dialog box as
>> calc.mp3.exe like it should.
>
> So you can't really change the extension from .exe to .jpg under XP
> then?
Yes... You can. extensions really mean nothing outside of the GUI you
control.
--
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.
Virus Guy brought next idea :
> FromTheRafters wrote:
>
>>>> 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.
>>>
>>> The properties shown should have been for the exe, no?
>>
>> No, it displayed calc.mp3 but described it correctly as an
>> application.
>>
>> Applying the 'do not hide stuff' has the name in the dialog box as
>> calc.mp3.exe like it should.
>
> So you can't really change the extension from .exe to .jpg under XP
> then?
Not from the shell with 'hide extensions for known filetypes' checked -
which is the normal user experience.
>
> If not, then this whole idea of file-extensions and how they're handled
> under user control is moot.
Not really. Consider an executable file's content being downloaded and
given the name benign.txt.exe in the local filesystem. Consider also
that you have hidden the extensions for known filetypes (default
condidtion for XP). You would have a file named benign.txt.exe in the
filesystem (OS), but the GUI display for the user (user shell) has it
as benign.txt with the .exe hidden. Also, an executable can have a
custom icon in its resource section - in this case a copy of the
notepad icon. There would be no way for the user to tell that it was
not actually a plain old text file just by the presentation in the GUI.
The user double clicks the icon thinking it will invoke the default
text editor (notepad) with the file benign.txt (argument) as the file
content to disply - instead, the executable (benign.txt.exe) runs. The
OS is not being fooled into anything, it is the user that is being
fooled.
A safer way to open such a text file is to invoke notepad and use its
open file dialog to navigate to the file you want to open. That way,
there is never an association set up with the loader chain due to the
actual extension being exe.
IIRC, notepad in W98 won't show you most program file's contents
(they're too large for notepad) but it may offer you the option of
using wordpad. Mostly you will get little rectangles where non-ascii
characters would appear, which is why I used edit.com for my editor.
Bast wrote on 10/14/2012 :
>
> FromTheRafters wrote:
>> 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.
>
>
>
> I am pointing out that if you simply download a file of data, you don't get a
> file icon with it.
> Unless you download a .zip and it's in there.
Yes, and I was pointing out that what actually happens is that your OS
has its filesystem create a new "file" as a destination for the content
of the remote (source) "file's" content. There is no actual "file"
being transferred even though you may be using FTP which by its name
should be a Protocol for Tranferring Files. The source file may even
have a name that is incompatible with your local OS/filesystem's
destination file.
>
> However you can download ICON FILES as prepared graphics (.ico) , but then
> you have to manually assign them to a file type
Yes, and some DLLs are icon libraries as opposed to executable code
libraries. Still, if you try to download an icon file, what you get is
a local file being created on the filesystem for the content of the
remote icon file to be stored locally in. You don't get "that file" -
in fact you may get one of a different name (8.3 vs. LFN) depending on
your system.
>
> But in the context of this thread you have virtually no chance of downloading
> an .Mp3 or .avi and having an icon come in with it.
Of course not, but an executable file can have its own custom icon that
travels with the content when it is downloaded.
[...]
"FromTheRafters" wrote:
> It happens that Ant formulated :
>> I am surprised. Why would you hide those extensions?
>
> Maybe I should make an image *after* I set things up correctly.
So you don't normally hide extensions?
> My disagreement is in thinking that filenames have meaning.
The extensions have meaning in that a shell operation uses them to
decide what application (or not) to open the file with.
> 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.
I wouldn't like that at all. If I double click on a malicious exe (not
that I deliberately do) renamed as ".vir" or ".bin" then I don't want
the OS deciding what to do with it; i.e. run it. I want it to open in
a hex editor or whatever I've associated to those extensions.
> 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?
The only way that could work is if displaying an icon resource from
the exe were disallowed. You would then use a generic icon for all
exes. It would also slow down explorer listings as the OS would have
to scan every file in a directory to see what icon to use. There's
also no quick way of determining whether a file is text only,
especially in these days of unicode.
>> So does NT - and also for OLE2 files with unregistered extensions.
>
> 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.
Yes, but it only happens where the shell doesn't recognise the
extension or there is none. If I give an OLE2 file a ".txt" extension
it'll open in notepad.
> 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.
I very rarely open anything with a double-click. I use the right-click
menu and select one of the many options I have for various file types.
>>> - 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.
So it's only lying about the filename. The property page shows it as
an application and it even has the version tab.
FromTheRafters wrote:
> Bast wrote on 10/14/2012 :
>>
>> FromTheRafters wrote:
>>> 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.
>>
>>
>>
>> I am pointing out that if you simply download a file of data, you
>> don't get a file icon with it.
>> Unless you download a .zip and it's in there.
>
> Yes, and I was pointing out that what actually happens is that your OS
> has its filesystem create a new "file" as a destination for the content
> of the remote (source) "file's" content. There is no actual "file"
> being transferred even though you may be using FTP which by its name
> should be a Protocol for Tranferring Files. The source file may even
> have a name that is incompatible with your local OS/filesystem's
> destination file.
>>
>> However you can download ICON FILES as prepared graphics (.ico) , but
>> then you have to manually assign them to a file type
>
> Yes, and some DLLs are icon libraries as opposed to executable code
> libraries. Still, if you try to download an icon file, what you get is
> a local file being created on the filesystem for the content of the
> remote icon file to be stored locally in. You don't get "that file" -
> in fact you may get one of a different name (8.3 vs. LFN) depending on
> your system.
>>
>> But in the context of this thread you have virtually no chance of
>> downloading an .Mp3 or .avi and having an icon come in with it.
>
> Of course not, but an executable file can have its own custom icon that
> travels with the content when it is downloaded.
>
> [...]
But who would be stupid enough to think an .exe would contain media content
?
Ant wrote :
> "FromTheRafters" wrote:
>
>> It happens that Ant formulated :
>>> I am surprised. Why would you hide those extensions?
>>
>> Maybe I should make an image *after* I set things up correctly.
>
> So you don't normally hide extensions?
No, but I made my image with default settings for that OOTB experience.
I think I'll re-do it with tools onboard and proper settings.
>
>> My disagreement is in thinking that filenames have meaning.
>
> The extensions have meaning in that a shell operation uses them to
> decide what application (or not) to open the file with.
>
>> 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.
>
> I wouldn't like that at all. If I double click on a malicious exe (not
> that I deliberately do) renamed as ".vir" or ".bin" then I don't want
> the OS deciding what to do with it; i.e. run it. I want it to open in
> a hex editor or whatever I've associated to those extensions.
Yeah, I hadn't considered the ease at which one can 'name away'
executables. I suppose though that it could be done with an execute bit
or something like that. I'm not really opposed to apps being associated
by filename extension with the files they are meant to work with, I
just thought that it could be done with something more meaningful than
a filename where executables are concerned. After all, the loaders
don't depend on filename extensions to determine what kind of
executable they are.
>
>> 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?
>
> The only way that could work is if displaying an icon resource from
> the exe were disallowed.
It could still be allowed, but the shell could overlay something akin
to what it does with shortcut icons. An executable would *always* show
that it is an executable by a star (instead of a little arrow) in the
corner, or a border color for the entire icon. All executables could be
identified clearly no matter what custom icon was included.
> You would then use a generic icon for all
> exes. It would also slow down explorer listings as the OS would have
> to scan every file in a directory to see what icon to use.
That's a good point. As it stands it would only have to look at names,
which are in the filesystem not in the content of the files themselves.
> There's
> also no quick way of determining whether a file is text only,
> especially in these days of unicode.
I suppose the OS could determine such when the file is first saved with
content and such metadata could be stored in the filesystem where it is
more easily accessed.
[...]
It happens that Bast formulated :
>
> FromTheRafters wrote:
>> Bast wrote on 10/14/2012 :
>>>
>>> FromTheRafters wrote:
>>>> 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.
>>>
>>>
>>>
>>> I am pointing out that if you simply download a file of data, you
>>> don't get a file icon with it.
>>> Unless you download a .zip and it's in there.
>>
>> Yes, and I was pointing out that what actually happens is that your OS
>> has its filesystem create a new "file" as a destination for the content
>> of the remote (source) "file's" content. There is no actual "file"
>> being transferred even though you may be using FTP which by its name
>> should be a Protocol for Tranferring Files. The source file may even
>> have a name that is incompatible with your local OS/filesystem's
>> destination file.
>>>
>>> However you can download ICON FILES as prepared graphics (.ico) , but
>>> then you have to manually assign them to a file type
>>
>> Yes, and some DLLs are icon libraries as opposed to executable code
>> libraries. Still, if you try to download an icon file, what you get is
>> a local file being created on the filesystem for the content of the
>> remote icon file to be stored locally in. You don't get "that file" -
>> in fact you may get one of a different name (8.3 vs. LFN) depending on
>> your system.
>>>
>>> But in the context of this thread you have virtually no chance of
>>> downloading an .Mp3 or .avi and having an icon come in with it.
>>
>> Of course not, but an executable file can have its own custom icon that
>> travels with the content when it is downloaded.
>>
>> [...]
>
>
>
> But who would be stupid enough to think an .exe would contain media content ?
I've seen executable files with RLO characters in their filename so
that the shell GUI displays something like simplexe.txt for what
*really* is an executable named simpl[RLO}txt.exe.
one might even be able to see that here since NNTP supports Unicode
now.
simplexe.txt
simpl*txt.exe
If this executable had a notepad icon in its resource section then it
wouldn't take an idiot to be fooled.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote