NOD32 Antivirus Long Path Name Stack Overflow Vulnerabilities I - DESCRIPTION NOD32 Antivirus is vulnerable to two stack overflow vulnerabilitie. The vulnerabilities can be exploited when the AV tries to delete/disinfect or rename a detected malware in a specially formated directory. These vulnerabilities can lead to local/remote arbitrary code execution. II - DISCLOSURE TIMELINE 19/04/2007 - First Vulnerability reported to ESET 19/04/2007 - ESET Response 20/04/2007 - Vulnerability Analysis and PoC sent to ESET 20/04/2007 - ESET initial feedback 24/04/2007 - Confirmed the bug and fixed 07/05/2007 - ESET made available the updates 10/05/2007 - A second vulnerability was founded and reported to ESET with a PoC an analysis 10/05/2007 - ESET response, Confirmed the bug and fixed 15/05/2007 - ESET made available the updates 19/05/2007 - Coordinated public disclosure III - AFFECTED PRODUCTS NOD32 Antivirus v2.7 (Versions prior to the update 2.70.37.0) IV - ADVANCED DESCRIPTION NOD32 is vulnerable to a simple stack overflow vulnerability. The vulnerability can be exploited when the AV tries to delete/disinfect a detected malware. If the the full path size to the malware (filename included) has a long size, an stack variable is overflowed allowing the overwriting of the ret address. The vulnerability can be localy or remotely exploitable. The local threat is very interesting, because could allow a detected malware to never been disinfected allowing the local execution of a shellcode (for example: whenever the AV include a signature for the malware and the AV tries to delete/disinfect it, the vulnerability will be exploited allowing, for example, the execution of a shellcode to update (download) to a new malware variant. By this way the malware will be always up to date and never disinfected. Remote exploit is possible via network shared folders. If a local network shared is remotely analyzed the vulnerability can be abused to execute arbitrary commands in the remote system. The vulnerable function is: .text:004296D0 ; int __cdecl sub_4296D0(int,wchar_t *,int) .text:004296D0 sub_4296D0 proc near ; CODE XREF: sub_429950+27p .text:004296D0 ; sub_429950+192_p ... .text:004296D0 .text:004296D0 var_210 = dword ptr -210h .text:004296D0 var_20C = dword ptr -20Ch .text:004296D0 var_208 = word ptr -208h .text:004296D0 arg_0 = dword ptr 4 ; Unicode String (Path to malware) ; (\??\c:\malwarePath\malwarefile) .text:004296D0 arg_4 = dword ptr 8 ; Size MAX_PATH=0x104 (260) .text:004296D0 arg_8 = dword ptr 0Ch And the vulnerable code is: Search for a 0x5c ('\') in the string, to match if it's a directory or a file: .text:00429890 6A 5C push 5Ch ; wchar_t .text:00429892 56 push esi ; wchar_t * .text:00429893 FF 15 B8 F6 43 00 call ds:wcschr Jump if the string is found (It's a directory), continue otherwise (it's a file). A wsccat is made to concatenate the directory path name string with the file name string, nevertheless the concatenation is made without a size check: .text:00429899 8B F8 mov edi, eax .text:0042989B 83 C4 18 add esp, 18h .text:0042989E 85 FF test edi, edi .text:004298A0 75 0D jnz short loc_4298AF .text:004298A2 8D 54 24 18 lea edx, [esp+220h+var_208] .text:004298A6 56 push esi ; wchar_t * ; Ptr to filename .text:004298A7 52 push edx ; wchar_t * ; Ptr to path string .text:004298A8 FF D5 call ebp ; wcscat ; A call to wcscat is made without a previous ; size check to verify if the final string ; overflow the stack variable ; Here we can overwrite the ret address Although the vulnerability is hard to exploit, it's not impossible. These are the restrictions to bypass: - The path is in Unicode format. So we have to find a call esp or similar code whith an unicode format - The shellcode has to be in the path name. We have to use an Alphanumeric shellcode V - EXPLOITATION A PoC has been developed to probe the vulnerability, but it's not going to be publicly available. It has been only shared with ESET. Although the vulnerabilities are hard to exploit, it's not impossible. There are some restrictions to bypass: - The path name is formated in Unicode, so we have to find an opcode in an address with an unicode format - The shellcode has to be in the path name so we have to use an Alphanumeric shellcode VI - SOLUTION The vulnerabilities was reported on April 19 and on May 10. An update has been issued on May 18 to solve these vulnerabilities through the regular update mechanism. VII - CREDIT Bug found by Ismael Briones [http://www.inkatel.com]