* TrendMicro's VirusWall version 3.52 build 1375 (or any other build prior to 1462)
* TrendMicro's VirusWall v3.7 build 1070 on Solaris
* TrendMicro's VirusWall version 3.52 build 1462
* TrendMicro's VirusWall version 5.1 (Allows stopping of malformed emails, not enabled by default)
Conforming to the RFC standard regarding email attachments has been proven in the past to be a two-way sword, where both the email gateway (server) and the receiving email software (client) need to comply to the same rules or problems will arise.
Since some degree of incompatibility is expected, it should be handled correctly (i.e. notifying the user, or not allowing him to open the attachment).
A new way for Viruses to bypass TrendMicro's VirusWall occurs due to the different way Outlook Express (in our test case) handles attachments and the way TrendMicro's VirusWall looks for attachments in emails it handles.
The vulnerability itself is referred to as a Space Gap, since it revolves around the issue of adding additional spaces into the normal attachment standard, causing VirusWall to ignore the attachment, while Outlook Express does not.
Any of the following email modifications will allow bypassing of VirusWall, while Outlook Express will open the email's attachment without problem:
1) Replace "Content-Type:" with "Content-Type :"
2) Replace "Content-Transfer-Encoding:" with "Content-Transfer-Encoding :"
3) Replace ' boundary="----=_NextPart_000_000E_01C2100B.F369D840"' with 'boundary=----=_NextPart_000_000E_01C2100B.F369D840 '
4) Replace ' boundary="----=_NextPart_000_000E_01C2100B.F369D840"' with 'boundary= ----=_NextPart_000_000E_01C2100B.F369D840'
(NOTE: Some emails have more than one, Content-Type or Content-Transfer-Encoding keyword, it is important to modify that of the attachment)
As you can see all the above modification revolve around adding one or more spaces into key sections that both Outlook Express and VirusWall look for. The product is a malformed email that is not RFC compliant. However, while VirusWall is restrictive with the way it handles such malformed emails, Outlook Express isn't.
We have informed the vendor on the June 10, 2002 via email@example.com and have received a prompted response. A case ID was assigned, TDSC-0D711F00. Initial contact was a little hectic, where the vendor was unable to verify the vulnerability.
On June 19, 2002 they were able to recreate the issue, and their development team was notified.
On June 28, 2002 they released a patch (build 1462) that resolves the issue. However, they are not planning to release an advisory of their own.