> well, this bothers me a bit. I feel unable to confirm for myself if
> there is a problem or not, so could someone please tell whether there
> is problem with ipf that makes a remote exploit possible, or not? Or
> which version of OBSD do I take to avoid such a problem?
"remote exploit" is overly harsh.
There are two security issues corrected by the recently posted ipf
erratum (www.openbsd.org/errata.html and errata26.html)
1) Using "keep state" rules unsafely (not specifying any TCP flags)
in conjunction with "return-rst" rules could poke a hole in your
ruleset. This is easy to avoid.
DON'T DO THIS:
pass out quick proto tcp from any to any keep state
block return-rst in quick proto tcp from any to any
See that "keep state" with no TCP flags specified? That means a
state entry can be generated for ANY outgoing packet, including the
RST generated by the second rule.
If you use keep-state, ALWAYS DO THIS:
pass out quick proto tcp from any to any flags S keep state
See that "flags S"? That means state rules are only generated for
connections initiated by you, inside your firewall.
There's other ways to avoid the problem, too, but the key is the
unsafe use of "keep state". Why would you want an outgoing ACK packet
to create a state entry? or an ACK-FIN? Always use flags S, and
you have no worries.
3.3.16 (the errata patch) addresses this, too. outgoing RSTs no longer
generate state. (in fact, they aren't processed by the firewall at all).
Still. Change your rules anyway if you're doing things the unsafe way.
2) (2.6 users only) An attacker on a local network segment (local
ethernet, no intervening routers) could send a packet containing a
misaligned timestamp option. This is invalid, and would be dropped by
any intervening routers, but someone on the local segment could do
it. It could cause the firewall to crash. This probably only
affected people running ipf in bridging mode.
This issue was fixed in 3.3.14 (included in 2.7)
Two performance (stability) fixes were also included in the patch for
2.6 (hence the jumbo patch). 3.3.16 fixes many problems with the
stability of the in-kernel FTP proxy, and one issue with ipmon logging.
> In a different posting there was a remark about the FTP proxy module.
> Could you please provide more details?
The in-kernel FTP proxy has a habit of crashing. I am told it is much
better now. I _still_ recommend using a userland proxy, like ftp-gw from
the fwtk, or the one from Juniper (www.obtuse.com). If you don't
want to fool around with ipnat redirects, you can also use an external
proxy server (like squid running outside your firewall). All of this
makes MUCH more sense that simulating a wacky TCP protocol at the IP
layer.
-kj
|