iptables icmp protocol match bug.

iptables icmp protocol match bug.

[Peteris Krumins]

Hello,

 A quick bug report:

 iptables -A INPUT -p icmp --icmp-type 255 -i lo -j REJECT

 this rule also denies icmp ping and i think anything else of icmp.

 Works for me at least on 2.4.22-pre6 and patch-o-matic-20030714
 havent tried w/ newer versions.
 
 Does not work on base 2.4.20 and iptables 1.2.7a

proof:
--
z@xor:/[1032]# iptables -A INPUT -p icmp --icmp-type 255 -i lo -j REJECT
z@xor:/[1033]# ping localhost -c 5
PING localhost (127.0.0.1): 56 octets data

--- localhost ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

z@xor:/[1034]# iptables -D INPUT -p icmp --icmp-type 255 -i lo -j REJECT
z@xor:/[1035]# ping localhost -c 5
PING localhost (127.0.0.1): 56 octets data
64 octets from 127.0.0.1: icmp_seq=0 ttl=128 time=0.3 ms
64 octets from 127.0.0.1: icmp_seq=1 ttl=128 time=0.3 ms
^C


P.Krumins







netfilter-devel@lists.netfilter.org

Re: iptables icmp protocol match bug.

[Patrick McHardy]

Peteris Krumins wrote:

>Hello,
>
> A quick bug report:
>
> iptables -A INPUT -p icmp --icmp-type 255 -i lo -j REJECT
>

This is deliberate. There is no valid icmp-type 255, it is used as a
wildcard to match every possible type. See icmp_type_code_match()
in ip_tables.c. Perhaps the userspace tool should warn about invalid
types ?

Patrick

>
> this rule also denies icmp ping and i think anything else of icmp.
>
> Works for me at least on 2.4.22-pre6 and patch-o-matic-20030714
> havent tried w/ newer versions.
> 
> Does not work on base 2.4.20 and iptables 1.2.7a
>
>proof:
>--
>z@xor:/[1032]# iptables -A INPUT -p icmp --icmp-type 255 -i lo -j REJECT
>z@xor:/[1033]# ping localhost -c 5
>PING localhost (127.0.0.1): 56 octets data
>
>--- localhost ping statistics ---
>5 packets transmitted, 0 packets received, 100% packet loss
>
>z@xor:/[1034]# iptables -D INPUT -p icmp --icmp-type 255 -i lo -j REJECT
>z@xor:/[1035]# ping localhost -c 5
>PING localhost (127.0.0.1): 56 octets data
>64 octets from 127.0.0.1: icmp_seq=0 ttl=128 time=0.3 ms
>64 octets from 127.0.0.1: icmp_seq=1 ttl=128 time=0.3 ms
>^C
>
>
>P.Krumins
>
>
>
>
>
>
>
>netfilter-devel@lists.netfilter.org
>  
>

Re[2]: iptables icmp protocol match bug.

[Peteris Krumins]

Friday, August 1, 2003, 12:52:00 AM, you wrote:

PM> Peteris Krumins wrote:

>>Hello,
>>
>> A quick bug report:
>>
>> iptables -A INPUT -p icmp --icmp-type 255 -i lo -j REJECT
>>

PM> This is deliberate. There is no valid icmp-type 255, it is used as a
PM> wildcard to match every possible type. See icmp_type_code_match()
PM> in ip_tables.c. Perhaps the userspace tool should warn about invalid
PM> types ?

Why there is no valid icmp-type 255? Maybe it is not defined by rfc or
(IANA?), but it could still be used, couldnt it? (Tho i block all but
those really needed).

Why is it defined to be used as a wildcard worldwide? If not, I think
this is wrong - because if it is not defined to be used for this
purpose, then it is still valid and could be used (by some
application which constructs packets itself and has chosen 0xff for
communications, for example).


P.Krumins

Re: iptables icmp protocol match bug.

[Patrick McHardy]

Peteris Krumins wrote:

