|
|
|
|
| |
Credit:
The information has been provided by Virtual Security Research.
The original article can be found at:
http://www.vsecurity.com/bulletins/advisories/2007/afflib-overflows.txt
|
| |
Vulnerable Systems:
* AFF version 2.2.0.
Immune Systems:
* All identified overflows were fixed in version 2.2.6.
Multiple buffer overflows were found in AFFLIB(TM) which could allow an attacker to create a denial-of-service condition against a forensics examiner, or possibly to execute arbitrary code on the behalf of a victim. One such overflow may be triggered remotely and may be relatively easy to exploit. The other overflows identified appear to have medium to low severity, due to the low likelihood of an attacker having the ability to influence the vulnerable operations, at least in the typical use case scenarios. However, because AFFLIB(TM) is in part a library, other applications may utilize it in unanticipated ways, which may expose these attack vectors.
Remote Stack-based Buffer Overflow Through Use of LastModified:
File: lib/s3.cpp
Line: 113
The LastModified string is copied to a fixed-length buffer using strcpy(3), but no length checking is apparently done when it is originally read from an XML response. This could allow a malicious Amazon S3 server or a man-in-the-middle to execute code on the S3 client system. (See [2] for more details on the Amazon S3 protocol.) Lines
111-115 illustrate the problem:
/* Make date nice */
char tstamp[64];
strcpy(tstamp,(*i)->LastModified.c_str());
tstamp[10] = ' ';
tstamp[19] = '\000';
Note that the (*i)->LastModified string is drawn directly from an XML response in the endElement() callback function (lines 173-178 of lib/s3_glue.cpp):
case 3:
if(!strcmp(name,"Key")){ einfo->lbr->contents.back()->Key = einfo->cbuf; break;}
if(!strcmp(name,"LastModified")){einfo->lbr->contents.back()->LastModified = einfo->cbuf;break;}
if(!strcmp(name,"ETag")){ einfo->lbr->contents.back()->ETag = einfo->cbuf;break;}
if(!strcmp(name,"Size")){ einfo->lbr->contents.back()->Size = atoi(einfo->cbuf.c_str());break;}
break;
An exploit of this would require that users decide to run the s3 binary program against an untrustworthy S3 server, or an attacker were able to conduct impersonation or man-in-the-middle attacks against the communications between the user and a valid S3 server. Since the s3 binary uses non-SSL HTTP connections by default, this may not be difficult.
Stack-based Buffer Overflows in S3 URL Parsing:
File: lib/vnode_s3.cpp
Lines: 80 & 81
A portion of a potentially untrustworthy parameter is copied into a buffer without sufficient length checking in a memcpy() call, which writes to a stack-based buffer. If this function receives URLs from an untrusted source, code execution would be a major risk. Lines 66-81 are included below for illustration:
/* Separate out the bucket and the path */
const char *fn = af_filename(af);
regex_t re;
if(regcomp(&re,"^s3://([^/]*)/(.*)$",REG_EXTENDED)){
err(1,"regcomp");
}
regmatch_t match[3];
memset(match,0,sizeof(match));
if(regexec(&re,fn,3,match,0)!=0){
return -1; // can't parse URL; must not be a match
}
char bucket[1024]; memset(bucket,0,sizeof(bucket));
char path[1024]; memset(path,0,sizeof(path));
memcpy(bucket,fn+match[1].rm_so,match[1].rm_eo-match[1].rm_so);
memcpy(path,fn+match[2].rm_so,match[2].rm_eo-match[2].rm_so);
The overflow occurs because the length specified to memcpy() is the length of the regular expression match, without regard to the size of the path buffer. This may be exploitable in scenarios where an attacker could pass command line parameters to a privileged aimage program, or via a program written by a third-party developer.
Stack-based Buffer Overflow in libewf Vnode Wrapper:
File: lib/vnode_ewf.cpp
Line: 70
A potentially untrustworthy parameter is used without length checking in a strcpy() call which writes to a stack-based buffer. If this command receives parameters from an untrusted source, code execution would be a major risk. Lines 59-70 are included to illustrate the problem:
static int ewf_open(AFFILE *af)
{
if(strchr(af->fname,'.')==0) return -1; // need a '.' in the filename
/* See how many files there are to open */
char **files = (char **)malloc(sizeof(char *));
int nfiles = 1;
files[0] = strdup(af->fname);
char fname[MAXPATHLEN+1];
strcpy(fname,af->fname);
An overflow could occur because the af->fname string is provided by the user, and is not limited to MAXPATHLEN. An attacker could use this in scenarios where a 3rd-party program incorporates AFFLIB(TM) into their program (which ultimately accepts file names from an untrusted source) or in situations where an AFFLIB(TM) binary is setuid/setgid or is executed remotely web applications.
Stack-based Buffer Overflow in AFD Vnode Wrapper:
File: lib/vnode_afd.cpp
Line: 405
A potentially untrustworthy parameter is used without length checking in a strcpy() call which writes to a stack-based buffer. If this command receives parameters from an untrusted source, code execution would be a major risk.
Lines 402-412 are included below for illustration:
while ((dp = readdir(dirp)) != NULL){
if (last4_is_aff(dp->d_name)){
char path[MAXPATHLEN+1];
strcpy(path,af->fname);
strlcat(path,"/",sizeof(path));
strlcat(path,dp->d_name,sizeof(path));
if(afd_add_file(af,path)){
return -1;
}
}
}
The overflow would occur if a value for af->fname were specified by a user which was larger than 1025 bytes. This is certainly plausible, since many systems allow pathnames to be as large as 4096 bytes. As this is part of the core AFFLIB(TM), it could be exploited in 3rd party programs which include AFFLIB(TM) support, if an attacker were allowed to specify filenames. In addition, it could be exploited if any AFFLIB(TM) binary were setuid/setgid, or if these programs were executed from a CGI script or similar remote connection.
Vendor Response:
Simson Garfinkel was first contacted on 2007-03-31. The following timeline outlines the responses from the vendor regarding this issue:
Disclosure Timeline:
* 2007-04-01 - Vendor provided details of all vulnerabilities identified.
* 2007-04-03 - Continued vendor communication.
* 2007-04-05 - Vendor released version 2.2.6, containing multiple security fixes.
* 2007-04-06 - Vendor notified VSR that fixes were released.
* 2007-04-09 - VSR notified vendor that 9 vulnerability instances still remained in latest release.
* 2007-04-12 - Vendor confirmed that remaining vulnerabilities would be fixed in next release.
* 2007-04-25 - Vendor released versions 2.2.7 and 2.2.8. Vendor did not notify VSR.
* 2007-04-27 - VSR discovered new versions were released. VSR inspected version 2.2.8 and found that no additional vulnerabilities were fixed. VSR advisories published.
Recommendation:
AFFLIB(TM) users should upgrade to the newest version. Third-party projects which rely on AFFLIB(TM) should encourage users to upgrade, and/or incorporate fixes into their distribution of the library.
The update is available via:
http://www.afflib.org/downloads/
CVE Information:
CVE-2007-2053
|
|
|
|
|
