Details about the Lnk vulnerability and the patch

Simulation
I have written a little code using Windows Shell for simulating the process of lnk file. My code load a crafted control panel shortcut file, then extract the icon location, so, dll is loaded and executed automatically.

HRESULT hRes;

UINT _flag;

int _add;

WCHAR wszTemp[MAX_PATH+1];

IShellLink* psl = NULL;

hRes = CoCreateInstance(     CLSID_ShellLink, NULL,

                CLSCTX_INPROC_SERVER,

IID_IShellLink, reinterpret_cast<void**>(&psl));

CComQIPtr<IPersistFile> ipPersistFile(psl);

CComQIPtr<IExtractIconW> iconex;

MultiByteToWideChar(CP_ACP, 0, "H:\\lnk.txt", -1, wszTemp, MAX_PATH);

hRes = ipPersistFile->Load(wszTemp, STGM_READ);

hRes = ipPersistFile->QueryInterface(IID_IExtractIconW, (void**)&iconex);

hRes = iconex->GetIconLocation(GIL_DEFAULTICON, _path, MAX_PATH, &_add, &_flag);

About the patch

With the normal exploitation cases (Explorer browse lnk files), Windows Shell calls to CExtractIcon:: GetIconLocationW () function, this function doesn't use LoadLibrary().

In the case of softwares using my above code, Windows Shell calls still to error function, CCtrlExtIconBase:: GetIconLocationW (), but MS add more a function, CControlPanelFolder:: _IsRegisteredCPLApplet (), which is responsible for checking the valid CPL path.

Interesting

Basically, MS has a good patch. However, there is a more exciting: if you click (double) on the crafted shortcut file, dll is loaded and executed. While, if it is a standard shortcut to dll file, this is not possible because dll is not exe.