mailing list archives
[VU#317417] Denial of Service condition in vxworks ftpd/3com nbx
From: "Michael S. Scheidell" <Scheidell () secnap com>
Date: Mon, 2 Dec 2002 13:04:31 -0500
Name: 3com NBX IP phone system Denial of Service Attack
Systems: 3com NBX IP Phone Call manager, FW Versions through 4_1_4
Category: Denial of Service
Classification: Boundary Condition Error
Vendor URL: http://www.3com.com
Author: Michael S. Scheidell (scheidell () secnap net)
Date: December 2nd, 2002
Notifications: (3com, WindRiver and CERT) Notified October 31st, 2002
Contact with 3com October 31st, November 1st, 5th, 6th, 15th and November 22nd
Contact with WindRiver: October 31st, November 6th, 22nd, and 24th. No response from WindRiver.
Discussion: (From 3com's and WindRiver's web site)
3Com® SuperStack® 3 NBX® and 3Com NBX 100 networked telephony solutions offer wide-ranging price/performance
alternatives to fit your business needs today and tomorrow. 3Com® SuperStack® 3 NBX® Networked Telephony Solution
Delivers robust, full-featured business communications for up to 1500 devices (lines/stations) Ensures high system
availability with the Wind River VxWorks real-time operating system (also used in pacemakers and artificial hearts), so
server and PC downtime does not impact your telephone service.
VxWorks and pSOSystem are the most widely adopted real-time operating systems (RTOSs) in the embedded industry -- for
good reason. They are flexible, scalable, reliable, and available on all popular CPU platforms. They are also, by most
measures, the fastest RTOSs available today.
It was possible to make the remote FTP server crash by issuing this command :
CEL aaaa[...]aaaa where string is 2048 bytes long. This can be done with netcat,
a windows client by telnetting to the nbx server on port 21 or by running the aix_ftpd.nasl test
in nessus (www.nessus.org)
The 3com NBX uses VXWORKS Embedded Real time Operating system and what appears to be their own internal ftp server.
This buffer overflow problem seems to be one similar to the AIX ftpd reported in CVE 1999-0789 and bugtraq id 679.
By sending a specific string of data to the ftp server, an attacker can disable not only the ftp server, but the
integrated web based administrative console and the call manager preventing diagnostics, control and all incoming,
outgoing or internal calls. Any calls in progress cannot be disconnected, and in the case of long distance calls,
could result in excessive long distance bills and extended loss of use of the phone system.
This condition is not recovered without a Hard reboot (power off/on). Since the 3com nbx is based on an embedded *nix
operating system, and abrupt power off could cause loss of data, including corruption of voice mails in progress or
A company who uses the VoIP features for remote locations, and who has the call manager located on the outside of their
firewall, or has no firewall can have their voice communications disrupted easily. Even if the company has call
manager located on internal network, people with internal network access can also disrupt communications.
We have tested 3com nbx firmware version 4_0_17 (with ftpd version 5.4) and nbx firmware version 4_1_4 (ftpd version
5.4.2) and this bug seems to be present in both systems.
3com confirmed problem and received a field patch, TSR(296292) from vxworks to address the problem. Neither WindRiver
nor 3com has provided a test bed or access to a fixed system for us verify fix. 3com will be working to integrate this
TSR into a future release of the nbx build but has no date yet for release. Also, since ftpd is only used for debugging
and diagnostics, a future firmware will allow the administrator the ability to turn off ftpd if not used.
Please contact 3com for further information.
There is no known fix. If you have information about a fix, please contact security () secnap net
There appears to be on way to turn off the build in ftp server in this version of the software, no way to do ip address
limits via tcp wrapper or acls, and if there is a build in firewall, there is no documented way to access it. The only
way we know of to prevent a denial of service attack on the 3com nbx is to place it behind its own firewall. If call
manager is placed on the Internet side of the firewall or in the DMZ, care should be taken to prohibit any access to
ftp port (tcp port 21) This may be impossible on an internal network unless 3com nbx is itself placed behind a
firewall, or on a separate VLAN or network segment.
Care should be taken in this approach, since some firewalls may interfere with the VoIP operations.
(see Firewall limits vex VoIP users http://www.nwfusion.com/news/2002/0625bleeding.html )
This problem was originally found during a routine security audit by Michael Scheidell, SECNAP Network Security,
www.secnap.net using the Nessus vulnerabilities scanner, www.nessus.org.
A tcpdump/pcap packet of the sploit and ftpd/nbx response can be found at
A copy of this report can be found at http://www.secnap.net/security/nbx001.html
and at http://www.kb.cert.org/vuls/id/317417
If you have snort or ISS's trons IDS, a signature to detect this attack can be found at
To test your systems for this vulnerability, you can use Nessus at www.nessus.org. Either update your signatures, or
download this nessus signature: vxworks_ftpd.nasl http://cgi.nessus.org/plugins/dump.php?id=11185
For a report on Security Risk Factors with IP Telephony based Networks see:
Also reference article "is VoIP vulnerable"? http://www.nwfusion.com/news/2002/0624voip.html
Above Copyright(c) 2002, SECNAP Network Security, LLC. World rights reserved.
This security report can be copied and redistributed electronically provided it is not edited and is quoted in its
entirety without written consent of SECNAP Network Security, LLC. Additional information or permission may be obtained
by contacting SECNAP Network Security at 561-368-9561 or at www.secnap.com
Michael S. Scheidell
SECNAP Network Security www.secnap.com
scheidell () secnap net / 1+561.368.9561, 1131
- [VU#317417] Denial of Service condition in vxworks ftpd/3com nbx Michael S. Scheidell (Dec 02)