Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=818
Symantec attempts to clean or remove components from archives or other multipart containers that they detect as malicious. The code that they use to remove components from MIME encoded messages in CMIMEParser::UpdateHeader() assumes that filenames cannot be longer than 77 characters.
This assumption is obviously incorrect, names can be any length, resulting in a very clean heap overflow.
The heap overflow occurs because Symantec does the cleaning in multiple stages, first changing the Content-Type to "text/plain", then changing the filename to "DELETED.TXT". The problem is that during the first stage of this process, they maintain the existing name but use a buffer prepared for the final name.
Something like:
char *buf = malloc(strlen(NewContentType) + strlen(LengthOfNewEncodedFilename) + 100)
// First change the content-type
strcpy(buf, "Content-Type: ");
strcpy(buf, NewContentType;
strcpy(buf, "; name=\"");
strcpy(buf, OldFileName);
...
UpdateName(buf, NewFileName);
...
This obviously won't work, because it doesn't verify that the old name will fit. I've attached an example MIME message that triggers this code in Symantec Scan Engine.
Proof of Concept:
https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/40034.zipData
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation