Possibly dangerous interpretation of address/prefix pair in -s option

Possibly dangerous interpretation of address/prefix pair in -s option

[Stefan Riha]

Hi,

I'm a beginner and noticed than when I do e.g.

iptables -A INPUT ... -s 10.0.0.2/24 ...

this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the entire network. I think it would be more beginner-proof if iptables would interpret this as incorrect input and error. Or at least, interpret 10.0.0.2/24 as 10.0.0.2/32. So if there is incorrect input, and that input is automatically re-interpretet (which in itself is unsafe, I would think), then at least interpret it in the way that is more restrictive (i.e. single IP instead of subnet). Otherwise I like iptables a lot, thanks for all the great work!

Regards, Stefan 

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Reindl Harald]

Am 03.06.22 um 16:54 schrieb Stefan Riha:
> I'm a beginner and noticed than when I do e.g.
> 
> iptables -A INPUT ... -s 10.0.0.2/24 ...
> 
> this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the entire network. I think it would be more beginner-proof if iptables would interpret this as incorrect input and error. Or at least, interpret 10.0.0.2/24 as 10.0.0.2/32. So if there is incorrect input, and that input is automatically re-interpretet (which in itself is unsafe, I would think), then at least interpret it in the way that is more restrictive (i.e. single IP instead of subnet). Otherwise I like iptables a lot, thanks for all the great work!
sorry - garbage in - garbage out
that's how netmasks are working

you are supposed to review your inputs and the final ruleset and the 
decimal way of writing ip's is completly different to the internal way 
of the tcp stack

ipcalc 10.0.0.2/24
Address:        10.0.0.2
Network:        10.0.0.0/24
Netmask:        255.255.255.0 = 24
Broadcast:      10.0.0.255

Address space:  Private Use
HostMin:        10.0.0.1
HostMax:        10.0.0.254
Hosts/Net:      254

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Chris Hall]

> Am 03.06.22 um 16:54 schrieb Stefan Riha:
>> I'm a beginner and noticed than when I do e.g.
>>
>> iptables -A INPUT ... -s 10.0.0.2/24 ...
>>
>> this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the 
>> entire network. I think it would be more beginner-proof if iptables 
>> would interpret this as incorrect input and error. Or at least, 
>> interpret 10.0.0.2/24 as 10.0.0.2/32. So if there is incorrect input, 
>> and that input is automatically re-interpretet (which in itself is 
>> unsafe, I would think), then at least interpret it in the way that is 
>> more restrictive (i.e. single IP instead of subnet). Otherwise I like 
>> iptables a lot, thanks for all the great work!

The iptables(8) Linux manual page says:

        [!] -s, --source address[/mask][,...]

               Source specification. Address can be either a network
               name, a hostname, a network IP address (with /mask), or a
               plain IP address. ....

For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid 
network address for a /24 network.

I agree: the parser should detect invalid input and reject it.  I can 
see no good reason for being sloppy here.

On 03/06/2022 16:21, Reindl Harald wrote:
> sorry - garbage in - garbage out
> that's how netmasks are working

Except that in this case the iptables command parser could trivially 
have detected the 'garbage in' and rejected it instead of generating 
'garbage out'.

It can be argued that it is too late to fix the parser, on the basis 
that this could stop existing configurations from working.  But that 
doesn't mean that the parser is not broken.

 > you are supposed to review your inputs and the final ruleset

Sure, but it takes quite careful reading of the man page to discover 
that 10.0.0.2/24 is undefined.  Worse yet, iptables then does something 
undefined (AFAICS) :-(

Once you are thoroughly used to how something works, it's easy to become 
convinced that what it does is *obvious* and *right*.  Sometimes it 
takes someone with a different perspective to see the problem.

The emperor is suffering a wardrobe malfunction.

Chris

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Florian Westphal]

Chris Hall <netfilter@gmch.uk> wrote:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> network address for a /24 network.
> 
> I agree: the parser should detect invalid input and reject it.  I can see no
> good reason for being sloppy here.

It breaks current behaviour; we cannot change this 20 years later.
Its as simple as that.

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Chris Hall]

On 08/06/2022 12:21, Florian Westphal wrote:
> Chris Hall <netfilter@gmch.uk> wrote:
>> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
>> network address for a /24 network.
>>
>> I agree: the parser should detect invalid input and reject it.  I can see no
>> good reason for being sloppy here.

Perhaps that should have been "...no good reason for _having_been_ 
sloppy...".

> It breaks current behaviour; we cannot change this 20 years later.
> Its as simple as that.

You snipped the bit where I said:

 >> It can be argued that it is too late to fix the parser, on the basis 
 >> that this could stop existing configurations from working.  But that 
 >> doesn't mean that the parser is not broken.

I am hoping that it is agreed that it is a mistake for the parser to 
silently accept unspecified input and proceed to so something 
unspecified with it.

Accepting that "breaking current behaviour" is a cardinal sin, the 
(obvious) alternative to fixing the code is to (retrospectively) fix the 
specification and amend the man page to reflect that.

Given that (eg) "-s 10.0.0.2/24" is at best ambiguous, and at worst 
nonsense: would a warning message "break current behaviour" ?

Anyway: "20 years later" suggests that this is not a big problem.  I am 
not trying to argue that it is.

Finally: given what the man page says, my principal issue was with the 
(repeated) insistence (elsewhere) that what iptables does is both 
*correct* and *obvious*, and that a "newbie" suggesting otherwise should 
listen to their "elders and betters" and kindly "go away".

Chris

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Reindl Harald]

Am 09.06.22 um 19:52 schrieb Chris Hall:
> I am hoping that it is agreed that it is a mistake for the parser to 
> silently accept unspecified input

it is *not* unspecified input

with /24 you *clearly* say "only use the first 3 octets of the address"

when you use a netmask you are supposed to know what it does and if not 
just don't specify it - the address alone would have had the assumed result

it's dead simple and there is nothing to agree

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Joshua Moore]

Agreed as a user that netmask == more specific filtering. No netmask == use the /32 host as presented.



> On Jun 9, 2022, at 12:11 PM, Reindl Harald <h.reindl@thelounge.net> wrote:
> 
> 
> 
>> Am 09.06.22 um 19:52 schrieb Chris Hall:
>> I am hoping that it is agreed that it is a mistake for the parser to silently accept unspecified input
> 
> it is *not* unspecified input
> 
> with /24 you *clearly* say "only use the first 3 octets of the address"
> 
> when you use a netmask you are supposed to know what it does and if not just don't specify it - the address alone would have had the assumed result
> 
> it's dead simple and there is nothing to agree

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Jozsef Kadlecsik]

On Thu, 9 Jun 2022, Chris Hall wrote:

> On 08/06/2022 12:21, Florian Westphal wrote:
> > Chris Hall <netfilter@gmch.uk> wrote:
> > > For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> > > network address for a /24 network.
> > > 
> > > I agree: the parser should detect invalid input and reject it.  I can see
> > > no good reason for being sloppy here.
> 
> Perhaps that should have been "...no good reason for _having_been_ sloppy...".

I don't agree. If it have been sloppy, it had been fixed at the very 
beginning. The "firewall" guys originally were "networking" guys and it 
was never a question what 10.0.0.2/24 could mean: apply the mask 
unconditionally.

> I am hoping that it is agreed that it is a mistake for the parser to 
> silently accept unspecified input and proceed to so something 
> unspecified with it.

Nothing is unspecified. If you mean the manpage could be improved, yes, it 
seems so. 
 
> Accepting that "breaking current behaviour" is a cardinal sin, the (obvious)
> alternative to fixing the code is to (retrospectively) fix the specification
> and amend the man page to reflect that.
> 
> Given that (eg) "-s 10.0.0.2/24" is at best ambiguous, and at worst nonsense:
> would a warning message "break current behaviour" ?

Sorry, I don't understand: if it's a warning, then the wording is 
misleading, which current behaviour does break? If it's an error, then 
that is unacceptable as it could really break scripts, without easily 
realise for the operators what happened: firewall scripts run at the very 
beginning at the boot and normally nobody watches the console (if exists).

> Anyway: "20 years later" suggests that this is not a big problem.  I am not
> trying to argue that it is.
> 
> Finally: given what the man page says, my principal issue was with the 
> (repeated) insistence (elsewhere) that what iptables does is both 
> *correct* and *obvious*, and that a "newbie" suggesting otherwise should 
> listen to their "elders and betters" and kindly "go away".

I agree, unfriendly tones do not help at all to understand newcomers 
problems.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[matt]

On 2022-06-08 11:38, Chris Hall wrote:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> network address for a /24 network.
> 
> I agree: the parser should detect invalid input and reject it.  I can
> see no good reason for being sloppy here.
> 


If someone uses 10.0.0.2/24 but meant 10.0.0.2/32, then just omit the 
/24 or /32 - it's not required.

'-s 10.0.0.2' works fine

Thinking of all the iptables firewall scripts that could be in use right 
now, and would be affected by a change that stops accepting 
'10.0.0.2/24' as acceptable, and the disruption that would cause, 
expecting it to be changed is unreasonable.

If you mean to write a rule for a single IP address then just use that 
single IP address, don't use a subnet suffix. Get into that habit 
instead.

Matt

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Matt]

On 2022-06-08 11:38, Chris Hall wrote:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid
> network address for a /24 network.
> 
> I agree: the parser should detect invalid input and reject it.  I can
> see no good reason for being sloppy here.

If someone uses 10.0.0.2/24 but meant 10.0.0.2/32, then just omit the 
/24 or /32 - it's not required.

'-s 10.0.0.2' works fine

Thinking of all the iptables firewall scripts that could be in use right 
now, and would be affected by a change that stops accepting 
'10.0.0.2/24' as acceptable, and the disruption that would cause, 
expecting it to be changed is unreasonable.

If you mean to write a rule for a single IP address then just use that 
single IP address, don't use a subnet suffix. Get into that habit 
instead.

Matt

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Reindl Harald]

Am 08.06.22 um 12:38 schrieb Chris Hall:
> For input such as "-s 10.0.0.2/24", the 10.0.0.2 simply isn't a valid 
> network address for a /24 network.
> 
> I agree: the parser should detect invalid input and reject it.  I can 
> see no good reason for being sloppy here

there is nothing to parse or interprete
/24 clearly says only the first 3 octets are the relevant
again: it's a calculation

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Benny Lyne Amorsen]

Chris Hall <netfilter@gmch.uk> writes:

> The emperor is suffering a wardrobe malfunction.

Reindl Harald has worked tirelessly for more than a decade to get
himself banned from as many open source-related mailing lists as
possible.


/Benny

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Kamil Jońca]

Stefan Riha <stefan@sriha.net> writes:

> Hi,
> 
> I'm a beginner and noticed than when I do e.g.
> 
> iptables -A INPUT ... -s 10.0.0.2/24 ...
> 
> this gets interpreted as "allow from source 10.0.0.0/24" i.e. from the
> entire network. I think it would be more beginner-proof if iptables
> would interpret this as incorrect input and error. Or at least,

I am afraid that you will not find allies here.
Interpreting this as bitmask notation is quite long tradition, and I am
afrait that noone wants to put extra code here,

KJ



-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Stefan Riha]

Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that

>> how do you expect your calculator "error out" when you type "1+3" but 
meant "1+2"?

I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been

10.0.0.0/24 (that's what iptables assumed I meant)

or

10.0.0.2/32 (or equivalently 10.0.0.2)

The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type

In [3]: 3)4

python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'

Thanks again for your patience!

-----Original message-----
From: Reindl Harald
Sent: Friday, June 3 2022, 6:42 pm
To: Stefan Riha
Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option

Am 03.06.22 um 18:36 schrieb Stefan Riha:
> But it assumed that when I put in 10.0.0.2/24

you braindead moron IT CALCULATED

10.0.0.2/24 is for a computer similar to "1+2" for a human

> I actually meant 10.0.0.0/24

then write it

> That's possibly dangerous

operate a firewall as beginner is in generall dangerous

> because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).

then write it

> As you said, it can't smell what I meant when I supplied an incorrect 
> input. So the right thing would be to error, and not do anything.

how do you expect your calculator "error out" when you type "1+3" but 
meant "1+2"?

> Instead it re-interprets my incorrect input

FUCK IT - it DID NOT interprete - IT IT A CALCULATION

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Alex Buie]

Underneath, it's all just binary math.
Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
their binary representation.

EG:
10.0.0.0: 00001010.00000000.00000000.00000000
10.0.0.2: 00001010.00000000.00000000.00000010

Then you are providing a bitmask (the /24 or /32 part) to tell the
kernel which parts of the address should be checked for matching.

