Skip Menu |

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 96608
Status: resolved
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: Mark.Martinec [...] ijs.si
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.77
Fixed in: (no value)



Subject: "Insecure dependency in connect" with Net::DNS::Resolver over TCP
$ perl -T -MNet::DNS::Resolver -le ' $r=Net::DNS::Resolver->new(usevc=>1); $r->send("_spf.google.com","TXT")' Insecure dependency in connect while running with -T switch at /usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115. (same happens without usevc=>1 on an automatic UDP->TCP fallback when a returned record is truncated)
From: rwfranks [...] acm.org
On Fri Jun 20 20:09:00 2014, Mark.Martinec@ijs.si wrote: Show quoted text
> $ perl -T -MNet::DNS::Resolver -le ' > $r=Net::DNS::Resolver->new(usevc=>1); $r->send("_spf.google.com","TXT")' > > Insecure dependency in connect while running with -T switch > at /usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115. > > (same happens without usevc=>1 on an automatic UDP->TCP fallback > when a returned record is truncated)
That does not happen for me. Where are the nameserver addresses coming from? RES_NAMESERVERS ? /etc/resolv.conf ? ./.resolv.conf ?
Subject: Re: [rt.cpan.org #96608] "Insecure dependency in connect" with Net::DNS::Resolver over TCP
Date: Sat, 21 Jun 2014 16:36:46 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Show quoted text
> That does not happen for me.
It was reported on the amavis mailing list (not sure what version they were running), and I can reproduce it on several of my machines (perl 5.20), but not on all. Net::DNS 0.76 or 0.77 Show quoted text
> Where are the nameserver addresses coming from? > > RES_NAMESERVERS ?
No. Show quoted text
> /etc/resolv.conf ?
Yes: $ cat /etc/resolv.conf search ijs.si. nameserver 2001:1470:ff80::53:247 nameserver 2001:1470:ff80::53:248 or (on another): $ cat /etc/resolv.conf search ijs.si nameserver ::1 Show quoted text
> ./.resolv.conf ?
No. Mark
From: rwfranks [...] acm.org
On Sat Jun 21 10:37:01 2014, Mark.Martinec@ijs.si wrote: Show quoted text
> > That does not happen for me.
> > It was reported on the amavis mailing list (not sure what version > they were running), and I can reproduce it on several of my machines > (perl 5.20), but not on all. Net::DNS 0.76 or 0.77 >
> > Where are the nameserver addresses coming from? > > > > /etc/resolv.conf ?
> > Yes: > > $ cat /etc/resolv.conf > search ijs.si. > nameserver 2001:1470:ff80::53:247 > nameserver 2001:1470:ff80::53:248 >
So, data read from the external /etc/resolv.conf is tainted. The taint propagates all the way through to the socket code. Question: Should /etc/resolv.conf receive some special priviledge as trustworthy material and therefore untainted? If yes, then user-specified config files should receive the same treatment. This is to make certain that: $res = new Net::DNS::Resolver(); and $res = new Net::DNS::Resolver( config_file => '/etc/resolv.conf' ); both produce exactly the same result. If no, untainting should be applied to user-specified config files only. Users would then be required either to provide their own config file or refer explicitly to /etc/resolv.conf as above.
Subject: Re: [rt.cpan.org #96608] "Insecure dependency in connect" with Net::DNS::Resolver over TCP
Date: Mon, 23 Jun 2014 14:00:15 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Show quoted text
> So, data read from the external /etc/resolv.conf is tainted. > The taint propagates all the way through to the socket code.
Yes. With version 0.74 and earlier data fields from resolv.conf were blindly laundered in read_config_file() (as long as the field is non-empty). This brings up an interesting question: why does an *UDP* query *not* fail for the same reason? Unintentional laundering somewhere else? Show quoted text
> Question: Should /etc/resolv.conf receive some special privilege as > trustworthy material and therefore untainted?
Yes. Same for $HOME/.resolv.conf Show quoted text
> If yes, then user-specified config files should receive the same > treatment.
Yes for explicitly specified config files. (I still claim that reading .resolv from a cwd can be a security hole (checking ownership does not help), but that is a subject of some other PR).
From: rwfranks [...] acm.org
On Mon Jun 23 08:00:41 2014, Mark.Martinec@ijs.si wrote: Show quoted text
> > So, data read from the external /etc/resolv.conf is tainted. > > The taint propagates all the way through to the socket code.
> > Yes. With version 0.74 and earlier data fields from resolv.conf > were blindly laundered in read_config_file() (as long as the field > is non-empty). >
Which was clearly not right. Show quoted text
> This brings up an interesting question: why does an *UDP* query > *not* fail for the same reason? Unintentional laundering somewhere else? >
Don't know the answer to that one. Perhaps we need to find out. Show quoted text
> > Question: Should /etc/resolv.conf receive some special privilege as > > trustworthy material and therefore untainted?
> > Yes.
I happen to disagree, but accept that it is debatable. Interestingly, old versions have been very inconsistent about whether they accept /etc/resolv.conf with -T flag, so we cannot appeal to historical precedent. Show quoted text
> ... Same for $HOME/.resolv.conf >
No. Just as bad as ./.resolv.conf Show quoted text
> > If yes, then user-specified config files should receive the same > > treatment.
> > Yes for explicitly specified config files. >
Show quoted text
> (I still claim that reading .resolv from a cwd can be a security > hole (checking ownership does not help), but that is a subject of > some other PR). >
./.resolv.conf and $HOME/.resolv.conf should be regarded as tainted. These will not be read if user provides a config file. IMHO, security sensitive users should turn on -T and supply an explicit config file (which might be /etc/resolv.conf). The onus is then on the user to make sure that a malicious actor cannot modify the specified file. With this model, we would always ignore all the other places that bad stuff can come from.
Subject: Re: [rt.cpan.org #96608] "Insecure dependency in connect" with Net::DNS::Resolver over TCP
Date: Thu, 26 Jun 2014 15:46:07 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
The current 'solution' in trunk is not right (r1222, 0.77+), it does not solve the problem. Show quoted text
>> This brings up an interesting question: why does an *UDP* query >> *not* fail for the same reason? Unintentional laundering somewhere >> else?
> Don't know the answer to that one. Perhaps we need to find out.
It turns out that the perl builtin function send() does not check for taintedness of its fourth argument (TO). Show quoted text
>> > Question: Should /etc/resolv.conf receive some special privilege as >> > trustworthy material and therefore untainted?
>> Yes.
> I happen to disagree, but accept that it is debatable.
It is not possible for an application to guard itself against the operating system. If one cannot trust the underlying operating system and its basic settings, then any attempts to do so are futile and can be circumvented. The purpose of taint checks is to protect against untrusted data from the wild, not from the operating system and its basic settings. Show quoted text
> If no, untainting should be applied to user-specified config files > only. > Users would then be required either to provide their own config file or > refer > explicitly to /etc/resolv.conf as above.
An application should not need to know where the system's recursive resolvers configuration is located. The exact location is OS-specific and that logic is already built into Net::DNS. An application should not need to replicate that code. Requiring to explicitly specify a config file in Net::DNS::Resolver->new() is unacceptable. The system-default should suffice for most needs. Show quoted text
> IMHO, security sensitive users should turn on -T and supply an > explicit config file (which might be /etc/resolv.conf).
Even the less security sensitive should turn on the -T option, but should still work with a default setup. It is not possible to selectively turn off taint checking within a perl block or module. If an application happens to use Net::DNS (e.g. in one of its library modules, using a default configuration), it is not acceptable that taint checks need to be globally disabled just because Net::DNS version 0.75 or 0.76 or 0.77 happens to be installed on the system. Show quoted text
> Interestingly, old versions have been very inconsistent about whether > they > accept /etc/resolv.conf with -T flag, so we cannot appeal to historical > precedent.
0.49 OK 0.53 OK 0.59 OK 0.61 OK 0.62 OK 0.63 OK 0.64 OK 0.65 OK 0.66 OK 0.67 OK 0.68 OK 0.69 OK 0.70 OK 0.71 OK 0.72 OK 0.73 OK 0.74 OK 0.75 Insecure dependency in connect 0.76 Insecure dependency in connect 0.77 Insecure dependency in connect I wouldn't call it inconsistent. To me it looks like a breakage in 0.75. It is not acceptable that an application would fail depending on a size of a DNS response (TC flag): $ perl -T -MNet::DNS::Resolver -le '$r=Net::DNS::Resolver->new; $r->send("spop1024._domainkey.ealert.nature.com","TXT") or print "OK"' OK $ perl -T -MNet::DNS::Resolver -le '$r=Net::DNS::Resolver->new; $r->send("20120113._domainkey.gmail.com","TXT") or print "OK"' Insecure dependency in connect while running with -T switch at /usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115. The UDP and TCP queries should be subject to the same criteria.
From: rwfranks [...] acm.org
Show quoted text
> I wouldn't call it inconsistent. To me it looks like a breakage in 0.75.
I do not see things that way at all. Neither am I convinced by your experimental evidence. Taint propagation appears to have been broken in 0.68 and fixed again in 0.75. So now it *is* fixed, it is going to stay fixed. $ perl -T -I/home/rwf/src/Net-DNS-0.20/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.25/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.30/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.40/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.50/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.60/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.65/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.66/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.67/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.68/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.69/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.70/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.71/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.72/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.73/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.74/lib/. test.pl taint not detected $ perl -T -I/home/rwf/src/Net-DNS-0.75/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.76/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115. $ perl -T -I/home/rwf/src/Net-DNS-0.77/lib/. test.pl Insecure dependency in connect while running with -T switch at /usr/lib/perl5/IO/Socket.pm line 115.
Subject: Re: [rt.cpan.org #96608] "Insecure dependency in connect" with Net::DNS::Resolver over TCP
Date: Sat, 28 Jun 2014 02:55:55 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Show quoted text
> Neither am I convinced by your experimental evidence. > > Taint propagation appears to have been broken in 0.68 and fixed again > in 0.75. So now it *is* fixed, it is going to stay fixed.
This was my test (using perl 5.20.0) which produced my results across all the versions of Net::DNS that I could find since 0.49: for j in Net-DNS-0.??; do (cd $j; echo; echo $j; perl Makefile.PL; make install; perl -T -MNet::DNS::Resolver -le 'print Net::DNS->VERSION; $r=Net::DNS::Resolver->new(usevc=>1); $r->send("_spf.google.com","TXT"); print "\nOK\n\n"'; sleep 5; make clean); done
From: rwfranks [...] acm.org
One of us has a problem with the experiment, but it is not obvious what it is. However, perhaps we do not need to solve that problem in order to reach a conclusion. If your result is right, untainting /etc/resolv.conf is the right way to go. If my result is right, the decision is, at best, split 50-50. Way forward: /etc/resolv.conf untainted $HOME/.resolv.conf tainted ./.resolv.conf tainted Environment variables always tainted Security sensitive users provide their own config file.
Subject: Re: [rt.cpan.org #96608] "Insecure dependency in connect" with Net::DNS::Resolver over TCP
Date: Sun, 29 Jun 2014 02:28:20 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Show quoted text
> One of us has a problem with the experiment, but it is not obvious what > it is.
I have repeated my experiment (perl 5.20.0, on FreeBSD 10.0), this time with some additional checking for receiving a valid DNS answer, and avoiding to manually force a TCP query but relying on a long DNS reply with a TC flag set and automatic failover by Net::DNS to re-do a query over TCP. I have also specified a single IPv4 nameserver in my /etc/resolv.conf, just in case (previously I had two IPv6 entries there). ... ... essentially all the same as previously, just avoiding some potential traps. # for j in Net-DNS-0.??.tar.gz; do echo $j; tar xf $j; ( cd ${j%.tar.gz}; perl Makefile.PL; make; make install; perl -T -MNet::DNS -MNet::DNS::Resolver -le ' $|=1; print "\n\n----- ",Net::DNS->VERSION; $a=Net::DNS::Resolver->new->send("20120113._domainkey.gmail.com","TXT") or die "Err: $!"; print "OK: ",$a->string'; make clean ); done 2>&1 | tee 0.log # egrep '^----- |OK: ;; Answer received|Insecure' 0.log (just manually inserting a newline before every version for clarity): ----- 0.49 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.53 ----- 0.59 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.61 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.62 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.63 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.64 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.65 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.66 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.67 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.68 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.69 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.70 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.71 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.72 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.73 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.74 OK: ;; Answer received from 193.2.4.247 (605 bytes) ----- 0.75 Insecure dependency in connect while running with -T switch at /usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115. ----- 0.76 Insecure dependency in connect while running with -T switch at /usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115. ----- 0.77 Insecure dependency in connect while running with -T switch at /usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115. The version 0.53 didn't provide any answer (and didn't fail either), but I didn't investigate, as it's nine years old anyway. So the result matches my previous experiment, versions 0.49 to 0.74 are happy with a default setup, versions 0.75, 0.76 and 0.77 fail. Show quoted text
> However, perhaps we do not need to solve that problem in order to > reach a conclusion. > > If your result is right, untainting /etc/resolv.conf is the right way > to go.
I think it is the right thing to do. Btw, there shouldn't be any differences between getting the information from /etc/resolv.conf or from a Windows registry, both sources hold trusted system's settings (unless system has been compromised or seriously misconfigured, in which case anything can happen anyway). Show quoted text
> Way forward: > /etc/resolv.conf untainted
Ok. Show quoted text
> $HOME/.resolv.conf tainted > ./.resolv.conf tainted > Environment variables always tainted
I don't care much for these, although I think that if such a setup is already known to fail eventually when an application happens to stumble over a DNS reply with a TC flag set, then it would be better to fail right away with some sensible diagnostic, or just disallow $HOME/.resolv.conf and /.resolv.conf and document the change. Leaving an application to its chances of eventually stumbling over such DNS answer and failing at some 'random' time is not polite. Still, there shouldn't be a difference (regarding trustworthiness of name server sources) between a DNS query over UDP vs. TCP. Show quoted text
> Security sensitive users provide their own config file.
Right, or just use a system default.
From: rwfranks [...] acm.org
On Sat Jun 28 20:28:37 2014, Mark.Martinec@ijs.si wrote: Show quoted text
> > One of us has a problem with the experiment, but it is not obvious what > > it is.
> > I have repeated my experiment (perl 5.20.0, on FreeBSD 10.0)
Good work, thanks. Show quoted text
> Btw, there shouldn't be any differences between getting the > information from /etc/resolv.conf or from a Windows registry, >
Possibly, but off-topic here. Show quoted text
>
> > Way forward: > > /etc/resolv.conf untainted
>
Fixed in 0.78 Show quoted text
>
> > $HOME/.resolv.conf tainted > > ./.resolv.conf tainted > > Environment variables always tainted
> > I don't care much for these, >
Neither do I, but they have their uses. Show quoted text
> , or just disallow > $HOME/.resolv.conf and /.resolv.conf and document the change. >
Not going to happen. Show quoted text
> Leaving an application to its chances of eventually stumbling > over such DNS answer and failing at some 'random' time is not > polite. > > Still, there shouldn't be a difference (regarding trustworthiness > of name server sources) between a DNS query over UDP vs. TCP. >
Different issue; arguably UDP should fail in the same way as TCP. There is no quick fix for this, but it is well worth investigating. Show quoted text
>
> > Security sensitive users provide their own config file.
> > Right, or just use a system default. >
Not "just use" but "deliberately use" system default. $res = new Net::DNS::Resolver( config_file => '/etc/resolv.conf' ); Provides untainted config and does not read ${HOME}/.resolv.conf, ./.resolv.conf or environment variables.
Subject: Re: [rt.cpan.org #96608] "Insecure dependency in connect" with Net::DNS::Resolver over TCP
Date: Fri, 11 Jul 2014 13:09:47 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Mark Martinec <Mark.Martinec [...] ijs.si>
Show quoted text
>> Still, there shouldn't be a difference (regarding trustworthiness >> of name server sources) between a DNS query over UDP vs. TCP. >>
> Different issue; arguably UDP should fail in the same way as TCP. > There is no quick fix for this, but it is well worth investigating.
Already investigated, as reported earlier: perl decided that it does not care if arguments to a send() builtin are tainted, in particular its forth argument (TO). Show quoted text
>>> Security sensitive users provide their own config file.
>> Right, or just use a system default.
> Not "just use" but "deliberately use" system default. > $res = new Net::DNS::Resolver( config_file => '/etc/resolv.conf' );
It is wrong that an application would need to know the exact OS-specific location of its list of default resolvers (Unix vs Windows vs OpenVMS vs whatever). That's what a library (or a perl module) is there for - and in fact the Net::DNS already does so. It makes no sense that an application would need to re-do and duplicate the reconnaissance efforts on its environment. The need for config_file => '/etc/resolv.conf' is not portable. Some other mechanism should be provided to select (only) a system's default set of resolvers.
From: rwfranks [...] acm.org
On Fri Jul 11 07:10:10 2014, Mark.Martinec@ijs.si wrote: [snip] Show quoted text
> Already investigated, as reported earlier: perl decided that > it does not care if arguments to a send() builtin are tainted, > in particular its forth argument (TO).
If so, I guess we will have to live with it. Latest incarnation (in 0.79) now behaves as follows: /etc/resolv.conf untainted $HOME/.resolv.conf tainted ~/.resolv.conf tainted Environment variables tainted Windows registry untainted Show quoted text
> It is wrong that an application would need to know the exact > OS-specific location of its list of default resolvers (Unix vs > Windows vs OpenVMS vs whatever).
Disagree. Secure systems requirements specify explicitly where all the information comes from, *including* "standard" config files. Supplying a custom config file fulfils that requirement, and excludes all other sources of config information. Show quoted text
> It makes no sense that an application would need to re-do and > duplicate the reconnaissance efforts on its environment. >
but then you cannot meet the above security requirement because some other party specified where the config information comes from. Show quoted text
> The need for config_file => '/etc/resolv.conf' is not portable. > Some other mechanism should be provided to select (only) a system's > default set of resolvers. >
Not possible without a radical re-write of the resolver.
From: rwfranks [...] acm.org
On Thu Jun 26 09:46:33 2014, Mark.Martinec@ijs.si wrote: [snip] Show quoted text
> It turns out that the perl builtin function send() does not check > for taintedness of its fourth argument (TO).
We would all be happier if it did. [snip] Show quoted text
> The UDP and TCP queries should be subject to the same criteria.
Agree. Plan B added to trunk this very day.