Bug 253392 - telnetd refuses connections if nameserver(s) down
telnetd refuses connections if nameserver(s) down
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: telnet (Show other bugs)
5.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
: EasyFix, Patch
: 232020 244022 248063 (view as bug list)
Depends On: 223448
Blocks: 246139 246258 266601 274971 296411
  Show dependency treegraph
 
Reported: 2007-08-18 15:42 EDT by Jose Plans
Modified: 2013-04-30 19:37 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHBA-2007-1012
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 09:33:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
netkit-telnet-0.17-nodns.patch (1.75 KB, patch)
2007-08-18 15:42 EDT, Jose Plans
no flags Details | Diff
Fix use of ipv6 name lookups (1.33 KB, patch)
2007-09-03 07:30 EDT, Bryn M. Reeves
no flags Details | Diff
don't call perror on things that are not errnos (617 bytes, patch)
2007-09-03 07:32 EDT, Bryn M. Reeves
no flags Details | Diff

  None (edit)
Description Jose Plans 2007-08-18 15:42:20 EDT
+++ This bug was initially created as a clone of Bug #223448 +++

Description of problem:
telnetd refuses connections if nameserver(s) down or not configured

Version-Release number of selected component (if applicable):
telnet-server-0.17-37
glibc-2.5-3

How reproducible:
either disconnect nameservers from network or delete /etc/resolv.conf
telnet into server from a client not listed in /etc/hosts

Steps to Reproduce:
1. on FC6 server
  rm /etc/resolv.conf #or disconnect nameservers from network

2. on a client machine not listed in /etc/hosts on server
  telnet fc6_machine 
  
Actual results:
$ telnet grima
Trying 10.51.21.10...
Connected to grima.
Escape character is '^]'.
getnameinfo: localhost: Success
Temporary failure in name resolution: Illegal seek
Connection closed by foreign host.

Expected results:
$ telnet grima
Trying 10.51.21.10...
Connected to grima.
Escape character is '^]'.
Fedora Core release 6 (Zod)
Kernel 2.6.18-1.2798.fc6 on an i686
login:

Additional info:
This bug is due to a change in the glibc getnameinfo function, see bug 221583
and bug 204122.
If a nameserver is not available, getnameinfo now returns the EAI_AGAIN
error(even when the NI_NAMEREQD flag is not set) rather than returning the IP
address as a string as it used to.

-- Additional comment from atkac@redhat.com on 2007-04-11 12:38 EST --
Very similar to bug #223452, patch could be based on rlogind's patch. I'm going
to take care about this one

-A-

-- Additional comment from atkac@redhat.com on 2007-04-13 05:17 EST --
I've created proposed fix. Could you test it, please?
http://people.redhat.com/atkac/test_srpms/telnet-0.17-38.fc7.src.rpm

Regards, Adam

-- Additional comment from jfaith@cemsys.com on 2007-04-13 07:58 EST --
Yes, that seems to work fine, thanks.
The -c option is not mentioned in the manual page though.

But I would just like to confirm that the option is needed.
I'm afraid I'm still not convinced that doing this second lookup if EAI_AGAIN is
returned reduces security. EAI_AGAIN only happens if the nameserver is down or
not configured. 

If the nameserver is working and the client does not have a reverse DNS entry
the first call to getnameinfo will return the IP address in string form(with no
error), so telnetd/rlogind have to handle that situation anyway.

If you are certain the hostname MUST be available when the -c option is NOT used
then you need to use NI_NAMEREQD in the flags argument to the first getnameinfo
call. In which case the second call will need to be done if the error returned
is EAI_NONAME or EAI_AGAIN and the -c option is used. But I don't think this is
a good idea.

I believe all of this is caused by a change to the implementation of the
getnameinfo function see bug #221583 and #204122.

I think the better option is to do the second getnameinfo call if the error is
EAI_AGAIN even it the nodns option is not set. I think this covers up the
problem with the getnameinfo implementation.

Sorry, if I'm not being clear here or missing something but I'm just not getting it.

-- Additional comment from atkac@redhat.com on 2007-04-13 08:26 EST --
(In reply to comment #3)
> Yes, that seems to work fine, thanks.
> The -c option is not mentioned in the manual page though.

Be sure that you're looking at correct manpage (you must see "man in.telnetd",
not only telnetd because this is different version of telnet daemon)

I'm not expert about security so better is create new option than create
security hole :)

-A-

-- Additional comment from jfaith@cemsys.com on 2007-04-13 10:14 EST --
You are correct man in.telnetd does mention the -c option, my bad.

relevant section:-
 -c           This option disables reverse dns checking. Of course that
              security is lower with this option

Just to be picky, should it not be 'Of course the' rather than 'Of Course that'.

Mind you I'm not convinced security is lower but fair enough re your decision to
err on the side of caution(seldom a bad move).
Comment 1 Jose Plans 2007-08-18 15:42:21 EDT
Created attachment 161807 [details]
netkit-telnet-0.17-nodns.patch
Comment 3 Adam Tkac 2007-08-31 04:28:39 EDT
*** Bug 248063 has been marked as a duplicate of this bug. ***
Comment 5 Adam Tkac 2007-09-03 04:49:09 EDT
*** Bug 232020 has been marked as a duplicate of this bug. ***
Comment 6 Adam Tkac 2007-09-03 04:49:39 EDT
*** Bug 244022 has been marked as a duplicate of this bug. ***
Comment 7 Bryn M. Reeves 2007-09-03 07:30:08 EDT
Created attachment 185181 [details]
Fix use of ipv6 name lookups

Attaching the patches I wrote back in March when this was first raised as bug
232020

These do not change the command line interface or add global variables, they
also don't require the administrator to explicitly configure the telnet daemon
to work correctly with no DNS server defined/reachable.
Comment 8 Bryn M. Reeves 2007-09-03 07:32:14 EDT
Created attachment 185191 [details]
don't call perror on things that are not errnos

Fix another bug exposed by this one - telnetd trying to pass getaddrinfo return
values off as errnos.
Comment 15 errata-xmlrpc 2007-11-15 09:33:57 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-1012.html

Note You need to log in before you can comment on or make changes to this bug.