ipv4options still broken (posted prev w/ no reply)...

ipv4options still broken (posted prev w/ no reply)...

[Cody Tubbs]

While we're on the nth match topic and speaking of broken modules in
pom, I posted a couple of weeks ago about the lsrr and ssrr options
being broken in the ipv4options module.  I had dialog with Fabrice, but
it seems he doesn't have time to maintain the module anymore, or at
least fix this issue.  It's giving everyone who is using it a false
sense of security, being that it loads, but doesn't do anything when an
lsrr/ssrr ip option is set and passes through the module.  Can this be
removed until it's fixed?  lsrr and ssrr are critical ip options to
monitor attempting to enter your network, and people using this module
thinking/expecting it to work can possibly get compromised via its lack
of mojo.  Thanks.

ps, testing with hping3 is a quick method to determine if changes
worked.
http://www.hping.org/download.html
(a simple command line tool that allows you to set lsrr/ssrr ip options,
among other things.)


-Cody Tubbs

Re: ipv4options still broken (posted prev w/ no reply)...

[Patrick McHardy]

Cody Tubbs wrote:
> While we're on the nth match topic and speaking of broken modules in
> pom, I posted a couple of weeks ago about the lsrr and ssrr options
> being broken in the ipv4options module.  I had dialog with Fabrice, but
> it seems he doesn't have time to maintain the module anymore, or at
> least fix this issue.  It's giving everyone who is using it a false
> sense of security, being that it loads, but doesn't do anything when an
> lsrr/ssrr ip option is set and passes through the module.  Can this be
> removed until it's fixed?  lsrr and ssrr are critical ip options to
> monitor attempting to enter your network, and people using this module
> thinking/expecting it to work can possibly get compromised via its lack
> of mojo.  Thanks.

I somehow doubt that this is really a threat, but feel free to send
a patch to disable those two options until fixed.

Re: ipv4options still broken (posted prev w/ no reply)...

[Cody Tubbs]

I'm not going to indulge in 101 stuff regarding loose/strict source 
attacks, google enjoys 101 much more.

http://www.spirit.com/Network/net0300.html (section: Source Route)

http://seclists.org/lists/pen-test/2003/May/0023.html

Patch coming soon.

-Cody Tubbs


On Tue, 2006-05-30 at 21:22 +0200, Patrick McHardy wrote:
> Cody Tubbs wrote:
> > While we're on the nth match topic and speaking of broken modules in
> > pom, I posted a couple of weeks ago about the lsrr and ssrr options
> > being broken in the ipv4options module.  I had dialog with Fabrice, but
> > it seems he doesn't have time to maintain the module anymore, or at
> > least fix this issue.  It's giving everyone who is using it a false
> > sense of security, being that it loads, but doesn't do anything when an
> > lsrr/ssrr ip option is set and passes through the module.  Can this be
> > removed until it's fixed?  lsrr and ssrr are critical ip options to
> > monitor attempting to enter your network, and people using this module
> > thinking/expecting it to work can possibly get compromised via its lack
> > of mojo.  Thanks.
> 
> I somehow doubt that this is really a threat, but feel free to send
> a patch to disable those two options until fixed.

Re: ipv4options still broken (posted prev w/ no reply)...

[Patrick McHardy]

Cody Tubbs wrote:
> I'm not going to indulge in 101 stuff regarding loose/strict source 
> attacks, google enjoys 101 much more.
> 
> http://www.spirit.com/Network/net0300.html (section: Source Route)
> 
> http://seclists.org/lists/pen-test/2003/May/0023.html

Which system accepts source route options nowadays? You most likely
have more serious problems than this.

Re: ipv4options still broken (posted prev w/ no reply)...

[Patrick McHardy]

tubbs@wispdirect.com wrote:
> D-link and netgear had issues not too long ago for one.  Presumptions are the
> root of stupidity

Just send me the patch without annoying me and I'll apply it.

Re: ipv4options still broken (posted prev w/ no reply)...

[Patrick Schaaf]

On Wed, May 31, 2006 at 01:46:07AM +0200, Patrick McHardy wrote:
> tubbs@wispdirect.com wrote:
> > D-link and netgear had issues not too long ago for one.  Presumptions are the
> > root of stupidity
> 
> Just send me the patch without annoying me and I'll apply it.

Patrick, at the risk of annoying you some more: the attitude you showed
in this thread, is very annoying in itself. While your work on netfilter
is really deeply appreciated, slight-of-hand security evaluations like
you showed here, are not.

Maybe you just need to get some more sleep. I hope so.

best regards
  Patrick

Re: ipv4options still broken (posted prev w/ no reply)...

[Patrick McHardy]

