Symantec Antivirus Heap Overflow Modifying MIME Messages

2016.06.30
Risk: High
Local: Yes
Remote: No
CWE: CWE-20


Ogólna skala CVSS: 10/10
Znaczenie: 10/10
Łatwość wykorzystania: 10/10
Wymagany dostęp: Zdalny
Złożoność ataku: Niska
Autoryzacja: Nie wymagana
Wpływ na poufność: Pełny
Wpływ na integralność: Pełny
Wpływ na dostępność: Pełny

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. More: https://bugs.chromium.org/p/project-zero/issues/detail?id=818

Referencje:

https://bugs.chromium.org/p/project-zero/issues/detail?id=818


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