[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090416172432.78d35a57@redhat.com>
Date: Thu, 16 Apr 2009 17:24:32 +0200
From: Tomas Hoger <thoger@...hat.com>
To: wietse@...cupine.org
Cc: oss-security@...ts.openwall.com, coley@...us.mitre.org
Subject: Re: Re: Some fun with tcp_wrappers
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?
> 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.
--
Tomas Hoger / Red Hat Security Response Team
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.