/24: 11111111.11111111.11111111.00000000
/32: 11111111.11111111.11111111.111111111

The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
make sure the first 24 bits match 10.0.0.2".

1- 10.0.0.50: 00001010.00000000.00000000.00110010
2- /24:       11111111.11111111.11111111.00000000
---------------------------------------------------------------
XOR 1 with 2  00001010.00000000.00000000.00000000 (result 1)

1- 10.0.0.2:  00001010.00000000.00000000.00000010
2- /24:       11111111.11111111.11111111.00000000
---------------------------------------------------------------
XOR 1 with 2  00001010.00000000.00000000.00000000 (result 2)

Result 1 == Result 2, so the source match passes.

This is functionally equivalent to telling the kernel "allow all of
10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2

There is no reinterpretation going on - the rule is simply being
processed exactly as you added it, and the behavior you suggest would
be introducing reinterpretation.

Hopefully that helps :)

Alex


On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net> wrote:
>
> Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
>
> >> how do you expect your calculator "error out" when you type "1+3" but
> meant "1+2"?
>
> I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
>
> 10.0.0.0/24 (that's what iptables assumed I meant)
>
> or
>
> 10.0.0.2/32 (or equivalently 10.0.0.2)
>
> The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
>
> In [3]: 3)4
>
> python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
>
> Thanks again for your patience!
>
> -----Original message-----
> From: Reindl Harald
> Sent: Friday, June 3 2022, 6:42 pm
> To: Stefan Riha
> Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
>
> Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > But it assumed that when I put in 10.0.0.2/24
>
> you braindead moron IT CALCULATED
>
> 10.0.0.2/24 is for a computer similar to "1+2" for a human
>
> > I actually meant 10.0.0.0/24
>
> then write it
>
> > That's possibly dangerous
>
> operate a firewall as beginner is in generall dangerous
>
> > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
>
> then write it
>
> > As you said, it can't smell what I meant when I supplied an incorrect
> > input. So the right thing would be to error, and not do anything.
>
> how do you expect your calculator "error out" when you type "1+3" but
> meant "1+2"?
>
> > Instead it re-interprets my incorrect input
>
> FUCK IT - it DID NOT interprete - IT IT A CALCULATION
>
>
>


-- 
Alex Buie
Senior Networking Software Engineer
Datto, Inc.
475-288-4550 (o)
585-653-8779 (c)
www.datto.com



Join the conversation!

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Alex Buie]

Whoops - just noticed, XOR should be AND in my message. My apologies!


On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com> wrote:
>
> Underneath, it's all just binary math.
> Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> their binary representation.
>
> EG:
> 10.0.0.0: 00001010.00000000.00000000.00000000
> 10.0.0.2: 00001010.00000000.00000000.00000010
>
> Then you are providing a bitmask (the /24 or /32 part) to tell the
> kernel which parts of the address should be checked for matching.
>
> /24: 11111111.11111111.11111111.00000000
> /32: 11111111.11111111.11111111.111111111
>
> The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> make sure the first 24 bits match 10.0.0.2".
>
> 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> 2- /24:       11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2  00001010.00000000.00000000.00000000 (result 1)
>
> 1- 10.0.0.2:  00001010.00000000.00000000.00000010
> 2- /24:       11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2  00001010.00000000.00000000.00000000 (result 2)
>
> Result 1 == Result 2, so the source match passes.
>
> This is functionally equivalent to telling the kernel "allow all of
> 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
>
> There is no reinterpretation going on - the rule is simply being
> processed exactly as you added it, and the behavior you suggest would
> be introducing reinterpretation.
>
> Hopefully that helps :)
>
> Alex
>
>
> On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net> wrote:
> >
> > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> >
> > >> how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> >
> > 10.0.0.0/24 (that's what iptables assumed I meant)
> >
> > or
> >
> > 10.0.0.2/32 (or equivalently 10.0.0.2)
> >
> > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> >
> > In [3]: 3)4
> >
> > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> >
> > Thanks again for your patience!
> >
> > -----Original message-----
> > From: Reindl Harald
> > Sent: Friday, June 3 2022, 6:42 pm
> > To: Stefan Riha
> > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> >
> > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > But it assumed that when I put in 10.0.0.2/24
> >
> > you braindead moron IT CALCULATED
> >
> > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> >
> > > I actually meant 10.0.0.0/24
> >
> > then write it
> >
> > > That's possibly dangerous
> >
> > operate a firewall as beginner is in generall dangerous
> >
> > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> >
> > then write it
> >
> > > As you said, it can't smell what I meant when I supplied an incorrect
> > > input. So the right thing would be to error, and not do anything.
> >
> > how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > > Instead it re-interprets my incorrect input
> >
> > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> >
> >
> >
>
>
> --
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com
>
>
>
> Join the conversation!



-- 
Alex Buie
Senior Networking Software Engineer
Datto, Inc.
475-288-4550 (o)
585-653-8779 (c)
www.datto.com



Join the conversation!

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Stefan Riha]

>> Whoops - just noticed, XOR should be AND in my message. My apologies!

No problem:) Thanks for taking the time and answer so comprehensively!

> There is no reinterpretation going on - the rule is simply being
> processed exactly as you added it, and the behavior you suggest would
> be introducing reinterpretation.

Hmm, but don't other programs do indeed interpret 10.0.0.2/24 differently? For example systemd-networkd interprets 10.0.0.2/24 as a single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense to me, because why would one specify the .2 at the end, if one meant the subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet itself. In the Wikipedia article about Ip addresses [1] it says: 

>> For example, the destination address used for directed broadcast to devices on the network 192.0.2.0/24 is 192.0.2.255. 

So they too interpret 192.0.2.0/24 as the network, and 192.0.2.255 as broadcast address, my point being that those two Ip addresses (i.e. beginning and end of the subnet) have two special meanings, the former representing the network.

I guess my impression is that other user space programs (e.g. systemd-networkd), interpret 10.0.0.2/24 as pair: a single ip address and a mask identifying the corresponding subnet. I am confused that iptables picks one of them without telling me to be more specific.

Why would a user space program not take advantage of that fact and unambiguously accept 10.0.0.0/24 to specify that specific subnet, and nothing else?


[1] https://en.wikipedia.org/wiki/IP_address

-----Original message-----
From: Alex Buie
Sent: Friday, June 3 2022, 7:30 pm
To: Stefan Riha
Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option

