Windows (all versions) Zero Day lnk vulnerability VERY serious


Recommended Posts

Probably not. As far as I can tell, you're describing something so vague and theoretical, without providing any examples or reference sources, that I'm not sure I understand how it translates to the real world.

1. Protected mode can be exploited. It's hard, but not impossible. The easiest way is to manipulate the window that prompts for access. This leads us onto number 2:

2. What hdood is trying to say is the protected mode in IE doesn't have a secure desktop, so anything can modify that window. Hence instead of it being a warning, it can simply be a little picture saying thanks for using IE or w/e

How can this translate to the real world?

Not sure, but one example I can think of would go like this:

1. Trojan makes you download files, PMIE window is redrawn to seem harmless. User clicks ok, files run with elevated privileges.

2. Trojan exploits a hole in IE, PMIE window is redrawn to seem harmless. User clicks ok, trojan now has elevated privileges.

Essentially protected mode has been defeated. At least thats what I understood from what hdood was saying, could be wrong so.

Link to comment
Share on other sites

One question though: Shouldn't all AV vendors have updated their definitions to detect/block this by now?

You would think so.

I mentioned it on the previous page ;):

And pretty much every AV that has access to MAPP has all the technical details they need to make a relatively good signature (I know f-secure, bitdefender, and kaspersky have all updated their signature databases in order to detect this)
Link to comment
Share on other sites

Can't an AV detect only detect the malware being installed by the exploit? I don't think they can detected the exploit it's self without installing something like what is in the free sophos' tool.

Link to comment
Share on other sites

Can't an AV detect only detect the malware being installed by the exploit? I don't think they can detected the exploit it's self without installing something like what is in the free sophos' tool.

Not necessarily.

Link to comment
Share on other sites

You can't infect anything with just a .lnk file though. You actually have to have an external executable to run.

Not exactly. The bug is in the Windows shell. As soon as Windows tries to view a maliciously crafted .LNK file, code in the file's icon data gets executed. This is why the fix that Microsoft released makes the icons on the desktop (the shortcuts not actual files as far as has been mentioned in the news) turn into white blank icons. The thing that the fix is doing is it is stopping the Windows Shell from trying to draw the icons because the bug exists in the drawing mechanism of the Windows Shell. If the Windows Shell was not buggy then yes "You can't infect anything with just a .lnk file."

Steve Gibson is not a credible source of anything. An icon (which is what favicon.ico is) is a very different thing from a shortcut (.lnk). An icon is a pure data file that simply contains raw bitmap/PNG data, and I don't see what that has to do with this vulnerability (which as far as I know is not in an image decoder).

As for Steve Gibson, he is primarily a programmer and works on security related projects and other stuff http://www.grc.com/resume.htm. Calling someone as "not a credible source of anything" is a stretch if you don't know them or what they have done.

Now going back to the Windows Shell. Both favicon.ico and .LNK are primarily Windows files. You would think that displaying icons on webpages is a standard thing but no it is not. It was first enabled by Internet Explorer (I think version 4) and then websites used it and then other browsers added this functionality. In Internet Explorer favicon.ico as has been mentioned in the news is delegated to the Windows Shell and the bug is there as I explained above.

Link to comment
Share on other sites

Not exactly. The bug is in the Windows shell. As soon as Windows tries to view a maliciously crafted .LNK file, code in the file's icon data gets executed. This is why the fix that Microsoft released makes the icons on the desktop (the shortcuts not actual files as far as has been mentioned in the news) turn into white blank icons. The thing that the fix is doing is it is stopping the Windows Shell from trying to draw the icons because the bug exists in the drawing mechanism of the Windows Shell. If the Windows Shell was not buggy then yes "You can't infect anything with just a .lnk file."

I don't think that's how it works. From what I gathered (and I haven't looked at it since it first made the news) the lnk file doesn't contain any code. The vulnerability is in control panel code. The icon section of a lnk file points to a resource in an external exe/dll file. When parsing the lnk files, Windows goes and loads the icon from this external file. Normally this is just read as data, but for control panels it will actually execute code in the dll. In this case, it ends up running malicious code. In other words, the bug is not in any of the icon functions in the shell. I am of course open to be shown otherwise, if you can show actual credible information.

As for Steve Gibson, he is primarily a programmer and works on security related projects and other stuff http://www.grc.com/resume.htm. Calling someone as "not a credible source of anything" is a stretch if you don't know them or what they have done.

I am very familiar with Gibson. That's why I wrote it. I wasn't just trying to be mean to a random person.

Now going back to the Windows Shell. Both favicon.ico and .LNK are primarily Windows files. You would think that displaying icons on webpages is a standard thing but no it is not. It was first enabled by Internet Explorer (I think version 4) and then websites used it and then other browsers added this functionality. In Internet Explorer favicon.ico as has been mentioned in the news is delegated to the Windows Shell and the bug is there as I explained above.

Yes, they are both Windows formats, but an .ico file is just raw data, and is a completely unrelated format to .lnk. Since the bug does not appear to be in any of the code that actually processes the icon data itself, it shouldn't affect .ico files.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.