> PM> This is deliberate. There is no valid icmp-type 255, it is used as a
>
>PM> wildcard to match every possible type. See icmp_type_code_match()
>PM> in ip_tables.c. Perhaps the userspace tool should warn about invalid
>PM> types ?
>
>Why there is no valid icmp-type 255? Maybe it is not defined by rfc or
>(IANA?), but it could still be used, couldnt it? (Tho i block all but
>those really needed).
>

It is not defined. The highest defined type is ICMP_ADDRESSREPLY (18).
Of course some application could construct _invalid_ icmp packets, but
who cares ?

>Why is it defined to be used as a wildcard worldwide? If not, I think
>this is wrong - because if it is not defined to be used for this
>purpose, then it is still valid and could be used (by some
>application which constructs packets itself and has chosen 0xff for
>communications, for example).
>  
>

Ok i see your point, "icmp-type 255 equals wildcard" was introduced
as a workaround for "-m icmp" not matching all (or none, i can't
remember exactly) types. I suppose if you submit a patch with a better
solution, everyone will be fine with it, but it doesn't sound as if you
would need it yourself. IIRC one of the reason this way was chosen was
backwards-compatibility, if you introduce a new flag you break the ABI.

Bye
Patrick

>
>P.Krumins
>  
>

Re: iptables icmp protocol match bug.

[Henrik Nordstrom]

On Fri, 1 Aug 2003, Patrick McHardy wrote:

> It is not defined. The highest defined type is ICMP_ADDRESSREPLY (18).
> Of course some application could construct _invalid_ icmp packets, but
> who cares ?

Anyone who wants to block such invalid ICMP packets.. but given the low 
ratio of valid ICMP codes it is easier to build a list of what one accepts 
than what not.

Regards
Henrik

Re: iptables icmp protocol match bug.

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Thu, Jul 31, 2003 at 11:52:00PM +0200, Patrick McHardy wrote:
 
> This is deliberate. There is no valid icmp-type 255, it is used as a
> wildcard to match every possible type. See icmp_type_code_match()
> in ip_tables.c. Perhaps the userspace tool should warn about invalid
> types ?

yes, please make this a bugzilla entry so we don't forget about that.

> Patrick

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: iptables icmp protocol match bug.

[Patrick McHardy]

Harald Welte wrote:

>On Thu, Jul 31, 2003 at 11:52:00PM +0200, Patrick McHardy wrote:
> 
>  
>
>>This is deliberate. There is no valid icmp-type 255, it is used as a
>>wildcard to match every possible type. See icmp_type_code_match()
>>in ip_tables.c. Perhaps the userspace tool should warn about invalid
>>types ?
>>    
>>
>
>yes, please make this a bugzilla entry so we don't forget about that.
>  
>

I'll do that later or just send a patch.

Bye
Patrick

iptables icmp protocol match bug.

[Peteris Krumins]

Hello,

 A quick bug report:
 (sorry for crossposting to devel and user list, but i am interested
 if anyone else can reproduce)

 iptables -A INPUT -p icmp --icmp-type 255 -i lo -j REJECT

 this rule also denies icmp ping and i think anything else of icmp.

 Works for me at least on 2.4.22-pre6 and patch-o-matic-20030714
 havent tried w/ newer versions.
 
 Does not work on base 2.4.20 and iptables 1.2.7a

proof:
--
z@xor:/[1032]# iptables -A INPUT -p icmp --icmp-type 255 -i lo -j REJECT
z@xor:/[1033]# ping localhost -c 5
PING localhost (127.0.0.1): 56 octets data

--- localhost ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

z@xor:/[1034]# iptables -D INPUT -p icmp --icmp-type 255 -i lo -j REJECT
z@xor:/[1035]# ping localhost -c 5
PING localhost (127.0.0.1): 56 octets data
64 octets from 127.0.0.1: icmp_seq=0 ttl=128 time=0.3 ms
64 octets from 127.0.0.1: icmp_seq=1 ttl=128 time=0.3 ms
^C


P.Krumins







netfilter-devel@lists.netfilter.org