New (but really - old) Windows .lnk vulnerability
in [Viruses]
|
Prev: Anti-Virus Best one
Next: Win32/RAMNIT.A Anyone?
From: Ant on 22 Jul 2010 10:45 "Virus Guy" wrote: > Ant wrote: >> I've now tested it on NT 4.0 (where it works) and Win 95 (where it >> doesn't). Double-clicking on the shortcut launches control panel >> on 95 but still won't run the DLL. > > Same for Win-98se. Ok. If I can find a spare hard disk I might check Win ME. > According to an MSDN article by Microsoft , Win-9x/me shortcut (lnk) > files use ansi coding for the target filespec, but NT-based systems use > unicode. You're misreading that. The A and W endings you see on many API functions are to do with the encoding of any string parameters they might have, not the data manipulated by them. In general, Win 9x only supports the ANSI (A) version of any Windows API routine unless you install unicode support. > This means there are two slightly different forms for lnk > files. There are, but but not because of the above. The .lnk format has optional structures and also a flag indicating which type of strings are present. > My experimentation today on win-98 and XP-sp3 systems tells me that > *both* systems understand and are compatible with *both* types of lnk > files, but win-98 natively creates ansi-coded lnk files, while XP > creates unicode files. I think you may find the STRING_DATA structues are absent or the IsUnicode bit is not set in 9x shortcuts. > The exploit is created by performing some minimal editing of .lnk files > that point to a DLL file that must be present in the root directory of a > named drive. Relational paths don't seem to work. [...] I get the impression from the rest of your post that you're quoting or paraphrasing some webpage. From where, exactly?
From: Virus Guy on 22 Jul 2010 17:59 Ant wrote: > >> Double-clicking on the shortcut launches control panel > >> on 95 but still won't run the DLL. > > > > Same for Win-98se. > > Ok. If I can find a spare hard disk I might check Win ME. Won't matter. The malformed .lnk file (as published) doesn't work on 9x/ME. > > According to an MSDN article by Microsoft , Win-9x/me shortcut > > (lnk) files use ansi coding for the target filespec, but NT-based > > systems use unicode. > > You're misreading that. No I'm not. > The A and W endings you see on many API functions are to do > with the encoding of any string parameters they might have > not the data manipulated by them. We are not talking about "many API functions". I made a correct statement about how the filespec is coded in shortcut files as created by win-9x/me vs NT. > In general, Win 9x only supports the ANSI (A) version of any > Windows API routine unless you install unicode support. In general, Win-9x/me is (was) designed to handle string structures coded in ANSI, while NT was coded to handle both ANSI and Unicode (double-byte). Some east-asian versions of 9x can natively handle double-byte strings (but technically these are not unicode strings). In late 2001, Microsoft released Unicode support for win-9x/me, which I believe is implimented in unicows.dll. > > This means there are two slightly different forms for lnk > > files. > > There are, but but not because of the above. The .lnk format has > optional structures and also a flag indicating which type of > strings are present. If you create a shortcut under XP and compare it to a shortcut created under 9x, you'll see that apart from the "IsUnicode" flag and perhaps one other attribute byte, the only difference will be the coding of the target filespec. I did not say that the only difference between the two versions was unicode vs ansi target coding, but it is A major difference. > > My experimentation today on win-98 and XP-sp3 systems tells > > me that *both* systems understand and are compatible with > > *both* types of lnk files, but win-98 natively creates ansi- > > coded lnk files, while XP creates unicode files. > > I think you may find the STRING_DATA structues are absent If the target filespec is contained in a STRING_DATA structure in a shortcut file, then how can you say that such a structure could be absent from a shortcut file? > or the IsUnicode bit is not set in 9x shortcuts. Naturally that bit is not set in 9x shortcuts. That's how you know the target filespec is ANSI-coded. And by the way, 9x/me can still handle unicode (or "NT-style") shortcuts just fine. > I get the impression from the rest of your post that you're > quoting or paraphrasing some webpage. From where, exactly? From my own testing and investigation.
From: FromTheRafters on 22 Jul 2010 18:59 "Virus Guy" <Virus(a)Guy.com> wrote in message news:4C48BF4A.796862FA(a)Guy.com... > Ant wrote: >> Ok. If I can find a spare hard disk I might check Win ME. > > Won't matter. The malformed .lnk file (as published) doesn't work on > 9x/ME. I'm reasonably sure that Ant is capable of otherwise "porting" it for Win ME to test for himself whether or not there is an exploitable vulnerability in ME's shell.
From: Virus Guy on 22 Jul 2010 19:17 FromTheRafters wrote: > >> Ok. If I can find a spare hard disk I might check Win ME. > > > > Won't matter. The malformed .lnk file (as published) doesn't work > > on 9x/ME. > > I'm reasonably sure that Ant is capable of otherwise "porting" it > for Win ME to test for himself I didn't say he wasn't capable. I'm saying that there isin't enough of a difference in ME's shell compared to win-98se that would make it vulnerable to this exploit.
From: Ant on 23 Jul 2010 00:56
"Virus Guy" wrote: > Ant wrote: >>> According to an MSDN article by Microsoft , Win-9x/me shortcut >>> (lnk) files use ansi coding for the target filespec, but NT-based >>> systems use unicode. >> >> You're misreading that. > > No I'm not. If you're referring to this... "The IShellLink interface has an ANSI version (IShellLinkA) and a Unicode version (IShellLinkW). The version that will be used depends on whether you compile for ANSI or Unicode. However, Windows 95 and Windows 98 only support IShellLinkA" then that's not about the content or naming of shortcuts. It's about the way the API is used. >> The A and W endings you see on many API functions are to do >> with the encoding of any string parameters they might have >> not the data manipulated by them. > > We are not talking about "many API functions". The same should apply to IShellLink. However... > I made a correct statement about how the filespec is coded in shortcut > files as created by win-9x/me vs NT. It's true that 9x uses ANSI inside shortcuts (at least, for English language versions) and NT uses unicode, and maybe there really is a difference between using IShellLinkA or IShellLinkW on NT. Does using IShellLinkA produce ANSI encoding in NT shortcuts? That would be unusual since MS say in their latest specification that the unicode flag in shortcuts should be set. Which version of the API you use (normally automatic because an A or W suffix is typically not added by the programmer) should have no bearing on the file format but there's always exceptions that "prove the rule" and it's an interesting point with regard to lnk files. > In late 2001, Microsoft released Unicode support for win-9x/me, which I > believe is implimented in unicows.dll. Yes, unicows. For a while, I wondered about the purpose of that bovine-sounding filename. Does that mean 9x is capable of producing lnk files containing unicode? > If you create a shortcut under XP and compare it to a shortcut created > under 9x, you'll see that apart from the "IsUnicode" flag and perhaps > one other attribute byte, the only difference will be the coding of the > target filespec. I checked again and the unicode bit is not set on Win 95 but all other flag bits are the same. However, the unicode/ANSI differences will be in the LinkInfo structure (original location info) and/or the StringData fields. The actual path to the target is specified in the LinkTargetIDList before that; most of which is unreadable apart from the ANSI filename (long and/or short form). > I did not say that the only difference between the two versions was > unicode vs ansi target coding, but it is A major difference. The other major difference appears to be in the elements of the LinkTargetIDList. This is private to the shell and, while its structure is documented, the meaning of each field is not. I suspect it may depend on the MS COM or Windows version. The first element is a CLSID which should represent the root of the shell namespace. This is the structure exploited in the attacks. >> I think you may find the STRING_DATA structues are absent > > If the target filespec is contained in a STRING_DATA structure in a > shortcut file, then how can you say that such a structure could be > absent from a shortcut file? The structure turns out to be present in both types but seems to be more about conveying user interface information. The ID list is the important one. > And by the way, 9x/me can still handle unicode (or "NT-style") shortcuts > just fine. There's probably enough redundancy in the format that allows it to resolve potential incompatabilities. >> I get the impression from the rest of your post that you're >> quoting or paraphrasing some webpage. From where, exactly? > > From my own testing and investigation. Ok, then I'll address these points. > The exploit is created by performing some minimal editing of .lnk files > that point to a DLL file that must be present in the root directory of a > named drive. Relational paths don't seem to work. My tests worked with a DLL in one subdirectory and a link in another. > ... multiple copies of the .lnk file would be present - > because there is no way to know before-hand if the flash drive is drive > d: or e: or f: (etc) on a given system. The exploits didn't need to know that. They used a couple of possible device names they knew would be assigned: "\\.\STORAGE#Volume#_??_USBSTOR# [...] \~WTR4141.tmp" "\\.\STORAGE#RemovableMedia# [...] \~WTR4141.tmp" This should also work for fixed disks, e.g. harddisk\DR0 or similar, for the first hard disk. |