Whoops - just noticed, XOR should be AND in my message. My apologies!

On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com <mailto:alex.buie@datto.com>> wrote:
>
> Underneath, it's all just binary math.
> Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> their binary representation.
>
> EG:
> 10.0.0.0: 00001010.00000000.00000000.00000000
> 10.0.0.2: 00001010.00000000.00000000.00000010
>
> Then you are providing a bitmask (the /24 or /32 part) to tell the
> kernel which parts of the address should be checked for matching.
>
> /24: 11111111.11111111.11111111.00000000
> /32: 11111111.11111111.11111111.111111111
>
> The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> make sure the first 24 bits match 10.0.0.2".
>
> 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> 2- /24:       11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2  00001010.00000000.00000000.00000000 (result 1)
>
> 1- 10.0.0.2:  00001010.00000000.00000000.00000010
> 2- /24:       11111111.11111111.11111111.00000000
> ---------------------------------------------------------------
> XOR 1 with 2  00001010.00000000.00000000.00000000 (result 2)
>
> Result 1 == Result 2, so the source match passes.
>
> This is functionally equivalent to telling the kernel "allow all of
> 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
>
> There is no reinterpretation going on - the rule is simply being
> processed exactly as you added it, and the behavior you suggest would
> be introducing reinterpretation.
>
> Hopefully that helps :)
>
> Alex
>
>
> On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net <mailto:stefan@sriha.net>> wrote:
> >
> > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> >
> > >> how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> >
> > 10.0.0.0/24 (that's what iptables assumed I meant)
> >
> > or
> >
> > 10.0.0.2/32 (or equivalently 10.0.0.2)
> >
> > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> >
> > In [3]: 3)4
> >
> > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> >
> > Thanks again for your patience!
> >
> > -----Original message-----
> > From: Reindl Harald
> > Sent: Friday, June 3 2022, 6:42 pm
> > To: Stefan Riha
> > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> >
> > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > But it assumed that when I put in 10.0.0.2/24
> >
> > you braindead moron IT CALCULATED
> >
> > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> >
> > > I actually meant 10.0.0.0/24
> >
> > then write it
> >
> > > That's possibly dangerous
> >
> > operate a firewall as beginner is in generall dangerous
> >
> > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> >
> > then write it
> >
> > > As you said, it can't smell what I meant when I supplied an incorrect
> > > input. So the right thing would be to error, and not do anything.
> >
> > how do you expect your calculator "error out" when you type "1+3" but
> > meant "1+2"?
> >
> > > Instead it re-interprets my incorrect input
> >
> > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> >
> >
> >
>
>
> --
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com <http://www.datto.com>
>
>
>
> Join the conversation!

-- 
Alex Buie
Senior Networking Software Engineer
Datto, Inc.
475-288-4550 (o)
585-653-8779 (c)
www.datto.com <http://www.datto.com>

Join the conversation!

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Jozsef Kadlecsik]

On Fri, 3 Jun 2022, Stefan Riha wrote:

> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
> 
> Hmm, but don't other programs do indeed interpret 10.0.0.2/24 
> differently? For example systemd-networkd interprets 10.0.0.2/24 as a 
> single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense 
> to me, because why would one specify the .2 at the end, if one meant the 
> subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet 
> itself. In the Wikipedia article about Ip addresses [1] it says:

That is a different context: in systemd-networkd you want to express a 
single IP address *and* a netmask in one go, so the syntax is interpreted 
that way. The wikipedia article explains it also.

However the -s/-d options of iptables are interpreted as 
source/destination IP addresses/networks. Read the manpage: "Address can 
be either a network name, a network IP address (with /mask), or a plain IP 
address". The input is interpreted accordingly, therefore 10.0.0.2/24 is 
equal to 10.0.0.0/24.

If you want to specify a single IP address, then either use 10.0.0.2/32 or
simply 10.0.0.2.

Best regards,
Jozsef

> -----Original message-----
> From: Alex Buie
> Sent: Friday, June 3 2022, 7:30 pm
> To: Stefan Riha
> Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
> Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> 
> Whoops - just noticed, XOR should be AND in my message. My apologies!
> 
> On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com <mailto:alex.buie@datto.com>> wrote:
> >
> > Underneath, it's all just binary math.
> > Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> > their binary representation.
> >
> > EG:
> > 10.0.0.0: 00001010.00000000.00000000.00000000
> > 10.0.0.2: 00001010.00000000.00000000.00000010
> >
> > Then you are providing a bitmask (the /24 or /32 part) to tell the
> > kernel which parts of the address should be checked for matching.
> >
> > /24: 11111111.11111111.11111111.00000000
> > /32: 11111111.11111111.11111111.111111111
> >
> > The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> > make sure the first 24 bits match 10.0.0.2".
> >
> > 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> > 2- /24:       11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2  00001010.00000000.00000000.00000000 (result 1)
> >
> > 1- 10.0.0.2:  00001010.00000000.00000000.00000010
> > 2- /24:       11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2  00001010.00000000.00000000.00000000 (result 2)
> >
> > Result 1 == Result 2, so the source match passes.
> >
> > This is functionally equivalent to telling the kernel "allow all of
> > 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
> >
> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
> >
> > Hopefully that helps :)
> >
> > Alex
> >
> >
> > On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net <mailto:stefan@sriha.net>> wrote:
> > >
> > > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> > >
> > > >> how do you expect your calculator "error out" when you type "1+3" but
> > > meant "1+2"?
> > >
> > > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> > >
> > > 10.0.0.0/24 (that's what iptables assumed I meant)
> > >
> > > or
> > >
> > > 10.0.0.2/32 (or equivalently 10.0.0.2)
> > >
> > > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> > >
> > > In [3]: 3)4
> > >
> > > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> > >
> > > Thanks again for your patience!
> > >
> > > -----Original message-----
> > > From: Reindl Harald
> > > Sent: Friday, June 3 2022, 6:42 pm
> > > To: Stefan Riha
> > > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> > >
> > > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > > But it assumed that when I put in 10.0.0.2/24
> > >
> > > you braindead moron IT CALCULATED
> > >
> > > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> > >
> > > > I actually meant 10.0.0.0/24
> > >
> > > then write it
> > >
> > > > That's possibly dangerous
> > >
> > > operate a firewall as beginner is in generall dangerous
> > >
> > > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> > >
> > > then write it
> > >
> > > > As you said, it can't smell what I meant when I supplied an incorrect
> > > > input. So the right thing would be to error, and not do anything.
> > >
> > > how do you expect your calculator "error out" when you type "1+3" but
> > > meant "1+2"?
> > >
> > > > Instead it re-interprets my incorrect input
> > >
> > > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> > >
> > >
> > >
> >
> >
> > --
> > Alex Buie
> > Senior Networking Software Engineer
> > Datto, Inc.
> > 475-288-4550 (o)
> > 585-653-8779 (c)
> > www.datto.com <http://www.datto.com>
> >
> >
> >
> > Join the conversation!
> 
> -- 
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com <http://www.datto.com>
> 
> Join the conversation!
> 
> 
> 

