[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090416154805.3E0351F3E9E@spike.porcupine.org>
Date: Thu, 16 Apr 2009 11:48:05 -0400 (EDT)
From: wietse@...cupine.org (Wietse Venema)
To: Tomas Hoger <thoger@...hat.com>
CC: wietse@...cupine.org, oss-security@...ts.openwall.com,
coley@...us.mitre.org
Subject: Re: Re: Some fun with tcp_wrappers
Tomas Hoger:
> Hi Wietse!
>
> On Thu, 16 Apr 2009 07:59:20 -0400 (EDT) wietse@...cupine.org (Wietse
> Venema) wrote:
>
> > Tomas Hoger:
> > > The good_client (tcp_wrappers wrapping function in portmap /
> > > nfs-utils / ...) problem is rather interesting too, as it creates
> > > problems due to its attempt to avoid unneeded DNS lookups
> > > (workaround for hosts_ctl limitation?) and support host aliases
> > > (tcp_wrappers limitation).
> >
> > See my previous email. Programs such as portmappers must not look
> > up hostname information, since that would result in an infinite
> > recursion when host lookups use SUNRPC services. To state the
> > obvious: the portmapper would directly or indirectly send SUNRPC
> > calls to itself, in order to locate the NIS server.
>
> Thank you for pointing this problem out. And my apologies for not
> digging deep enough into peculiarities of RPC and making a conclusions
> based on the code already used in the wild. It seems that portmappers
> do name resolution, even if they should not.
>
> Current upstream portmap code has a compile-time option that enables
> name resolution (along with proper warnings):
> http://neil.brown.name/git?p=portmap;a=commitdiff;h=b663f78b86
>
> but the variants of this (buggy) patch without such ENABLE_DNS define
> and proper warnings are used in the wild. Additionally, portmap also
> has an explicit check for local access and does not call tcp_wrappers
> at all in such case, probably to avoid the problem you have mentioned.
> Is there a case when even that is insufficient?
I worked last on this program 13 years ago. If I recall correctly
the from_local() test will avoid certain screwups, but a full
analysis will take time, and I am short on that.
Wietse
> > Before discussing changes to a program, it is a good investment of
> > time to find out how the program works, and why it works in the
> > specific way it works.
>
> I obviously erred on this! Though with code being copied across
> projects, getting changes that are not always correct, or copying
> special handling to projects where it is not needed, makes it rather
> complicated to not miss some whys or always distinguish correct changes
> from incorrect ones. Nobody has perfect knowledge of everything, that's
> when objective feedback from subject experts is greatly appreciated and
> desired to not miss any gotchas and have all pros and cons to make the
> decision.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
