('binary' encoding is not supported, stored as-is) In-Reply-To: <3D427349.8000009at_private> ************************************** Lucent Technologies Internet Security Products July 25, 2002 *** Advisory Notification Response *** SUMMARY This statement is in response to an advisory authored by individuals identifying themselves as kim0 and FX from an organization known as Phenoelit. This advisory was identified as "Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 ++->". The Lucent VPN Firewall Brick is a high-speed hybrid packet-processing firewall appliance. The currently Generally-Available release of the Lucent VPN Firewall system is 6.0. The Lucent VPN Firewall Brick version 6.0 can be configured to be not vulnerable to the types of attacks specified in this advisory notification. Version 7.0 of the Lucent VPN Firewall, scheduled to be generally-available in September, 2002, contains features that enhance the administrator's ability to so configure the Brick. DISCUSSION The attached advisory addresses three potential sources of vulnerability: 1) An attacker may be able to, via misuse of the ARP protocol, cause the Lucent Brick to lose connection with its management server (the Lucent Security Management Server, or LSMS). 2) An attacker may be able to, via misuse of the ARP protocol, perform discovery of IP hosts through the Lucent Brick, regardless of security policy. 3) An attacker may be able to perform system identification of the Brick itself due to the Brick's dynamic host discovery procedure, which may use the ARP protocol. The Lucent VPN Firewall team ("Lucent" hereafter) acknowledges that, under certain configuration, the Lucent VPN Firewall Brick may behave as indicated in the advisory. However, Lucent has several general responses to the entire class of reported vulnerabilities, as well as responses specific to each of the itemized points. Since the ARP protocol is a Layer-2 protocol, it will not pass beyond the local segment. That is, ARP messages do NOT pass through a router. As a result, for an attacker to exploit any of these vulnerabilities, he must already have control of a host directly connected to a Brick. If the Brick is installed between two or more routing points, any ARPs generated will be stopped by those routing points, and go no further. When configured such that each interface is assigned to a different IP subnet, the Brick does not exhibit behaviors (1) and (2). To be more specific, ARP requests will not be forwarded across subnets, so placing an interface (or VLAN) on a different subnet causes it to be immune to any attack based on the Brick's forwarding ARP messages. Simply by placing the LSMS on a different network than the inband data traffic, issue (1) is eliminated. Furthermore, the Brick _does_ have a checkbox which controls whether MAC addresses may be dynamically moved. This checkbox may be unchecked in sensitive topologies, to ensure that MAC addresses may not be spoofed. By default, the brick is configured in the more secure mode. Although the Brick does use ARP messages to stimulate responses from locally-connected hosts, regardless of security policy, it will not do so if the MAC address of the host has been cached at any time since boot (since that MAC table is not automatically aged). Lucent VPN Firewall version 7.0, scheduled to be Generally Available in September, 2002, contains the following additional features, which may additionally mitigate the concerns illustrated above. a] Static ARP and MAC entries The Brick will now have the ability to create manual static ARP and MAC bindings. With this ability, issue (1) above can be completely eliminated. b] Elimination of periodic ARP Request generation for local host discovery purposes The Brick will now only retransmit periodic ARP messages for statically-configured IP addresses, including gateway addresses in the routing table, the LSMS hosts, and the Lucent Proxy Agent hosts. The Brick will no longer perform persistent ARP requests for other end hosts when performing simple host discovery; after a single request/response, the ARP Request will not be repeated. c] Further limits on ARP Requests used for local host discovery If the Brick does need to perform MAC discovery, the Brick will no longer transmit ARP requests on the original interface on which the original packet was received. This mitigates issue (3) listed above. This Response applies to ALL models of the Lucent VPN Firewall Brick hardware running version 6.0 or later software (There is no version 5.5) POINT OF CONTACT Any questions or issues with regards to this Vulnerability Response may be addressed to: Andrew Ferreira aferreira2at_private The general email for reporting security events to Lucent Technologies is: securityalertat_private The text of the original advisory follows: > >Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 ++-> > >[ Authors ] > FX <fxat_private> > kim0 <kim0at_private> > > Phenoelit Group (http://www.phenoelit.de) > http://www.phenoelit.de/stuff/Lucent_Brick.txt > >[ Affected Products ] > Lucent > LSMS 5.5 (Lucent Brick, Bridging VPN Firewall) > > Lucent Bug ID: Not assigned > >[ Vendor communication ] > 06/28/02 Reply to inquiry regarding "who to notify" > 06/29/02 Initial Notification to Brick team > *Note-Initial notification by phenoelit > includes a cc to certat_private by default > 07/02/02 Ack. of receipt by Lucent Brick team > 07/06/02 Weekly follow-up by central POC at > Lucent (Right on Time) > 07/08/02 Additional tech-discussions > 07/19/02 Notification of intent to post publically > in apx. 7 days. > 07/25/02 Notification that due to personnel changes at Lucent, > our POC has changed. The new person is supposed to be > contacting us... > >[ Overview ] > The Lucent Brick VPN Firewall is a layer 2, NCSA, US Army, and > US National Security Agency (NSA) Approved/Certified Firewall that > operates on Inferno, an Embdedded Operating System. "Brick" devices > come in many sizes from the SOHO Brick 20 to the Enterprise 1000(GiG). > >[ Description ] > The Brick suffers from several design failures in handling of the ARP > protocol. > > 1. It is possible to interrupt any connection between the Brick and > critical devices such as the LSMS (Brick Management Server) by > binding the IP Address of the device in question to the attackers > interface and "pinging" the Brick or any address behind it. The Brick > will immediately update its ARP cache and drop the connection, no matter > where the attacker is located (internal/outside segment). This > requires the "Floating MAC" setting to be turned on. > > 2. The Brick will forward any ARP request and response across all > interfaces, regardless of the existing firewall rules. > > 3. All Bricks are identifiable during reconnaissance using the most > basic of techniques (pinging all addresses in segment). The device > that sends ARP requests for the attacker IP address is the Brick. > >[ Example ] > 1. # man ping > 2. # man arp > 3. # for i in ´cat ipaddresses.txt´; do ping $i; done > >[ Solution ] > None known at this time. > >[ end of file ] > >--------------020106060506060805030901-- > >
This archive was generated by hypermail 2b30 : Thu Aug 01 2002 - 09:39:10 PDT