-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Stefan Riha]

>> Read the manpage: "Address can 
be either a network name, a network IP address (with /mask), or a plain IP 
address".

The manpage states that the input can be either of three:

1) a network name
2) network IP address (with /mask)  (i.e. 10.0.0.0/24 in the example)
3) a plain IP address (i.e. 10.0.0.2 or equivalently 10.0.0.2/32 in the example)

and the input 10.0.0.2/24 is neither of those three (it's a contextually inappropriate combination of 2 and 3). It therefore should be rejected, but instead it is reinterpreted to be of type 2), i.e. a network IP address (with /mask). What do you think?

My point is, I think this re-interpretation dangerous. I think the appropriate behaviour would be to error on incorrect/ambiguous input.

>> The input is interpreted accordingly, therefore 10.0.0.2/24 is 
equal to 10.0.0.0/24.

But would you agree that if the input isn't of the 3 three types explicitly allowed in the manpage, it should be rejected? The word "either" in the manpage gives the impression that the three options are mutually exclusive, and not a contextually inappropriate mixture.

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Jozsef Kadlecsik]

On Sat, 4 Jun 2022, Stefan Riha wrote:

> >> Read the manpage: "Address can 
> be either a network name, a network IP address (with /mask), or a plain IP 
> address".
> 
> The manpage states that the input can be either of three:
> 
> 1) a network name
> 2) network IP address (with /mask)  (i.e. 10.0.0.0/24 in the example)
> 3) a plain IP address (i.e. 10.0.0.2 or equivalently 10.0.0.2/32 in the 
> example)
> 
> and the input 10.0.0.2/24 is neither of those three (it's a contextually 
> inappropriate combination of 2 and 3). It therefore should be rejected, 
> but instead it is reinterpreted to be of type 2), i.e. a network IP 
> address (with /mask). What do you think?
> 
> My point is, I think this re-interpretation dangerous. I think the 
> appropriate behaviour would be to error on incorrect/ambiguous input.
> 
> >> The input is interpreted accordingly, therefore 10.0.0.2/24 is 
> equal to 10.0.0.0/24.
> 
> But would you agree that if the input isn't of the 3 three types 
> explicitly allowed in the manpage, it should be rejected? The word 
> "either" in the manpage gives the impression that the three options are 
> mutually exclusive, and not a contextually inappropriate mixture.

The second form is interpreted as a network IP address and mask. The input 
is normalized by default, so if the IP address is not the network IP 
address, that is automatically converted to it.

You may say that it's not appropriate, dangerous, incorrect. But that is 
how the system works for decades. Nothing can be changed about it, because 
it could break configurations which rely on this behaviour.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Reindl Harald]

Am 04.06.22 um 08:45 schrieb Stefan Riha:
> My point is, I think this re-interpretation dangerous
and my point is when you come up with "I'm a beginner" you should fro 
the sake of go dlisten what people explain and stop using the word 
"interpretation"

binary math != interpretation
damned stop wasting peoples time
your way of communication makes me sick and tired

it won't be changed - live with it or just hire somebody who can but het 
rid of the idea that you are coming out of the blue after 30 years 
changing the world

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Jozsef Kadlecsik]

On Sat, 4 Jun 2022, Reindl Harald wrote:

> Am 04.06.22 um 08:45 schrieb Stefan Riha:
> > My point is, I think this re-interpretation dangerous
> and my point is when you come up with "I'm a beginner" you should fro 
> the sake of go dlisten what people explain and stop using the word 
> "interpretation"
> 
> binary math != interpretation
> damned stop wasting peoples time
> your way of communication makes me sick and tired
> 
> it won't be changed - live with it or just hire somebody who can but het 
> rid of the idea that you are coming out of the blue after 30 years 
> changing the world

There's no need to be hostile, everyone was a newcomer once. It seems 
people can come to wrong conclusions due to the syntax which is used at 
different systems with different internal meanings. The feature cannot of 
course be changed, but maybe it'd worth to update the documentation.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Reindl Harald]

Am 04.06.22 um 15:06 schrieb Jozsef Kadlecsik:
> On Sat, 4 Jun 2022, Reindl Harald wrote:
> 
>> Am 04.06.22 um 08:45 schrieb Stefan Riha:
>>> My point is, I think this re-interpretation dangerous
>> and my point is when you come up with "I'm a beginner" you should fro
>> the sake of go dlisten what people explain and stop using the word
>> "interpretation"
>>
>> binary math != interpretation
>> damned stop wasting peoples time
>> your way of communication makes me sick and tired
>>
>> it won't be changed - live with it or just hire somebody who can but het
>> rid of the idea that you are coming out of the blue after 30 years
>> changing the world
> 
> There's no need to be hostile, everyone was a newcomer once. It seems
> people can come to wrong conclusions due to the syntax which is used at
> different systems with different internal meanings. The feature cannot of
> course be changed, but maybe it'd worth to update the documentation.

the point was if you are a newcomer lisyten what people are telling you 
and when 5 different people on an doff list telling you it's not 
"interpretation" stop repeating yourself again and again

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Stefan Riha]

>> It seems people can come to wrong conclusions due to the syntax which is used at 
different systems with different internal meanings. The feature cannot of 
course be changed, but maybe it'd worth to update the documentation.

I see, are you thinking of adding something like this to the manpage:

-s --source address[/mask][,...]
Source specification. Address can be either a network name, a hostname, a network IP address (with /mask), or a plain IP address. It can also be a plain IP address with /mask, in which case the mask will be applied to the plain IP address to compute the associated network IP address. Note that in the latter case, the plain IP address is automatically reinterpreted (i.e. modified or re-calculated) by the system as a network IP address.

