COMMAND

	Symantec Enterprise Firewall SMTP proxy inconsistencies

SYSTEMS AFFECTED

	Symantec Enterprise Firewall (SEF) 6.5.x

PROBLEM

	Martin  O\'Neal  found  following,  as  published  in  Corsaire  Limited
	Security Advisory [http://www.corsaire.com]:
	

	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
	[http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=47&PID=9674250&EID=0]
	

	

	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.
	

	

	 -- Analysis --

	

	The SMTP proxy  works  by  analysing  the  SMTP  format  and  optionally
	rewriting some of the headers to achieve the desired aim.
	

	When an inbound or outbound SMTP  connection  is  NATed  to  an  address
	other than the one assigned to the  physical  firewall  interface,  then
	the SMTP proxy still  uses  the  physical  interface  name  and  address
	within the SMTP protocol exchange.
	

	This has two potential issues:
	

	The first issue is that there  is  now  a  potential  information  leak;
	additional information is contained within the  SMTP  protocol  exchange
	that could aid an attacker in analysing the firewall configuration.
	

	The  second  issue  is  that  any  receiving  /  sending  host  that  is
	configured to enforce strict  checks  on  the  SMTP  protocol  exchange,
	might not accept the  connection  due  to  the  inconsistencies  in  the
	fields.
	

	

	 -- Proof of concept --

	

	To reproduce this issue, place an SMTP host on an internal interface  of
	the SEF firewall.  Create  a  rule  that  allows  inbound  and  outbound
	traffic to this
	

	host, then create an address  translation  and  redirection  entry  that
	maps SMTP connections to and from an external  address  other  than  the
	physical interface address.
	

	

	smtp address (internal)                1.1.1.1 (twist.dance.org)

	firewall address (external physical)   2.2.2.2 (waltz.dance.org)

	firewall address (external SMTP NAT)   2.2.2.254 (foxtrot.dance.org)

	firewall name                          tango

	firewall domain                        dance.org

	

	redirect                               2.2.2.254 -> 1.1.1.1 (for SMTP only)

	NAT                                    1.1.1.1 -> any (use 2.2.2.254)

	NAT                                    any -> 1.1.1.1 (use client address)

	rule                                   1.1.1.1 -> any (for SMTP only)

	rule                                   any -> 1.1.1.1 (for SMTP only)

	

	

	For inbound connections to 2.2.2.254:
	

	-> 220 tango.dance.org Generic SMTP handler

	

	

	For outbound connections from 2.2.2.254:
	

	<- 220 ...

	-> HELO waltz.dance.org

	<- 250 ... talking to foxtrot.dance.org ([2.2.2.254])

	

	

	

	

SOLUTION

	Accordingly     with     Symantec\'s      answer,      available      at
	http://securityresponse.symantec.com/avcenter/security/Content/2002.02.20.html
	:
	

	 Solution

	 ========

	

	Bug will be corrected in near-future release version 8
	

	

	 Workarounds

	 ===========

	

	- Configure Symantec Enterprise Firewall to use the same  name  for  the
	firewall name and the firewall external interface name.
	

	- 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.