Microsoft: piracy is getting virusy

[FromTheRafters]

"Bast" <fakename@nomail.invalid> wrote in message
news:k5b5o6$ktk$1@dont-email.me...
>
>
> 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

I didn't see the expected RLO demonstration in MesNews, so I decided to post
with Outlook Express. I couldn't find the post I really wanted to reply to
while in OE so I replied here. Sorry for any confusion.
simplexe.txt
simpl?txt.exe

[Bast]

FromTheRafters wrote:
> 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.




It wouldn't fool my system.
Clicking it would open textpad, and the file would choke.

Of course if you want to turn off viewing extensions and hidden files, and
put all your trust in Windows,....good luck.

[Ant]

"FromTheRafters" wrote:

>Ant wrote :
>> 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.

That's how Unix does it.

>> 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.

I think that would be a good idea anyway. Make applications very
distinct from documents/data.

>> 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.

Like the resource fork in MacOS or alternate data streams and extended
attributes in NTFS. The trouble is that a file and its metadata are
soon parted when copied to other file systems (USB sticks).

[Ant]

"Bast" wrote:

> FromTheRafters wrote:
>> 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

Yes, despite my reply not recognising it in the quoted text, both of
those appeared as the same name: "simplexe.txt" in your post.

>> If this executable had a notepad icon in its resource section then it
>> wouldn't take an idiot to be fooled.

Perhaps not but it is listed as an application rather than a text
document. It also gets weird if you try to rename a file like that in
Explorer. The cursor appears in the middle of the name (after the 'L'
even if you press "end") and the cursor keys and backspace move in the
opposite direction in the text after the invisible RLO character.

> It wouldn't fool my system.

It appears to work only in newer versions of Explorer where "newer" is
some time after Win2k. The RLO character has no effect on the name in
older versions and appears as a small black rectangle.

> Clicking it would open textpad, and the file would choke.

If the file is named simpl[RLO]txt.exe where [RLO] is the override
character it will be treated as an executable no matter how it appears
in an Explorer window; e.g. as simplexe.txt.

[Bast]

Ant wrote:
> "Bast" wrote:
>
>> FromTheRafters wrote:
>>> 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
>
> Yes, despite my reply not recognising it in the quoted text, both of
> those appeared as the same name: "simplexe.txt" in your post.
>
>>> If this executable had a notepad icon in its resource section then it
>>> wouldn't take an idiot to be fooled.
>
> Perhaps not but it is listed as an application rather than a text
> document. It also gets weird if you try to rename a file like that in
> Explorer. The cursor appears in the middle of the name (after the 'L'
> even if you press "end") and the cursor keys and backspace move in the
> opposite direction in the text after the invisible RLO character.
>
>> It wouldn't fool my system.
>
> It appears to work only in newer versions of Explorer where "newer" is
> some time after Win2k. The RLO character has no effect on the name in
> older versions and appears as a small black rectangle.
>
>> Clicking it would open textpad, and the file would choke.
>
> If the file is named simpl[RLO]txt.exe where [RLO] is the override
> character it will be treated as an executable no matter how it appears
> in an Explorer window; e.g. as simplexe.txt.



Even in windows 8, it can only work if extensions are ignored.
I hate to say this but some people just beg for problems, when they think
putting their faith in dumbed down operating systems is a good idea.
With a bit of common sense, you don't have those problems.

Of course, the I-phone generation is also often stupid enough to text while
walking and step right out in front of cars. So perhaps some people just
shouldn't own computers either

[Ant]

"Bast" wrote:

> Ant wrote:
>> If the file is named simpl[RLO]txt.exe where [RLO] is the override
>> character it will be treated as an executable no matter how it appears
>> in an Explorer window; e.g. as simplexe.txt.
>
> Even in windows 8, it can only work if extensions are ignored.

This is nothing to do with whether extensions are hidden or not. It's
about using the right-to-left override unicode character in a filename
to make it appear to have an extension it does not have. It works when
extensions for registered file types are not hidden.

[Bear]

Dustin <bughunter.dustin@gmail.com> wrote in
news:XnsA0EB19221E7CBHHI2948AJD832@no:

> 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]

Try Google and find the answer on this page...

http://support.microsoft.com/kb/35284

Jax
--
Bear Bottoms
http://bearware.info

[Dustin]

Bear <removebear.bottoms1@gmail.com> wrote in
news:XnsA0EEF1B108660bearbottoms1gmail.AC@130.225. 254.104:

> Dustin <bughunter.dustin@gmail.com> wrote in
> news:XnsA0EB19221E7CBHHI2948AJD832@no:
>
>> 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]
>
> Try Google and find the answer on this page...

Did you not notice the [g]? I already know the execution order.

> http://support.microsoft.com/kb/35284

You mean, Billy didn't know?


--
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.

[FromTheRafters]

on 10/15/2012, Ant supposed :
> "FromTheRafters" wrote:
>
>> Ant wrote :
>>> 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.
>
> That's how Unix does it.
>
>>> 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.
>
> I think that would be a good idea anyway. Make applications very
> distinct from documents/data.
>
>>> 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.
>
> Like the resource fork in MacOS or alternate data streams and extended
> attributes in NTFS. The trouble is that a file and its metadata are
> soon parted when copied to other file systems (USB sticks).

Yeah, but if that metadata is actually in the file's content and only
copied the one time to the local filesystem to make it more easily
accessible for listing, it would survive being transported across such
systems with filesystems that are incompatible, and those systems would
be unaffected by the change. They could, in fact, still rely on
filename extension if they wanted to.

I dunno, it just seems to me that filenames are too easily manipulated
to have such an important role in how an OS or a user will treat a
file. It made perfect sense in the 8.3 days, but now perhaps something
more robust can be done.

[FromTheRafters]

on 10/15/2012, Ant supposed :
> "Bast" wrote:
>
>> FromTheRafters wrote:
>>> 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
>
> Yes, despite my reply not recognising it in the quoted text, both of
> those appeared as the same name: "simplexe.txt" in your post.

MesNews has an interesting display when you highlight sequentially from
left to right. When you get to the rlo character it inserts a space and
reverses the remainder of the string - then the space progresses
through the rest of the string with each step.
>
>>> If this executable had a notepad icon in its resource section then it
>>> wouldn't take an idiot to be fooled.
>
> Perhaps not but it is listed as an application rather than a text
> document. It also gets weird if you try to rename a file like that in
> Explorer. The cursor appears in the middle of the name (after the 'L'
> even if you press "end") and the cursor keys and backspace move in the
> opposite direction in the text after the invisible RLO character.

I've read somewhere that one needs to edit the registry so as to allow
creation of filenames with such characters. If so, I'm wondering if the
same disallowance applies to such files extracted from archive files. I
have only ever seen these where the name actually comes from within an
archive file.
>
>> It wouldn't fool my system.

More on this here:

http://krebsonsecurity.com/2011/09/r...email-attacks/
>
> It appears to work only in newer versions of Explorer where "newer" is
> some time after Win2k. The RLO character has no effect on the name in
> older versions and appears as a small black rectangle.
>
>> Clicking it would open textpad, and the file would choke.
>
> If the file is named simpl[RLO]txt.exe where [RLO] is the override
> character it will be treated as an executable no matter how it appears
> in an Explorer window; e.g. as simplexe.txt.

I reposted those names in another subthread by using OE because I
wasn't sure that MesNews would show the behavior in a Usenet post.
Apparently it does.