I think this would at least raise attention to a beginner to be cautious. Also, I used the terms "modified" and "re-calculated" as synonyms for "reinterpreted". I get the impression this would be more agreeable to some users?

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Jozsef Kadlecsik]

On Sat, 4 Jun 2022, Stefan Riha wrote:

> >> It seems people can come to wrong conclusions due to the syntax which is used at 
> different systems with different internal meanings. The feature cannot of 
> course be changed, but maybe it'd worth to update the documentation.
> 
> I see, are you thinking of adding something like this to the manpage:
> 
> -s --source address[/mask][,...]

> Source specification. Address can be either a network name, a hostname, 
> a network IP address (with /mask), or a plain IP address. It can also be 
> a plain IP address with /mask, in which case the mask will be applied to 
> the plain IP address to compute the associated network IP address. Note 
> that in the latter case, the plain IP address is automatically 
> reinterpreted (i.e. modified or re-calculated) by the system as a 
> network IP address.

The mask is unconditionally applied to the IP address. Please note, we 
support non-continuous netmasks too. So something like this describes 
better how the input is handled:

-s, --source address[/mask][,...]

Source specification. Address can be either a network name, a hostname, a 
network IP address (with /mask), or a plain IP address. Hostnames will be 
resolved  once  only, before the rule is submitted to the kernel.  Please 
note that specifying any name to be resolved with a remote query such  as 
DNS  is  a  really bad idea.  The mask can be either an ipv4 network mask 
(for iptables) or a plain number, specifying the number  of  1's  at  the 
left  side  of the network mask.  Thus, an iptables mask of 24 is 
equivalent to 255.255.255.0. When specified, the mask always applied to 
the network IP address part before processing the rule. ...

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Stefan Riha]

> The mask is unconditionally applied to the IP address.

Yes. Note again that it is unconditionally applied by other programs too, yet they do not discard the full ip address. When I use 10.0.0.2/24 in the "Address=" keywork of a systemd-networkd configuration, then the the mask is used to compute a prefix route (which is automatically added if not otherwise declared). Yet the full Ip address is kept, and assigned to the nic. My point is that I (as a beginner) would have thought iptables is "smart enough" to figure out that when I submit 10.0.0.2/24 instead of 10.0.0.0/24, then I actually mean 10.0.0.2, and that the additional information that 10.0.0.2 is part of a network 10.0.0.0/24 would be discarded.

> Please note, we support non-continuous netmasks too.

Interesting, I didn't know and had to look up what that is.

> When specified, the mask always applied to the network IP address part before processing the rule.

How about

> When specified, the mask is always applied to the IP address before processing the rule, and the masked-out part of the IP address is subsequently ignored (or "discarded" instead of "ignored").

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Gordon Fisher]

On 6/8/2022 7:34 AM, Stefan Riha wrote:
>> The mask is unconditionally applied to the IP address.
> Yes. Note again that it is unconditionally applied by other programs too, yet they do not discard the full ip address. When I use 10.0.0.2/24 in the "Address=" keywork of a systemd-networkd configuration, then the the mask is used to compute a prefix route (which is automatically added if not otherwise declared). Yet the full Ip address is kept, and assigned to the nic.

This is a different context and meaning than the usage in `iptables`.

In `systemd-networkd`, that is a host address field, not a network 
address field, and that specifying a length, a la 10.0.0.2/24, is short 
hand for configuring IP address 10.0.0.2 with a mask 255.255.255.0 as 
this is for configuring an address on a network interface, which 
normally requires an IP address and a mask pair.

Where as in `iptables`, an address supplied to -d or -s is is a network 
address field that defaults to /32 when no length is specified, which is 
a single address.

It makes all the difference if the field if is a network field or an 
single address field.

-- 
gordonfish

RE: Possibly dangerous interpretation of address/prefix pair in -s option

[Timothy Ham]

Here is an example network that wouldn't work with your proposed "syntax error":

10.0.0.1/25
IP Address:	10.0.0.1
Network Address:	10.0.0.1
Usable Host IP Range:	10.0.0.1 - 10.0.0.126
Broadcast Address:	10.0.0.127

10.0.0.129/25
IP Address:	10.0.0.129
Network Address:	10.0.0.129
Usable Host IP Range:	10.0.0.129 - 10.0.0.254
Broadcast Address:	10.0.0.255

This is a bit convoluted, but are perfectly valid subnets. And in order to specify them, the current behavior is needed.

Cheers,


Sent with Proton Mail secure email.
------- Original Message -------
On Friday, June 3rd, 2022 at 11:23 AM, Stefan Riha <stefan@sriha.net> wrote:


