Bug 981133 - port range validation is wrong for icmp security group rule
port range validation is wrong for icmp security group rule
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron (Show other bugs)
Unspecified Unspecified
medium Severity medium
: beta
: 4.0
Assigned To: Jakub Libosvar
Ofer Blaut
Depends On: 978354
  Show dependency treegraph
Reported: 2013-07-04 01:56 EDT by Etsuji Nakai
Modified: 2016-04-27 01:05 EDT (History)
7 users (show)

See Also:
Fixed In Version: 2013.2-0.4.b3
Doc Type: Bug Fix
Doc Text:
In OpenStack Networking, a problem occurred due to incorrect conditionals of ICMP code and type validation. As a result, ICMP packets with 'type 8' and 'code 0' failed the validation and printed this traceback to logs: QuantumClientException: For TCP/UDP protocols, port_range_min must be <= port_range_max This has been fixed by implementing specific validation for ICMP. Now, code and type are validated by ensuring that they fit in the range 0-255 (both included). Hence ICMP packets with 'type' greater than 'code' pass validation.
Story Points: ---
Clone Of: 978354
Last Closed: 2013-12-19 19:12:40 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Etsuji Nakai 2013-07-04 01:56:22 EDT
I confirmed that Bug #978354 found in RDO is also in RHOS.

# rpm -qa | grep quantum

+++ This bug was initially created as a clone of Bug #978354 +++

Description of problem:

You cannot add a security group rule such as:

protocol: icmp
type: 8
code: 0

It causes the following error:

2013-06-26 21:15:47.348 15711 TRACE nova.api.openstack QuantumClientException: For TCP/UDP protocols, port_range_min must be <= port_range_max

I'm using the Horizon dashboard to add the rule, but it would be the same for a direct API operation.

Version-Release number of selected component (if applicable):

# rpm -qa | grep quantum

Additional info:

The problem lies in _validate_security_group_rules() in quantum/db/securitygroups_db.py

In this function, the following condition is validated.

  rule['port_range_min'] <= rule['port_range_max']

But in the case of ICMP protocol rule, since rule['port_range_min'] and rule['port_range_max'] correspond to icmp type and code, this validation is wrong. Instead, the following condition should be checked.

                if ( rule['port_range_min'] >= -1 and
                     rule['port_range_min'] <= 255 and
                     rule['port_range_max'] >= -1 and
                     rule['port_range_max'] <= 255):

See the attachment for my patch, but this is just a quick hack. More fundamental refactoring should be done to handle different protocols separately.
Comment 3 lpeer 2013-08-13 06:51:07 EDT
A mitigation for this issue is to open ALL ICMP type range (set min==max==0).

A more granular configuration, like enabling only ping (type-8), is not supported with the current code base.

I assume this is an u/s issue.
Comment 4 Rami Vaknin 2013-11-12 15:57:34 EST
It seems like in rhos 4.0 (2013-11-08.1 puddle) this validation has been fixed already:

$ neutron security-group-rule-create --protocol icmp --port-range-min 8 --port-range-max 0 default
Created a new security_group_rule:
| Field             | Value                                |
| direction         | ingress                              |
| ethertype         | IPv4                                 |
| id                | 16d50488-718d-4cf9-b02b-cee52d436def |
| port_range_max    | 0                                    |
| port_range_min    | 8                                    |
| protocol          | icmp                                 |
| remote_group_id   |                                      |
| remote_ip_prefix  |                                      |
| security_group_id | 9d0fbe03-909a-4ef8-9022-f1ba664554b3 |
| tenant_id         | c6218eb9b8c44c91861ea7998db55505     |
Comment 5 Rami Vaknin 2013-11-14 03:53:52 EST
Moving to Verified per comment#4.
Comment 8 errata-xmlrpc 2013-12-19 19:12:40 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.