[LWN Logo]
[Timeline]
Date:         Mon, 4 Dec 2000 16:12:31 -0800
From: Ed Ingber <ingber@IPRG.NOKIA.COM>
Subject:      Nokia firewalls - Response from Nokia
To: BUGTRAQ@SECURITYFOCUS.COM

This posting is Nokia's response to the issue raised by author "K2" posted
on BugTraq on November 27, 2000 under the subject "Nokia firewalls". We
thank "K2" for bringing this issue to the attention of BugTraq, although
Nokia was not notified directly by "K2" prior to his posting.

"K2" classified this vulnerability as "low priority", and we agree with his
statement based on the nature of the vulnerability and the potential
exploits that might arise from it.

The Vulnerability: Sending a malformed URL consisting of a very large
number of characters ("K2" used 6000+ characters) to the Voyager web-based
management interface of a Nokia platform may interrupt certain
Voyager-related processes affecting access to Voyager. Operation of the
firewall forwarding and filtering functions is not affected, nor is command
line access.

Potential Exploits: No ability to plant malicious code or execute arbitrary
commands has been demonstrated, although this is always a risk in any
buffer overflow-like vulnerability. The exploit has been demonstrated to be
a denial of service affecting the web-based Voyager management interface -
command line management and firewall operation are not affected. To exploit
this vulnerability, the attacker would need access to Voyager and need to
be authenticated as an administrator or monitor (read-only administrator)
with user name and password. Good practice dictates disabling Voyager
access from the untrusted network (e.g. the Internet) if possible. An
inside administrator attacker then having user name and password access to
the management interface would be in a position to do far more harm than
simply disable the web-based Voyager management interface. Voyager could be
vulnerable to an authenticated inside monitor (read-only) administrator
who, worst case, might be able to execute arbitrary code and gain root and
therefore read/write access. You might consider disabling monitor access,
or providing it only to administrators that you trust.

Recommendations:
1. Do not allow Voyager access from untrusted networks (e.g. the Internet).
2. Use good generally accepted practice regarding password selection and
confidentiality (as always).
3. Consider disabling monitor (read-only administrator) access.
4. Use the provided SSH with port redirection (IPSO 3.2.1 and earlier) or
embedded SSL (IPSO 3.3 and later) to encrypt http traffic to Voyager to
prevent an attacker from eavesdropping to hear the password.

A good FireWall-1 rule set to implement recommendations 1-4 might look
something like:

Source / Dest / Service / Action
--------------------------------------------------------------
admin-group / firewalls / [http,] ssh / Accept
management-console / firewalls / fw1-group / Accept
Any / firewalls / Any / Drop

The first rule permits administrative access. The second provides
FireWall-1 management access for the machine acting as the management
console (and is only referenced if Properties have been modified to no
longer accept FireWall-1 Control Connections). The third excludes all other
traffic directly to the firewalls, and is referred to by Check Point as the
"stealth rule".

With these appropriate rules, an attacker must meet the criteria
established in your FireWall-1 security policy and then also be
authenticated as an administrator before he can attempt to attack the
Voyager-related processes.

This low priority vulnerability will be fixed in the next scheduled release
of IPSO (Nokia's OS). For further assistance, customers may contact the
Nokia Technical Assistance Center referenced in your product documentation.
When contacting TAC, reference Resolution 4097.

Ed Ingber, Product Manager
Nokia Internet Communications
650-625-2345