Re: [PATCH] Add RES_OPTIONS support for resolv.conf options overriding

[Rich Felker <dalias@libc.org>]

On Tue, Apr 25, 2017 at 04:30:58AM +0000, Stefan Sedich wrote:
> Rich,
> 
> I will make the change, but so I understand some more what would be the
> implications of not ignoring it in this scenario? I understand why it is
> bad in the case of the load paths for example but just want to understand
> the issue in this context.

Primarily it's just a general principle of safety. A few specific
attacks I can think of here, though:

1. By manipulating ndots, you could cause a privileged process to
lookup the wrong domain.

2. By controlling timeout and retries, you could widen the window for
dns spoofing attacks.

Neither of these should lead to privilege-elevation if proper
authentication is used (dns alone is not sufficient to authenticate a
server to a client without dnssec), but lots of stuff is not written
to be safe...

BTW, please reply inline/below on lists rather than top-posting.

Rich



> On Mon, Apr 24, 2017 at 7:50 PM Kurt H Maier <khm@sdf.org> wrote:
> 
> > On Mon, Apr 24, 2017 at 10:39:34PM -0400, Rich Felker wrote:
> > >
> > > What I'd really like is a way for users to override nameserver and
> > > search directives (so pretty much, all of resolv.conf) in a way that
> > > doesn't need root; this would be really valuable for testing. But
> > > sadly there's no precedent for an interface to do so. Maybe it's
> > > something we could work on a unified solution to with other
> > > implementations (glibc, bsds?).
> > >
> > > Rich
> >
> > FreeBSD and OpenBSD both currently support RES_OPTIONS (and LOCALDOMAIN
> > for overriding the search directive) but I don't think they support
> > overriding the nameserver directive.  There's just the HOSTALIASES
> > variable for pointing to a file full of 'alias hostname' pairs.
> >
> > khm
> >