Date: Thu, 21 Feb 2002 08:08:27 -0600
From: Sym Security <symsecurity@symantec.com.>
To: [email protected]Subject: Symantec Enterprise Firewall (SEF) SMTP proxy inconsistencies
On 02/20/2002, Martin O'Neal of Corsaire Ltd. posted:
-- Corsaire Limited Security Advisory --
Title: Symantec Enterprise Firewall (SEF) SMTP proxy inconsistencies
Date: 18.01.02
Application: Symantec Enterprise Firewall (SEF) 6.5.x
Environment: WinNT, Win2000
Author: Martin O'Neal [[email protected]]
Audience: General distribution
-- Scope --
The aim of this document is to clearly define some issues related to
a some SMTP proxy inconsistencies within the Symantec Enterprise
Firewall (SEF) environment as provided by Symantec [1].
-- History --
Vendor notified: 18.01.02
Document released: 21.02.02
-- Overview --
The SEF firewall product uses an application proxy strategy to provide
enhanced security features for a variety of common protocols. For the
SMTP proxy, part of this additional functionality allows the firewall
to restrict the sender / recipient domains and to hide internal
infrastructure information from external recipients.
However, when the firewall is configured to provide network address
translation (NAT) to an SMTP connection (effectively hiding the internal
server behind a publicly routable address), this might not always be
conducted as desired.
---------------------------snip-
Symantec Security Response Advisory
15 February, 2002
Symantec Enterprise Firewall SMTP Proxy Issues
Reference
Corsaire Limited Security Advisory 020118-001a.txt
Risk Impact
Low
Affected Components
Symantec Enterprise Firewall versions 6.5.x and 7.0
Overview
Corsaire Limited has discovered two low-risk issues with Symantec
Enterprise Firewall. The first is a potential information leak in the
Symantec Enterprise Firewall Simple Mail Transfer Protocol (SMTP) proxy
environment that could provide inappropriate information on the firewall
configuration. The second is that inconsistencies in the SMTP protocol
exchange could cause a connection to be denied.
Details
Corsaire Limited notified Symantec Corporation of some issues in the way
the Symantec Enterprise Firewall SMTP proxy worked with network address
translation (NAT). These issues could cause some undesirable results.
Symantec Enterprise Firewall uses application proxies to provide enhanced
security. Uses of this feature include restricting the sender/recipient
domains and hiding internal infrastructure information from external users.
Corsaire Limited discovered that when Symantec Enterprise Firewall is
configured to provide NAT to an SMTP connection, the function to hide the
internal server address by mapping it to an external public address is not
performed in a completely desirable manner.
The Symantec Enterprise Firewall SMTP proxy should analyze the SMTP format
and dynamically change the IP address as well as edit the required IP
header. Corsaire Limited's research demonstrated that when the inbound or
outbound SMTP connection was translated to an address other than the
address assigned to the physical firewall interface, the SMTP proxy
continued to use the name and address of the physical interface in the SMTP
protocol exchange.
There are two low-risk issues with the way Symantec Enterprise Firewall is
handling the SMTP proxy interface. First, there is a potential information
leak. Information is included in the SMTP protocol exchange that could,
possibly, aid a malicious intruder in analyzing the firewall configuration.
Second, a receiving/transmitting host that is configured to enforce strict
checks on the SMTP protocol exchange may not accept the connection due to
inconsistencies in the field. This could result in the nondelivery or
bouncing of mail messages.
Symantec Response
Symantec has verified the issues discovered by Corsaire Limited and
developed a fix that will be included with the near-future release of
Symantec Enterprise Firewall version 8.0. Until then, use the following
workarounds to address these issues:
* Configure Symantec Enterprise Firewall to use the same name for the
firewall name and the firewall external interface name. This workaround
results in consistent names for SMTP replies.
* If NAT is not needed, use the SMTP wizard included with Symantec
Enterprise Firewall to set up rules and redirects for all inbound and
outbound SMTP traffic.
Credit
Symantec takes the security of its products very seriously. Symantec
appreciates the coordination of Martin O'Neal and Corsaire Limited in
identifying and providing technical details of potential areas of concern
so it can quickly address the issue. Anyone with information on security
issues with Symantec products should contact [email protected].
This advisory can be viewed at
http://securityresponse.symantec.com/avcenter/security/Content/2002.02.20.html
Copyright (c) 2001 by Symantec Corp.
Permission to redistribute this Advisory electronically is granted as long
as it is not edited in any way unless authorized by Symantec Security
Response. Reprinting the whole or part of this Advisory in a medium other
than electronically requires permission from Sym [email protected].
Disclaimer
The information in the advisory is believed to be accurate at the time of
printing based on currently available information. Use of the information
constitutes acceptance for use in an AS IS condition. There are no
warranties with regard to this information. Neither the author nor the
publisher accepts any liability for any direct, indirect or consequential
loss or damage arising from use of, or reliance on this information.
Symantec, Symantec Security Response, Symantec product names and Sym
Security are Registered Trademarks of Symantec Corp. and/or affiliated
companies in the United States and other countries. All other registered
and unregistered trademarks represented in this document are the sole
property of their respective companies/owners.
Symantec Security Response
[email protected]
http://securityresponse.symantec.com
