Foundry Networks Security Advisories Archive (bugTraq)

01 /The bugTraq.html page and why it was linked

Foundry published its security notices on a single page at the root of the corporate site, named bugTraq.html after the disclosure mailing list of the era. The page listed each advisory with the affected products, the IronWare releases that fixed it and sometimes a link to a longer response document. Vulnerability databases and mailing-list archives linked to it as the vendor statement, which made it one of the most externally linked URLs on the domain. After the Brocade integration the page disappeared and those citations broke. This page records what was there in general terms and does not reproduce the notices.

02 /February 2002: multi-vendor SNMP vulnerabilities (CA-2002-03)

In February 2002 the CERT Coordination Center published advisory CA-2002-03 after the Oulu University Secure Programming Group (OUSPG) released its PROTOS test suite of malformed SNMPv1 messages. Nearly every network vendor was affected, and operators assumed Foundry was too because IronWare shipped an SNMP agent listening by default. The CERT/CC vulnerability notes (VU#854306 and VU#107186) record Foundry's status as Not Affected: its vendor statement, updated 18 February 2002, said PROTOS testing found no Foundry device affected on SNMP v1, v2c or v3. The sensible advice at the time still applied, filter UDP 161 and 162 at the network edge and keep agents patched. The SNMP MIBs page covers the protocol side.

03 /September 2003: OpenSSH buffer management (CA-2003-24)

CERT advisory CA-2003-24 of September 2003 described a buffer management error in OpenSSH releases before 3.7. Embedded devices whose SSH servers derived from that code were exposed, and Foundry published a notice for the IronWare SSH implementation under /solutions/advisories/. The fix was an IronWare update; the interim mitigation was an access list limiting which hosts could open TCP 22 to the device.

04 /April 2004: TCP reset attacks (NISCC 236929)

In April 2004 the UK NISCC published advisory 236929. It showed that a spoofed TCP RST or SYN segment only needed a sequence number inside the receive window, not an exact match, to tear down a connection, and that long-lived BGP sessions between routers were the natural target. Foundry, whose NetIron routers ran BGP in service provider cores, published a TCP vulnerability response document listing affected releases and mitigations: TCP MD5 signatures on BGP sessions (RFC 2385) and ingress filtering of spoofed sources.

05 /Other advisory classes of the era

• Default SNMP community strings. Early IronWare shipped with the read-only community public and, on some releases, a read-write community, giving configuration access to anyone on the management network.
• Telnet exposure. Telnet was on by default and carried credentials in clear text; several notices concerned telnet authentication behaviour on specific releases.
• Web management interface. The HTTP interface had authentication and input handling bugs common to every vendor of the period.

06 /Hardening a legacy IronWare device today

No vendor issues fixes for Foundry-era IronWare. The only controls left are exposure and configuration. The list below is the minimum.

1. Put the management IP on a dedicated management VLAN (VLANs) not routed to the internet or to user segments.
2. Disable telnet and the HTTP management interface. Use SSH version 2 only and regenerate the host key so a previous owner does not hold it.
3. Disable SNMP unless polling is needed. If it is, use SNMPv3 where the release supports it, otherwise a long random read-only community restricted by ACL. Never enable a read-write community.
4. Apply access lists to every management service so only the monitoring host and the admin jump host can reach the device.
5. Change every password, remove unknown user accounts, and do not expose any service to the internet.

configure terminal
no telnet server
no web-management http
crypto key generate rsa
access-list 10 permit host 10.10.0.5
ssh access-group 10
no snmp-server community public ro
snmp-server community LONG-RANDOM-STRING ro 10
enable super-user-password NEW-PASSWORD
write memory

Exact keywords vary between IronWare releases and between switch and router images; see the CLI reference. Verify from outside with a port scan of the management address: only TCP 22, and UDP 161 if SNMP is required, should answer. Unknown credentials are handled under password recovery. The exposure is worse for the security and wireless products: the inspection code on SecureIron firewall load balancers and the firmware on IronPoint access points have had no fixes since the late 2000s. Every affected family is listed from the Foundry product archive.

07 /Foundry Networks security advisories: reading the record today

The durable copies of these advisories are the CERT/CC vulnerability notes, each with a vendor section giving a dated status and, where supplied, a statement. Read the statement, not the list. On VU#107186 and VU#854306, the two notes behind CA-2002-03, Foundry is listed as Not Affected, updated February 18, 2002, with a statement that testing with the PROTOS tools found no Foundry device affected on SNMP v1, v2c or v3. On VU#333628, the OpenSSH note of September 16, 2003, Foundry is listed as Affected with no statement and an addendum pointing to /solutions/advisories/openssh333628.html on this domain. On VU#415294, the April 2004 TCP reset note, Foundry does not appear at all; its response was the standalone document under /solutions/security/.

The bugTraq page survives only as web archive captures, which do not show when each notice was added. To verify a claim about a Foundry vulnerability: find the VU number, read the vendor status and its date, then find a capture of the matching Foundry page and note the capture date, following archiving the advisory pages themselves. A fixed IronWare release or a CVE that appears in no note and no capture should be treated as invented; the provenance section applies the same test of origin and date to content in transit.

Because no fix is coming, the record of who reached the management plane is the control that remains. Send syslog to a collector kept under the rules for logging that stands up as evidence, so a login from an unexpected host is provable, not merely noticed.