0day.today - Größte Exploit-Datenbank der Welt.
![](/img/logo_green.jpg)
Wir benutzen eine Hauptdomain DOMAIN_LINK
Wenn Du den Exploit kaufen, oder für einen Service bezahlen möchtest, musst Du Gold kaufen. Wir wollen nicht, dass Du unsere Seite als ein Werkzeug für Aktivitäten wie Hacking verwendest. Illegale Aktionen, die andere Benutzer oder Webseiten betreffen, für die Du keine Zugriffsrechte hast, führen dazu, dass der Account gebannt und alle Daten von diesem unwiderruflich gelöscht werden.
Die Administratoren dieser Seite benutzen nur die offiziellen Kontaktdaten. Achte auf Betrüger!
![We DO NOT use Telegram or any messengers / social networks!](/img/no_telegram_big.png)
Please, beware of scammers!
- Lies [ Vereinbarung ]
- Lies [ Senden ] Regeln
- Besuche [ FAQ ] page
- [ Registrieren ] Profil
- Bekommen [ GOLD ]
- Wenn Du möchtest [ Verkaufen ]
- Wenn Du möchtest [ Kaufen ]
- Wenn Du vergessen hast [ Account ]
- Fragen [ [email protected] ]
- Anmeldungsseite
- Registrierungsseite
- Seite für Accountwiederherstellung
- FAQ Seite
- Kontakt
- Regeln für Veröffentlichungen
- Vereinbarungsseite
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Symantec AntiVirus - Heap Overflow Modifying MIME Messages
Autor
Risiko
![](/img/risk/critlow_2.gif)
Security Risk Medium
]0day-ID
Kategorie
Datum hinzufügen
CVE
Betriebssystem
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/exploit-database-bin-sploits/raw/master/sploits/40034.zip # 0day.today [2024-07-16] #