ClamAV get_unicode_name() off-by-one buffer overflow

2008.11.11
Credit: Moritz Jodeit
Risk: High
Local: Yes
Remote: No
CWE: CWE-119


CVSS Base Score: 9.3/10
Impact Subscore: 10/10
Exploitability Subscore: 8.6/10
Exploit range: Remote
Attack complexity: Medium
Authentication: No required
Confidentiality impact: Complete
Integrity impact: Complete
Availability impact: Complete

----------------------------------------------------------------- ClamAV get_unicode_name() off-by-one buffer overflow Copyright (c) 2008 Moritz Jodeit <moritz_at_jodeit&#46;org> (2008/11/08) ----------------------------------------------------------------- Application details: From http://www.clamav.net/: "Clam AntiVirus is an open source (GPL) anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail gateways. It provides a number of utilities including a flexible and scalable multi-threaded daemon, a command line scanner and advanced tool for automatic database updates. The core of the package is an anti-virus engine available in a form of shared library." Vulnerability description: ClamAV contains an off-by-one heap overflow vulnerability in the code responsible for parsing VBA project files. Successful exploitation could allow an attacker to execute arbitrary code with the privileges of the `clamd' process by sending an email with a prepared attachment. The vulnerability occurs inside the get_unicode_name() function in libclamav/vba_extract.c when a specific `name' buffer is passed to it. 101 static char * 102 get_unicode_name(const char *name, int size, int big_endian) 103 { 104 int i, increment; 105 char *newname, *ret; 106 107 if((name == NULL) || (*name == '\0') || (size <= 0)) 108 return NULL; 109 110 newname = (char *)cli_malloc(size * 7); First the `size' of the `name' buffer multiplied by 7 is used to allocate the destination buffer `newname'. When the `name' buffer only consists of characters matching some specific criteria [1] and `big_endian' is set, the following loop can write exactly 7 characters into the allocated destination buffer `newname' per character found in source buffer `name'. This effectively fills up the destination buffer completely. After the loop in line 143, the terminating NUL byte is written and overflows the allocated buffer on the heap. 143 *ret = '\0'; 144 145 /* Saves a lot of memory */ 146 ret = cli_realloc(newname, (ret - newname) + 1); 147 return ret ? ret : newname; 148 } [1] Every character matching the following condition results in 7 characters written to the destination buffer: (c & 0x80 || !isprint(c)) && (c >= 10 || c < 0) A VBA project file embedded inside an OLE2 office document send as an attachment can trigger the off-by-one. Vendor response: 2008/10/16 Initial report to vendor 2008/10/16 Vulnerability acknowledged by acab_at_clamav&#46;net 2008/11/03 Release of version 0.94.1 Vulnerable packages: All versions up to 0.94 are vulnerable. Version 0.94.1 fixes the problem.

References:

http://www.securityfocus.com/bid/32207
http://xforce.iss.net/xforce/xfdb/46462
http://www.securityfocus.com/archive/1/archive/1/498169/100/0/threaded
http://www.frsirt.com/english/advisories/2008/3085
http://sourceforge.net/project/shownotes.php?release_id=637952&amp;group_id=86638
http://secunia.com/advisories/32663
http://lists.grok.org.uk/pipermail/full-disclosure/2008-November/065530.html


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top