|
|
|
|
| |
A buffer overflow vulnerability was recently discovered in Nokia's Firewall implementation.
The following is a response from Nokia that attempts to explain the impact of this security problem, as well as offer possible workarounds for it.
The original article is available at: http://www.securiteam.com/securitynews/Nokia_Firewall_vulnerable_to_a_buffer_overflow.html |
| |
Credit:
This information was provided by Ed Ingber, Nokia Internet Communications.
|
| |
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 so far demonstrated, although this is always a risk in any buffer overflow-like vulnerability. The exploit that has been provided only demonstrates 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. Therefore you might want 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 on a connection and capturing the password (or hijacking a session).
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.
|
|
|
|
|
|
|
|
|
|
