So THAT's how you get a file extension



  • @Lingerance said:

    @Monomelodies said:
    I'd have to run some tests to see how the various Linux file managers would handle that, it's almost too obvious to work ūüėČ

    Most by default would try and render a thumbnail of the image, unless it happens to be an executable then you get a gear (I think). Thunar confirms this, I have neither Gnome nor KDE installed, so I can't test their file managers. I'll try out endevour2 later on.

     

    Konqueror (KDE) simply opens the image viewer and displays a broken image (thumbnail is the default "this is an image" thumbnail, not an actual thumbnail obviously). No warning whatsoever, but at least it doesn't try to run my "malicious" script ;-). I'm assuming Gnome will do likewise (my EEE uses XFCE so I'll test later on just to be sure).

    I kinda makes sense, since obviously your desktop environment needs to store the associations between file types and applications somewhere (otherwise it would have to prompt if I want to open the file with Gimp, QuikView or whatever it's called, or some other application every time I click it from the manager). OTOH, a file with no (known) extension gets executed just fine (from Konqueror).

    So, to summarise, I think we can conclude it's mainly the "hiding extensions" part that makes this dangerous. Although I would advocate fixing the file managers that allow this so that you can't run a random script without a warning (you'll still only have user-rights so it can't do any REAL harm, but it could cause a lot of inconvenience) or even at all. But obviously this has other implications for usability, so I'd have to think about it. It certainly doesn't feel right. And I definitely don't trust users to realise that clicking picsofnakedbritney.jpg.sh isn't a good idea...



  • @aihtdikh said:

    Extension hiding can be useful; I remember seeing (before windows 95) cases where someone had renamed (e.g.) "story.doc" to "oldstory" and then complained that their story was broken.

    Except it wasn't; only the lazy application refused to make sure it really wasn't the kind of file it could open... to be fair, Windows throws a warning when you try to change the extension which is at least something.

    @aihtdikh said:

    There's a compromise that I've seen in some other file managers where the extension is left unselected when you go to rename a file - you can still change the extension if you want to, but you don't have to do extra work to keep the same extension.
     

    Yeah, I think Gnome does that, and it makes sense. Konq doesn't ATM and neither does Dolphin (Konq replacement in KDE4 IIRC).



  • @Monomelodies said:

    to be fair, Windows throws a warning when you try to change the extension which is at least something.

    Only if it knows the file type you're changing it from (i.e., it's associated with some program). Of course, if it's a "renameable" file, that's usually the case anyway.

     Vista improves on this by not highlighting the extension when you want to rename something, so you don't accidentally remove it.



  • OK, you've done it. You have sucessfully triggered my full-blown extension hating mode. I'll be clear: I think filename extensions are the worst mistake that has been made in computing, ever. I hate them. No, HATE them. PUNY HUMANS STOP USING FILENAME EXTENSIONS!

     And by the way, some of you have suggested that some space should reserved at the beginning of the file from something like the MIME type and that actual file contents should begin afterwards. Others like the extension hiding feature as it hampers tinkering by users. Guess what? You both recreated file type metadata. I guess you'll like your 1984 128k Macintosh computer. Oh, but wait, some of you said you don't like hidden file metadata since it prevents you from changing which application opens a file, but since the file contents don't change, the type does not really change, only the preferred app (which is indeed one thing that the file manager uses the type for, deciding which app to use). Guess what? What you really need is a preferred app metadata. Again, the 1984 Mac will fit your bill with its creator code. The only reason we're stuck with file extensions and/or magic numbers is because conventions from CP/M (which made sense at the time) which were blindly followed by DOS which were themselves blindly followed by Windows even though they were downright stale by 1990; because some protocols do not support file type metadata (ftp comes to mind) even though others do (http and email); because some filesystems are stuck in the "files are just raw data+filename, plus maybe access flags and dates", all of which conspire to force the file type to be crammed in either the filename or the file data (and most of the time both) as there is no other way.

    </mode type='extension hating' severity='full-blown'>



  • @ZPedro said:

    OK, you've done it. You have sucessfully triggered my full-blown extension hating mode. I'll be clear: I think filename extensions are the worst mistake that has been made in computing, ever. I hate them. No, HATE them. PUNY HUMANS STOP USING FILENAME EXTENSIONS!

    Thank you for your rant. Unfortunately, I didn't quite get the details of the solution you are advocating as a replacement for file extensions while conserving simplicity, precious backwards compatibility and not needing to rewrite eleventy billion existing standards. Could you explain it in a little bit more detailed way please, I am sure we have enough space left in the forums so don't worry about that. While you are polishing the final tiny details of your solution, I hope you will forgive me keeping using file extensions as my preferred way to store basic file metadata.



  • @ender said:

    Font files. Even when most of them have extension .ttf, Explorer will examine them more deeply to see if they're OpenType instead of TrueType, and if they are, give them a different icon.

    Yes, it's correct that they're handled this way, but I don't see why this is a problem, or even inconsistent.  Explorer won't attempt to do this for file extensions not registered as fonts.  What's happening is perfectly consistent: the shell assumes a certain file type based on the extension, executes a handler based on that type, and the handler is robust enough to not choke if the file is actually a different type, and maybe even produce a correct result if the file is a similar type.

    Unless I'm missing something, it sounds pretty reasonable to me.



  • @Monomelodies said:

    @Aaron said:

    Aside from being a massive inconvenience to 99% of computer users, it doesn't even really accomplish anything.  It would be a pretty nutty coincidence if a data file, accidentally executed, would run long enough to actually do any damage.

    FilenameIntendedToMakeMeCurious.jpg[.exe]?

    Though if people are used to not having the extension, they'll be just as likely to open FilenameIntendedToMakeMeCurious[.exe], as long as the icon is an image icon. (Maybe more likely, they won't compare it to the other images in their folder and wonder why this one has this weird .jpg tacked on the end...)



  • @TwelveBaud said:

    Shell extension handlers. (Which are responsible for what DaveK sees, though he doesn't know the name or where to find them.)

    ...

    Note how they're all initially keyed off extension though.

    I'm sort of restating a previous reply here, but anyway...

    Yes, this is entirely correct, but shell extensions are extensions.  It's not Windows doing the inspection, or even the shell; the shell just executes a handler based on the extension.

    I understand that some handlers, like the one for MP3 files, are from Microsoft and are installed by default, but they're still extensions, and you could theoretically remove them or substitute your own extension(s) if you wanted to.  As long as the OS secures registration for these handlers (which it does - just don't run as an administrator) then it's no security risk either.



  • @Monomelodies said:

    FilenameIntendedToMakeMeCurious.jpg[.exe]? My main point was that the extension is made important, but is hidden by default. That's the biggest part of the security risk (how many users know how to turn this "feature" off?).

    I'm not sure what it is you're trying to say.  If a user doesn't even know how to turn the "hide file extensions" feature off, then the "JPG" probably means nothing to them, except in the sense of looking very strange in a folder full of other files without ".JPG" at the end.

    I also get the feeling that you haven't actually used Windows in a long time, because there is actually no way to rename an image file in Explorer and make it "executable" if you have file extensions turned off.  If you have MyPic.jpg, it just appears as "MyPic", and if you rename it to "MyPic.exe", it becomes "MyPic.exe.jpg" internally.  Same as if you send someone "MyPic.exe.jpg" and tell them to remove the ".jpg" - they're not even going to see the ".jpg" let alone be able to rename it to just .exe.

    Now if someone has file extensions turned on, then that's a different story, but I think the idea is that people who have this feature turned on are supposed to know what they're doing.  If a user is stupid enough to actually follow instructions to turn on file extensions and rename something to .exe, you can rest assured he'll happily copy and paste a "chmod" command too if that's what's required.  There's no real security advantage to either approach on the backend, it's just a question of how the issue is approached in the UI, and Windows has been doing that pretty well for a long time.

    @Monomelodies said:

    I seem to vaguely remember a not-insignificant number of large virus outbreaks exploiting this.
     

    If you think that the root cause of that has anything to do with file extensions being used as metadata, you're dreaming.  If spam e-mails can get users to send their credit card details to total strangers running shady websites, they can get users to either rename a file or change the permissions on it.  The difference is trivial.



  • @Lingerance said:

    @burntfuse said:
    I don't see what the security risk of filename extensions is, or why it's scary

    Mostly because you're relying on cosmetic data (the file name) to identify the content you get attacks like open naked_pics.exe.jpg as email attachments (with instructions for stripping the .jpg of the file name), where-as magic number approaches have the identity of the file type mixed with the file data, which is harder for a curious recipient to change, opening it in notepad risks damaging the binary part of it (presuming the virus is an executable or COM file).

    Wow, this whole conversation went right over your head, didn't it?  The users don't have to modify the magic byte sequence on UNIX because it has nothing to do with executability of the program, only the permission controls that.  This means it's quite simple to use the same social engineering attack on UNIX to get an end-user to execute your malicious program. 



  • @Aaron said:

    @Monomelodies said:

    FilenameIntendedToMakeMeCurious.jpg[.exe]? My main point was that the extension is made important, but is hidden by default. That's the biggest part of the security risk (how many users know how to turn this "feature" off?).

    I'm not sure what it is you're trying to say.  If a user doesn't even know how to turn the "hide file extensions" feature off, then the "JPG" probably means nothing to them, except in the sense of looking very strange in a folder full of other files without ".JPG" at the end.

    I also get the feeling that you haven't actually used Windows in a long time, because there is actually no way to rename an image file in Explorer and make it "executable" if you have file extensions turned off.  If you have MyPic.jpg, it just appears as "MyPic", and if you rename it to "MyPic.exe", it becomes "MyPic.exe.jpg" internally.  Same as if you send someone "MyPic.exe.jpg" and tell them to remove the ".jpg" - they're not even going to see the ".jpg" let alone be able to rename it to just .exe.

    Now if someone has file extensions turned on, then that's a different story, but I think the idea is that people who have this feature turned on are supposed to know what they're doing.  If a user is stupid enough to actually follow instructions to turn on file extensions and rename something to .exe, you can rest assured he'll happily copy and paste a "chmod" command too if that's what's required.  There's no real security advantage to either approach on the backend, it's just a question of how the issue is approached in the UI, and Windows has been doing that pretty well for a long time.

    @Monomelodies said:

    I seem to vaguely remember a not-insignificant number of large virus outbreaks exploiting this.
     

    If you think that the root cause of that has anything to do with file extensions being used as metadata, you're dreaming.  If spam e-mails can get users to send their credit card details to total strangers running shady websites, they can get users to either rename a file or change the permissions on it.  The difference is trivial.

    +5 Informative

     

    Seriously, you're one of the only people talking any sense here.  It's a UI issue and it's one that hasn't seriously been a problem for quite some time.  Any decent email client isn't going to let you open exes.  Hell, any decent mail filter is going to flag them as dangerous and scan them for viruses.  If the user is stupid enough to save the file to disk, rename the extension, ignore the "are you sure you want to run this unsigned exe" warning and not run anti-virus, they deserve what's coming to them.  And as you noted, if a user has extensions hidden, there's no way for them to change the extension anyway.  Seriously, people who think Linux would be more secure than Windows are delusional morons.



  • @ZPedro said:

    Guess what? What you really need is a preferred app metadata. Again, the 1984 Mac will fit your bill with its creator code.

    Yes! So I can assign different JPG viewers/editors to all my photos! I've always wanted an option to make DCIM00498.JPG open with the Picture Viewer, and DCIM00451.JPG with the Calculator!



  • @DrJokepu said:

    Thank you for your rant. Unfortunately, I didn't quite get the details of the solution you are advocating as a replacement for file extensions while conserving simplicity, precious backwards compatibility and not needing to rewrite eleventy billion existing standards. Could you explain it in a little bit more detailed way please, I am sure we have enough space left in the forums so don't worry about that. While you are polishing the final tiny details of your solution, I hope you will forgive me keeping using file extensions as my preferred way to store basic file metadata.

    I never claimed I had any solution. I just mentioned these examples as reinforcing my point that file type metadata was how it should have been from the beginning. My solution, if there has to be one, to the current situation, is to simply leave Windows behind with its love of file extensions while the rest of the world moves on.



  • @ZPedro said:

    I just mentioned these examples as reinforcing my point that file type metadata was how it should have been from the beginning.

    Metadata is just something that describes the data but isn't part of the data itself.  File extensions are metadata.  Do you not see that it fits the definition perfectly?

    My solution, if there has to be one, to the current situation, is to simply leave Windows behind with its love of file extensions while the rest of the world moves on.

    The "rest of the world" presumably being all 14 people who care.



  • @ZPedro said:

    @DrJokepu said:

    Thank you for your rant. Unfortunately, I didn't quite get the details of the solution you are advocating as a replacement for file extensions while conserving simplicity, precious backwards compatibility and not needing to rewrite eleventy billion existing standards. Could you explain it in a little bit more detailed way please, I am sure we have enough space left in the forums so don't worry about that. While you are polishing the final tiny details of your solution, I hope you will forgive me keeping using file extensions as my preferred way to store basic file metadata.

    I never claimed I had any solution. I just mentioned these examples as reinforcing my point that file type metadata was how it should have been from the beginning. My solution, if there has to be one, to the current situation, is to simply leave Windows behind with its love of file extensions while the rest of the world moves on.

    No, you just posted an insane, incorrect rant that everybody ignored because it was obvious that you have no idea what you are talking about.  Having the file type in the file name does no harm and it really doesn't provide any benefit, either.  All modern filesystems support file metadata, but some just don't store the content type inside the file.  Your comment on ftp makes no sense.  ftp does not have (nor does it need) content types, because content is not displayed directly as it is in email and on the web.  It does have the annoying text/binary modes, but just using binary is almost always the right solution.  And "the rest of the world" is far from leaving Windows behind, seeing as it constitutes the vast majority of desktop OSes and is a de facto standard that everyone else must follow. 



  • @morbiuswilters said:

    All modern filesystems support file metadata, but some just don't store the content type inside the file.

    In XP and later, you can add "summary" to any file, even plaintext. This is stored in an alternate stream. An irony is that the streams were designed into NTFS, because one of the requirements was to support metadata for Mac network clients.

     @morbiuswilters said:

    ftp does not have (nor does it need) content types, because content is not displayed directly as it is in email and on the web.  It does have the annoying text/binary modes, but just using binary is almost always the right solution

    And FTP is pretty much forgotten anyway. Though Microsoft is still keeping ftp.microsoft.com for those backward customers.

     



  • @alegr said:

    And FTP is pretty much forgotten anyway. Though Microsoft is still keeping ftp.microsoft.com for those backward customers.

    Off topic, but I still use FTP/SCP to upload stuff to my servers. Is that a WTF? Are there any better solutions out there?



  • @morbiuswilters said:

    Wow, this whole conversation went right over your head, didn't it?  The users don't have to modify the magic byte sequence on UNIX because it has nothing to do with executability of the program, only the permission controls that.


    I wasn't clear in my post, I was talking purely about Windows and explorer, if it were to use the magic numbers instead of the file extension, doing the email with extension changing instructions becomes harder as the magic number would have to be changed instead (potentially corrupting the entire file). Eg: Someone sends an exe with it's magic changed to look like a jpg (to by-pass email filters, which would scan the magic instead of the extension).



  • @morbiuswilters said:

    And as you noted, if a user has extensions hidden, there's no way for them to change the extension anyway.

    They wouldn't have to since obviously the trick is to make them believe that they're trying to open a JPG, not a JPG.exe.

    @morbiuswilters said:

    Seriously, people who think Linux would be more secure than Windows are delusional morons.
     

    People who don't see this is prevented in *nix by not having that $%^$#$# execute bit set by default don't really understand how permissions work. But you're forgiven. Seriously.



  • @DrJokepu said:

    @alegr said:
    And FTP is pretty much forgotten anyway. Though Microsoft is still keeping ftp.microsoft.com for those backward customers.

    Off topic, but I still use FTP/SCP to upload stuff to my servers. Is that a WTF? Are there any better solutions out there?
     

    FTP sucks as it's insecure. SCP is just that: secure copy. It's fine (presuming you've set it up correctly etc.). sFTP is sort of an amalgam of both which you're probably referring to, and that's okay-ish as well - it's secure, but not very well-engineered - though the last shouldn't concern the average user.



  • @Lingerance said:

    @morbiuswilters said:

    Wow, this whole conversation went right over your head, didn't it?  The users don't have to modify the magic byte sequence on UNIX because it has nothing to do with executability of the program, only the permission controls that.


    I wasn't clear in my post, I was talking purely about Windows and explorer, if it were to use the magic numbers instead of the file extension, doing the email with extension changing instructions becomes harder as the magic number would have to be changed instead (potentially corrupting the entire file). Eg: Someone sends an exe with it's magic changed to look like a jpg (to by-pass email filters, which would scan the magic instead of the extension).

    Alright, that makes significantly more sense.  However, as has been pointed out, the only way to really trick someone with the extension renaming is if they show extensions which most users will not do.  Also, it takes a significant amount of effort to infect a Windows machine with a virus nowadays.  Windows is very paranoid about exes and anyone who isn't using anti-virus software is just asking for it, unless they are competent enough to never, ever do something that would let a virus take hold. 



  • @Monomelodies said:

    @morbiuswilters said:

    And as you noted, if a user has extensions hidden, there's no way for them to change the extension anyway.

    They wouldn't have to since obviously the trick is to make them believe that they're trying to open a JPG, not a JPG.exe.

    Which has been pointed out several times to not be an issue.  Mail filters and mail apps almost always block exes.  Anti-virus software will pick up the virus before you even click on it.  If you do click on it, Windows will pop up a warning telling you that this is an untrusted executable and that it could have the ability to harm your computer, etc..  Really, it takes willful malice to infect a modern Windows install.

     

    @Monomelodies said:

    @morbiuswilters said:

    Seriously, people who think Linux would be more secure than Windows are delusional morons.
     

    People who don't see this is prevented in *nix by not having that $%^$#$# execute bit set by default don't really understand how permissions work. But you're forgiven. Seriously.


    That would depend completely on the mail client, just as it would on Windows.  A crappy mail client on Unix would simply execute any ELF file when you tried to open it.  Just like a crappy mail client on Windows would execute the exe.  Your point about extensions has been shot down repeatedly but you just keep trying to find some way to argue about it.  It's a user-education issue, and users can screw things up on any OS.  Finally, I have to wonder how many viruses are spread through accidental execution of binaries nowadays.  I'm assuming most are either embedded in untrusted apps that are deliberately executed (cracked games), or are spread through a hole in a network service or are spread through a hole in a library (e.g. a specially-crafted gif that overflows a buffer in the display library and executes arbitrary code).  Unix is no more immune to those than Windows is.  In fact, if you follow security alerts you'd know that the average desktop Linux install has more of these vulnerabilities, simply due to the large number of different applications, libraries and services that are installed.



  • @DrJokepu said:

    @alegr said:
    And FTP is pretty much forgotten anyway. Though Microsoft is still keeping ftp.microsoft.com for those backward customers.

    Off topic, but I still use FTP/SCP to upload stuff to my servers. Is that a WTF? Are there any better solutions out there?

    FTP is okay for the most part.  The data transfer is not encrypted and the login and password are sent in plaintext.  SCP and SFTP are built on top of SSH so they are generally much more secure, so long as you avoid anything built on top of the pile of fail known as Debian.  The problem with these is that they tend to be kind of slow and can be a PITA to resume.  Personally, I would recommend rsync.  You can tunnel it over ssh so it is just as secure as SCP/SFTP, but it is a hell of a lot faster.  Also, it does incremental copies so you can point it at a directory and have only the modified files copied, instead of copying the entire directory.  It's also great for interrupted connections with lots of files, because its incremental nature means it will resume with the last file copied instead of trying to re-copy everything.  The downside of rsync is that it may not be installed by default on your machine and it can be a bit of a tart if you aren't used to it. 



  • @D-Coder said:

    @DrJokepu said:

    @Monomelodies said:
    TRWTF of course being that extensions are considered important - they're just an indication at best.

    I am sure you know that in the CP/M - DOS - WINDOWS environment, extensions are important. I mean, they are meant to be important.
     

    Extensions go back to the Dark Ages. They certainly existed on TOPS-10 in the 1970s. Probably well before that, but that's the limit that I can personally attest to.

    I can attest to the MVS line of mainframe OSes. OS/390 will create some files in the format:

    USRWTF1.SOMETNG.FILE1.TEXT

    where the last segment in the namespace is actually the "file type". At least you can play with this using the TSO command "edit file2", it'll say it can't find the file, then ask you for "type", which will be the appended extension on said file.

    This system adds more fun, as the OS/360, OS/390 and z/OS family uses the dots as part of the file namespace.

    I used to like how MacOS treats the file types, at least up to System 7 it's done with the 4-letter "creator ID" and "application ID" strings; plus files are split in two, having a "resource" section which is basically OS metadata, and the "data" section. This format seemed to have solved the "what type of file is this?" but at a cost: this metadata is not available in other OSes.

    Oh, and that tiny problem about not being able to edit the creator/application ID strings on that file, though I think ResEdit could do that.



  • @TwelveBaud said:

    Mac file types have been mentioned here before, but I'd like to point out one thing about them that makes them less than useful. Within Windows, you can change the type of a file just by changing the extension, which you can do if you can rename the file ... Mac on the other hand has up through System 8 no way to change the 4-character type and creator codes associated with the file built into the system itself, nor through System 7 was there an easy user-accessable way to change which application was associated with a particular set of type or creator codes. Which led to the interesting case of me not being able to preview the Web pages I created in HomeSite or PageMaker or whatever the hell crappy program it was in an actual browser like Mosaic or Navigator, because Apple Knew Better.

    This isn't one issue; it's several.

    There was plenty of highly publicised software for changing file types and creator codes if you ever needed to do it. Apple didn't make everything secret, they simply did a good job of keeping unnecessary clutter out of the way. Most people just want the file they saved to open back up in the same program as last time, and as long as the computer does that, they're happy. File extensions get in the way and cause confusion. The security problem of naked_pics.jpg.exe is "solved" by showing extensions, but that then makes file renaming awkward as (prior to Vista) you frequently end up losing the extension when typing a new name.

    Now, the problem of opening HTML pages is awkward because of the unique properties of plain text formats. The extension approach says to use unique extensions for all types, e.g. .c, .html, .py, .pl (Perl or Prolog) and so forth. These extensions have absolutely nothing in common and there's no easy way to determine that the files are all, in fact, pure text. You end up manually creating file associations for every new plain text file you end up encountering.

    The file type approach is to declare every single one as type TEXT, semantically. This means that any text editor will automatically accept any file because it knows that they're pure text. It does, however, mean that they can't have unique type icons if they're all given the same creator code, e.g. BBEdit. (Note that Mac OS didn't use a default icon for TEXT when the creator isn't recognised, which it should have done.)

    Same problem in Windows. To preserve sanity, it's best that every text extension be mapped to class TextDocument, such that they will all share the same, centrally managed set of contextual actions. Thus, they all have the same icon and you're back to relying on file extension. Winamp does this -- every music type recognised by Winamp has its extension mapped to Winamp.File, such that the only way to tell an MP3 from an XM from an Ogg is via the file extension. Windows sets icons by named file class, not by extension.

    There's no win here. Apple's UTI is the best approach I've seen so far to really getting a grip on this problem but it still needs plenty of shell support to get it right.



  • @TwelveBaud said:

    @Aaron said:
    Examples?
    Shell extension handlers. (Which are responsible for what DaveK sees, though he doesn't know the name or where to find them.)
     

    I
    took the foolish risk of assuming sufficient intelligence on the part
    of the reader that I didn't need to spell out the basics in words of
    one syllable.

    In that I was, of course, deeply mistaken.  I will try not to assume it of you again.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.