security impact of creating rulesets with iptables (cmd)

security impact of creating rulesets with iptables (cmd)

[Christoph A.]

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

Hi,

I read Jan's "Towards the perfect ruleset" paper [1]

[1] http://jengelh.medozas.de/documents/Perfect_Ruleset.pdf

and I would have a question about the mentioned security risk when
creating hole rulesets with the iptables command (chapter 3).

I understand why it is a bad idea to create n rules by using multiple
times iptables -A... (instead of iptables-restore) because it
"downloads" the entire table n-times and sets the entire table n-times
(performing n*2 operations) while passing n^2 rules between kernel and
userspace.

The second and more interesting point is that this would also introduce
a timeframe where packets could slip through while these exchanges
between kernel and userspace are happening. Why does setting the policy
to DROP not solve this problem?

I asume these commands are processed from top to bottom, I couldn't
imagine of a opportunity when packets could slip through

example
(presuming an empty INPUT chain)

1: iptables -P INPUT DROP
2: iptables -A INPUT -s 10.0.0.0/8 -j DROP
3: iptables -A INPUT -p tcp --dport 22 --syn -j ACCEPT

After (1) the chain would be empty
after (2):
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 DROP     all  --  *      *       10.0.0.0/8
0.0.0.0/0

(3):
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source
destination
    0     0 DROP     all  --  *      *       10.0.0.0/8
0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0
0.0.0.0/0           tcp dpt:22

I'm not using iptables -A sequences in scripts anymore but would be
curious about this security risk anyway.

curious
Christoph A.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: security impact of creating rulesets with iptables (cmd)

[Jan Engelhardt]

On Sunday 2009-08-09 23:43, Christoph A. wrote:
>
>and I would have a question about the mentioned security risk when 
>creating hole rulesets with the iptables command (chapter 3).
>
>The second and more interesting point is that this would also introduce 
>a timeframe where packets could slip through while these exchanges 
>between kernel and userspace are happening. Why does setting the policy 
>to DROP not solve this problem?
>
>I asume these commands are processed from top to bottom, I couldn't 
>imagine of a opportunity when packets could slip through

Even if you manage to avoid temporary Windows Of Opportunity For 
Attackers does not mean all novice users are able to do the same. Hence 
it is easier to just use iptables-restore and need not worry about 
atomicity within a given table.

Assume this poor_user's script. It's got policies-first that you deem 
the ultimate solution, and still there is a window of opportunity.

#!/bin/sh
iptables -P INPUT DROP
iptables -A INPUT -p esp -j ACCEPT
iptables -P FORWARD DROP
iptables -A FORWARD -m policy --tunnel-src $remote_vpn_peer -o eth1 -j ACCEPT

Of course you could also make this specific one opportunity-window-free, 
but my mathematical gut tells me there's always a way to thwart the 
user's smartness by another ruleset. A circular dependency is the 
"easiest example" to always have a hole, tho I am not going to try and 
construct a scientifically-sound case and proof of that right now.

Re: security impact of creating rulesets with iptables (cmd)

[Christoph A.]

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

On 10.08.2009 00:18, Jan Engelhardt wrote:
> Even if you manage to avoid temporary Windows Of Opportunity For 
> Attackers does not mean all novice users are able to do the same. Hence 
> it is easier to just use iptables-restore and need not worry about 
> atomicity within a given table.

thanks for your fast reply!
Christoph A.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: security impact of creating rulesets with iptables (cmd)

[Patrick McHardy]

Christoph A. wrote:
> Hi,
> 
> I read Jan's "Towards the perfect ruleset" paper [1]
> 
> [1] http://jengelh.medozas.de/documents/Perfect_Ruleset.pdf
> 
> and I would have a question about the mentioned security risk when
> creating hole rulesets with the iptables command (chapter 3).
> 
> I understand why it is a bad idea to create n rules by using multiple
> times iptables -A... (instead of iptables-restore) because it
> "downloads" the entire table n-times and sets the entire table n-times
> (performing n*2 operations) while passing n^2 rules between kernel and
> userspace.
> 
> The second and more interesting point is that this would also introduce
> a timeframe where packets could slip through while these exchanges
> between kernel and userspace are happening. Why does setting the policy
> to DROP not solve this problem?

This is not correct, the replacement is atomic.

Re: security impact of creating rulesets with iptables (cmd)

[Jan Engelhardt]

On Monday 2009-08-10 08:58, Patrick McHardy wrote:
>> 
>> The second and more interesting point is that this would also introduce
>> a timeframe where packets could slip through while these exchanges
>> between kernel and userspace are happening. Why does setting the policy
>> to DROP not solve this problem?
>
>This is not correct, the replacement is atomic.

(Elaborating on this.) The _replacement_ itself is indeed atomic,
the issue arises when a table is in place that allows something
that is later restricted again by a new table update.

1. iptables -A INPUT -p esp -j ACCEPT
2. echo 'Possibly open from here on...'
3. iptables -P FORWARD DROP
4. echo 'Now closed again'

Now if you have a large ruleset, and RT preemption, or lots of CPUs,
or an overly busy system, etc., it may take "longer than usual" until
step 3 is in effect.