Patrick Schaaf wrote:
> On Wed, May 31, 2006 at 01:46:07AM +0200, Patrick McHardy wrote:
> 
> Patrick, at the risk of annoying you some more: the attitude you showed
> in this thread, is very annoying in itself. While your work on netfilter
> is really deeply appreciated, slight-of-hand security evaluations like
> you showed here, are not.
> 
> Maybe you just need to get some more sleep. I hope so.

I don't like beeing lectured. Linux drops all source route
options anyway, so this entire discussion is absolutely
pointless.

Re: ipv4options still broken (posted prev w/ no reply)...

[Cody Tubbs]

What about in a bridged firewall situation, you're saying Linux will
strip these ip options out while forwarding? automatically?  Is this
something that can be turned on or off?

but oh wait, I forgot...
Why does tcpdump show these ip options still attached even when not
forwarding? :) (latest kernel) heh++

On the contrary, you simply asked me who still supports these ip options
and I gave you a minimal list, thus if giving you an answer is annoying,
this thread must be an act of pissing in the wind. 

-Cody Tubbs


On Wed, 2006-05-31 at 15:55 +0200, Patrick McHardy wrote:
> Patrick Schaaf wrote:
> > On Wed, May 31, 2006 at 01:46:07AM +0200, Patrick McHardy wrote:
> > 
> > Patrick, at the risk of annoying you some more: the attitude you showed
> > in this thread, is very annoying in itself. While your work on netfilter
> > is really deeply appreciated, slight-of-hand security evaluations like
> > you showed here, are not.
> > 
> > Maybe you just need to get some more sleep. I hope so.
> 
> I don't like beeing lectured. Linux drops all source route
> options anyway, so this entire discussion is absolutely
> pointless.
> 

Re: ipv4options still broken (posted prev w/ no reply)...

[Patrick McHardy]

Cody Tubbs wrote:
> What about in a bridged firewall situation, you're saying Linux will
> strip these ip options out while forwarding? automatically?  Is this
> something that can be turned on or off?
> 
> but oh wait, I forgot...
> Why does tcpdump show these ip options still attached even when not
> forwarding? :) (latest kernel) heh++

I never said anything about stripping, but you're right that bridging
will happily forward them.

> On the contrary, you simply asked me who still supports these ip options
> and I gave you a minimal list, thus if giving you an answer is annoying,
> this thread must be an act of pissing in the wind. 

Its very simple, just keep things like "101 something", "root of
stupidity" and "heh++" to yourself and you'll make a much better
impression. Until then I choose to ignore you.

Re: ipv4options still broken (posted prev w/ no reply)...

[Cody Tubbs]

Or maybe possibly restrain from presuming every system or device on the
market today handles these options accordingly, and acting as if I'm
ignorant for even bringing it up.  You vent via arrogant remarks, same
bowl, different soup.  But indeed, you do have the ability to ignore,
the same ability you used before when responding to this thread
regarding the true topic at hand.  Nothing you quoted me on was in my
initial emails, the first one yesterday, or the one two weeks ago'ish.
Only post your arrogance.

Also, like Patrick stated, we appreciate the work, but being treated
ignorantly when stating bugs to a dev list is uncalled for. Period.

Bottom line is, it would be nice to -j LOG these options passing through
or attempting to be passed through a bridged firewall.  It details
malicious activity, thus deterring that fact into a presumption that "I
most likely have more serious problems" was blatantly absurd.

-Cody Tubbs 


On Wed, 2006-05-31 at 20:39 +0200, Patrick McHardy wrote:
> Cody Tubbs wrote:
> > What about in a bridged firewall situation, you're saying Linux will
> > strip these ip options out while forwarding? automatically?  Is this
> > something that can be turned on or off?
> > 
> > but oh wait, I forgot...
> > Why does tcpdump show these ip options still attached even when not
> > forwarding? :) (latest kernel) heh++
> 
> I never said anything about stripping, but you're right that bridging
> will happily forward them.
> 
> > On the contrary, you simply asked me who still supports these ip options
> > and I gave you a minimal list, thus if giving you an answer is annoying,
> > this thread must be an act of pissing in the wind. 
> 
> Its very simple, just keep things like "101 something", "root of
> stupidity" and "heh++" to yourself and you'll make a much better
> impression. Until then I choose to ignore you.
> 

Re: ipv4options still broken (posted prev w/ no reply)...

[Patrick McHardy]

Cody Tubbs wrote:
> Bottom line is, it would be nice to -j LOG these options passing through
> or attempting to be passed through a bridged firewall.  It details
> malicious activity, thus deterring that fact into a presumption that "I
> most likely have more serious problems" was blatantly absurd.

As I already said, please just send me your patch to disable or even
better fix this behaviour and I'm going to apply it. If you really want
to do something useful, please just fix the ipv4options match to be
acceptable for kernel inclusion. So far, it does stupid things like
using seperate flags for option negation and it depends on IP option
metadata provided by the IP layer, which doesn't work for bridging.
The last point BTW really is a good example why random crap from POM
shouldn't be trusted.