Get this Security+ CertiGuide for your own computer.
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Also available: 300-question Security+ practice test!
Get It Here!

Custom Search

Table Of Contents  CertiGuide to Security+
 9  Chapter 2:  Communication Security (Domain 2.0; 20%)
      9  2.3  The Web
           9  2.3.3  Instant Messaging

Previous Topic/Section
IM Software Flaws
Previous Page
Pages in Current Topic/Section
Next Page  Packet Sniffing
Next Topic/Section  8.3 Naming Conventions

Briefly, the term “8.3 naming convention” harkens back to the days of old, when MS-DOS only permitted filenames of the form AAAAAAAA.BBB (that is, up to 8 characters, followed by a period, followed by up to 3 more).

Later, Microsoft introduced long file names, but kept in Windows the ability to refer to each file by a short, or 8.3, name. For example, you might see a folder called “Program Files” on a Windows system. Its “8.3 name” is typically “PROGRA~1”. Windows knows how to translate from one name to the other, and will accept either name for that folder, when accessing it. Why? This is done to maintain compatibility with (the now nearly 10 years old) application programs which were written in the old 8.3 days, and only understand file names if they’re in the 8.3 format. The fact that some programs still truncate file names to fit this convention (particularly the suffix, the 3 characters), has occasionally been used by crackers to sneak by an access control rule, getting it to allow access to a file which should not be accessible by having the rule check for access to a file of one name (either the long or 8.3 name), and the actual access occur to the OTHER file, due to a bug in the program’s code.

Additionally, Windows files are not limited to containing a single “.” followed by a three-letter extension. A filename like “my.doc.exe” is perfectly legal. And this gives rise to another type of security issue which we covered briefly when discussing email-related vulnerabilities. Some programs start at the beginning of a filename, look for a dot, then take the next three characters as its extension, or file type. Why is this not good from a security standpoint? What if your mail program’s settings allow users to open files of type “doc” but not of type “exe”? Is a file named “my.doc.exe” going to be looked at as a .doc file or an .exe file, by the mail program, when checking to see if the user is allowed to open it? Or if the mail program is set to ask the user whether or not they want to open the file, with the email client ask the user if the file “my.doc.exe”, or just “my.doc”, should be opened? Generally, the only way to know for sure is to test it.

More than one Trojan horse has been distributed by not adhering to conventional naming, e.g., watchthisporn.jpg.exe etc.207 For instance, the infamous ILOVEYOU virus spread by claiming to contain an attachment whose name displayed in Outlook as LOVE-LETTER-FOR-YOU.txt.

In reality the attachment that millions of users opened was named LOVE-LETTER-FOR-YOU.txt.vbs, and when opened, it ran a script that propagated the virus. It’s also made its way onto the Kazaa file-sharing service, disguised as everything from videos to other executables208.

8.3 can be

The ways that Microsoft Windows and Windows applications sometimes treat filenames can lead to vulnerabilities. For example:

Some programs do not display the last three “extension” letters of files. Malicious users can take advantage of this to slip a dangerous file through defenses and encourage users to open a file whose true purpose is hidden.

The fact that data files can be known by multiple names, a full long name, and a shorter name modified to fit into the old 8.3 naming convention, can enable malicious users to through defenses which may have restricted access to a file under one of its names, but not the other209.





Previous Topic/Section
IM Software Flaws
Previous Page
Pages in Current Topic/Section
Next Page  Packet Sniffing
Next Topic/Section

If you find useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

CertiGuide for Security+ ( on
Version 1.0 - Version Date: November 15, 2004

Adapted with permission from a work created by Tcat Houser et al. Version Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.