> > > Whoops - just noticed, XOR should be AND in my message. My apologies!
>
>
> No problem:) Thanks for taking the time and answer so comprehensively!
>
> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
>
>
> Hmm, but don't other programs do indeed interpret 10.0.0.2/24 differently? For example systemd-networkd interprets 10.0.0.2/24 as a single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense to me, because why would one specify the .2 at the end, if one meant the subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet itself. In the Wikipedia article about Ip addresses [1] it says:
>
> > > For example, the destination address used for directed broadcast to devices on the network 192.0.2.0/24 is 192.0.2.255.
>
>
> So they too interpret 192.0.2.0/24 as the network, and 192.0.2.255 as broadcast address, my point being that those two Ip addresses (i.e. beginning and end of the subnet) have two special meanings, the former representing the network.
>
> I guess my impression is that other user space programs (e.g. systemd-networkd), interpret 10.0.0.2/24 as pair: a single ip address and a mask identifying the corresponding subnet. I am confused that iptables picks one of them without telling me to be more specific.
>
> Why would a user space program not take advantage of that fact and unambiguously accept 10.0.0.0/24 to specify that specific subnet, and nothing else?
>
>
> [1] https://en.wikipedia.org/wiki/IP_address
>
> -----Original message-----
> From: Alex Buie
> Sent: Friday, June 3 2022, 7:30 pm
> To: Stefan Riha
> Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
> Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
>
> Whoops - just noticed, XOR should be AND in my message. My apologies!
>
> On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com mailto:alex.buie@datto.com> wrote:
>
> > Underneath, it's all just binary math.
> > Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> > their binary representation.
> >
> > EG:
> > 10.0.0.0: 00001010.00000000.00000000.00000000
> > 10.0.0.2: 00001010.00000000.00000000.00000010
> >
> > Then you are providing a bitmask (the /24 or /32 part) to tell the
> > kernel which parts of the address should be checked for matching.
> >
> > /24: 11111111.11111111.11111111.00000000
> > /32: 11111111.11111111.11111111.111111111
> >
> > The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> > make sure the first 24 bits match 10.0.0.2".
> >
> > 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> > 2- /24: 11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
> >
> > 1- 10.0.0.2: 00001010.00000000.00000000.00000010
> > 2- /24: 11111111.11111111.11111111.00000000
> > ---------------------------------------------------------------
> > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
> >
> > Result 1 == Result 2, so the source match passes.
> >
> > This is functionally equivalent to telling the kernel "allow all of
> > 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
> >
> > There is no reinterpretation going on - the rule is simply being
> > processed exactly as you added it, and the behavior you suggest would
> > be introducing reinterpretation.
> >
> > Hopefully that helps :)
> >
> > Alex
> >
> > On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net mailto:stefan@sriha.net> wrote:
> >
> > > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> > >
> > > > > how do you expect your calculator "error out" when you type "1+3" but
> > > > > meant "1+2"?
> > >
> > > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> > >
> > > 10.0.0.0/24 (that's what iptables assumed I meant)
> > >
> > > or
> > >
> > > 10.0.0.2/32 (or equivalently 10.0.0.2)
> > >
> > > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> > >
> > > In [3]: 3)4
> > >
> > > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> > >
> > > Thanks again for your patience!
> > >
> > > -----Original message-----
> > > From: Reindl Harald
> > > Sent: Friday, June 3 2022, 6:42 pm
> > > To: Stefan Riha
> > > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> > >
> > > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > >
> > > > But it assumed that when I put in 10.0.0.2/24
> > >
> > > you braindead moron IT CALCULATED
> > >
> > > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> > >
> > > > I actually meant 10.0.0.0/24
> > >
> > > then write it
> > >
> > > > That's possibly dangerous
> > >
> > > operate a firewall as beginner is in generall dangerous
> > >
> > > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> > >
> > > then write it
> > >
> > > > As you said, it can't smell what I meant when I supplied an incorrect
> > > > input. So the right thing would be to error, and not do anything.
> > >
> > > how do you expect your calculator "error out" when you type "1+3" but
> > > meant "1+2"?
> > >
> > > > Instead it re-interprets my incorrect input
> > >
> > > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> >
> > --
> > Alex Buie
> > Senior Networking Software Engineer
> > Datto, Inc.
> > 475-288-4550 (o)
> > 585-653-8779 (c)
> > www.datto.com http://www.datto.com
> >
> > Join the conversation!
>
>
> --
> Alex Buie
> Senior Networking Software Engineer
> Datto, Inc.
> 475-288-4550 (o)
> 585-653-8779 (c)
> www.datto.com http://www.datto.com
>
>
> Join the conversation!

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[pigi]

I think you are wrong:
10.0.0.1/25
IP Address:	10.0.0.1
Network Address:	10.0.0.0  <====== It's "0", not "1"
Usable Host IP Range:	10.0.0.1 - 10.0.0.126
Broadcast Address:	10.0.0.127

10.0.0.129/25
IP Address:	10.0.0.129
Network Address:	10.0.0.128  <===== It's "128" not "129"
Usable Host IP Range:	10.0.0.129 - 10.0.0.254
Broadcast Address:	10.0.0.255

In iptables notation, 10.0.0.1/25 should sound as "syntax error" ( and so should 10.0.0.129/25) 

Just my 2 cents.

Pigi


On Saturday, June 4, 2022 1:37:57 AM CEST Timothy Ham wrote:
> Here is an example network that wouldn't work with your proposed "syntax error":
> 
> 10.0.0.1/25
> IP Address:	10.0.0.1
> Network Address:	10.0.0.1
> Usable Host IP Range:	10.0.0.1 - 10.0.0.126
> Broadcast Address:	10.0.0.127
> 
> 10.0.0.129/25
> IP Address:	10.0.0.129
> Network Address:	10.0.0.129
> Usable Host IP Range:	10.0.0.129 - 10.0.0.254
> Broadcast Address:	10.0.0.255
> 
> This is a bit convoluted, but are perfectly valid subnets. And in order to specify them, the current behavior is needed.
> 
> Cheers,
> 
> 
> Sent with Proton Mail secure email.
> ------- Original Message -------
> On Friday, June 3rd, 2022 at 11:23 AM, Stefan Riha <stefan@sriha.net> wrote:
> 
> 
> > > > Whoops - just noticed, XOR should be AND in my message. My apologies!
> >
> >
> > No problem:) Thanks for taking the time and answer so comprehensively!
> >
> > > There is no reinterpretation going on - the rule is simply being
> > > processed exactly as you added it, and the behavior you suggest would
> > > be introducing reinterpretation.
> >
> >
> > Hmm, but don't other programs do indeed interpret 10.0.0.2/24 differently? For example systemd-networkd interprets 10.0.0.2/24 as a single Ip address in the subnet 10.0.0.0/24. Which makes a lot of sense to me, because why would one specify the .2 at the end, if one meant the subnet? There is the unambiguous 10.0.0.0/24 to identify the subnet itself. In the Wikipedia article about Ip addresses [1] it says:
> >
> > > > For example, the destination address used for directed broadcast to devices on the network 192.0.2.0/24 is 192.0.2.255.
> >
> >
> > So they too interpret 192.0.2.0/24 as the network, and 192.0.2.255 as broadcast address, my point being that those two Ip addresses (i.e. beginning and end of the subnet) have two special meanings, the former representing the network.
> >
> > I guess my impression is that other user space programs (e.g. systemd-networkd), interpret 10.0.0.2/24 as pair: a single ip address and a mask identifying the corresponding subnet. I am confused that iptables picks one of them without telling me to be more specific.
> >
> > Why would a user space program not take advantage of that fact and unambiguously accept 10.0.0.0/24 to specify that specific subnet, and nothing else?
> >
> >
> > [1] https://en.wikipedia.org/wiki/IP_address
> >
> > -----Original message-----
> > From: Alex Buie
> > Sent: Friday, June 3 2022, 7:30 pm
> > To: Stefan Riha
> > Cc: netfilter@vger.kernel.org; h.reindl@thelounge.net
> > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> >
> > Whoops - just noticed, XOR should be AND in my message. My apologies!
> >
> > On Fri, Jun 3, 2022 at 1:28 PM Alex Buie <alex.buie@datto.com mailto:alex.buie@datto.com> wrote:
> >
> > > Underneath, it's all just binary math.
> > > Even though you enter 10.0.0.0 or 10.0.0.2, they are converted to
> > > their binary representation.
> > >
> > > EG:
> > > 10.0.0.0: 00001010.00000000.00000000.00000000
> > > 10.0.0.2: 00001010.00000000.00000000.00000010
> > >
> > > Then you are providing a bitmask (the /24 or /32 part) to tell the
> > > kernel which parts of the address should be checked for matching.
> > >
> > > /24: 11111111.11111111.11111111.00000000
> > > /32: 11111111.11111111.11111111.111111111
> > >
> > > The /24 at the end tells the kernel "allow 10.0.0.2, but only check to
> > > make sure the first 24 bits match 10.0.0.2".
> > >
> > > 1- 10.0.0.50: 00001010.00000000.00000000.00110010
> > > 2- /24: 11111111.11111111.11111111.00000000
> > > ---------------------------------------------------------------
> > > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 1)
> > >
> > > 1- 10.0.0.2: 00001010.00000000.00000000.00000010
> > > 2- /24: 11111111.11111111.11111111.00000000
> > > ---------------------------------------------------------------
> > > XOR 1 with 2 00001010.00000000.00000000.00000000 (result 2)
> > >
> > > Result 1 == Result 2, so the source match passes.
> > >
> > > This is functionally equivalent to telling the kernel "allow all of
> > > 10.0.0" as 10.0.0 is the contents of the first 24 bits of 10.0.0.2
> > >
> > > There is no reinterpretation going on - the rule is simply being
> > > processed exactly as you added it, and the behavior you suggest would
> > > be introducing reinterpretation.
> > >
> > > Hopefully that helps :)
> > >
> > > Alex
> > >
> > > On Fri, Jun 3, 2022 at 1:08 PM Stefan Riha <stefan@sriha.net mailto:stefan@sriha.net> wrote:
> > >
> > > > Sorry - I just realized I did not send the messages to the netfilter list, but replied to Reindl Harald directly. Harald patiently makes the point that
> > > >
> > > > > > how do you expect your calculator "error out" when you type "1+3" but
> > > > > > meant "1+2"?
> > > >
> > > > I'm not sure I understand the analogy, because 1+3 is correct and unambiguous input. Why would the program then invent a different meaningful input, say "1+2"? Instead, 10.0.0.2/24 for the -s option is ambiguous (and I would argue incorrect), because the correct inputs should have been
> > > >
> > > > 10.0.0.0/24 (that's what iptables assumed I meant)
> > > >
> > > > or
> > > >
> > > > 10.0.0.2/32 (or equivalently 10.0.0.2)
> > > >
> > > > The latter is what I actually meant. I guess the question is, why does iptables re-interpret an incorrect (ambiguous) input, and not error? 10.0.0.2/24 makes no sense, right? Picking up the calculator analogy: if I open a python terminal, and type
> > > >
> > > > In [3]: 3)4
> > > >
> > > > python errors due to syntax error. It doesn't just re-intepret it to '3+4' or '3-4'
> > > >
> > > > Thanks again for your patience!
> > > >
> > > > -----Original message-----
> > > > From: Reindl Harald
> > > > Sent: Friday, June 3 2022, 6:42 pm
> > > > To: Stefan Riha
> > > > Subject: Re: Possibly dangerous interpretation of address/prefix pair in -s option
> > > >
> > > > Am 03.06.22 um 18:36 schrieb Stefan Riha:
> > > >
> > > > > But it assumed that when I put in 10.0.0.2/24
> > > >
> > > > you braindead moron IT CALCULATED
> > > >
> > > > 10.0.0.2/24 is for a computer similar to "1+2" for a human
> > > >
> > > > > I actually meant 10.0.0.0/24
> > > >
> > > > then write it
> > > >
> > > > > That's possibly dangerous
> > > >
> > > > operate a firewall as beginner is in generall dangerous
> > > >
> > > > > because what I actually meant was 10.0.0.2 (or equivalently 10.0.0.2/32).
> > > >
> > > > then write it
> > > >
> > > > > As you said, it can't smell what I meant when I supplied an incorrect
> > > > > input. So the right thing would be to error, and not do anything.
> > > >
> > > > how do you expect your calculator "error out" when you type "1+3" but
> > > > meant "1+2"?
> > > >
> > > > > Instead it re-interprets my incorrect input
> > > >
> > > > FUCK IT - it DID NOT interprete - IT IT A CALCULATION
> > >
> > > --
> > > Alex Buie
> > > Senior Networking Software Engineer
> > > Datto, Inc.
> > > 475-288-4550 (o)
> > > 585-653-8779 (c)
> > > www.datto.com http://www.datto.com
> > >
> > > Join the conversation!
> >
> >
> > --
> > Alex Buie
> > Senior Networking Software Engineer
> > Datto, Inc.
> > 475-288-4550 (o)
> > 585-653-8779 (c)
> > www.datto.com http://www.datto.com
> >
> >
> > Join the conversation!
> 

Re: Possibly dangerous interpretation of address/prefix pair in -s option

[Gordon Fisher]

On 6/3/2022 11:23 AM, Stefan Riha wrote:
> Hmm, but don't other programs do indeed interpret 10.0.0.2/24 
> differently? For example systemd-networkd interprets 10.0.0.2/24 as a 
> single Ip address in the subnet 10.0.0.0/24. Which makes a lot of 
> sense to me, because why would one specify the .2 at the end, if one 
> meant the subnet?

I would say that it depends on context; that is, what the parameter is 
supposed to be. Is it meant to specify single address, a network, or either?

In the your systemd-networkd example, IIRC, that is supposed to be a 
single IP address, and `10.0.0.2/24` is a short hand for entering 
`10.0.0.2` and `255.255.255.0` for a network interface.

Another example that comes to mind where context matters, is the older 
`route` command (that predates `ip route`), which has `-host` and `-net` 
arguments for `route add` commands, that tell the program whether to 
interpret the address part as a network based on the mask given, or as a 
single host (where the mask can be omitted.)

`ip route` on the other hand just goes by the mask given similar to `-s` 
and `-d` in `iptables`, where it really just does as it is told: check 
this address according to the given mask. And like `iptables`, assumes 
/32 if no mask is given.

-- 
gordonfish