Bug 363541 - New L.ROOT-SERVERS.NET address
New L.ROOT-SERVERS.NET address
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: bind (Show other bugs)
4.5
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Tkac
:
Depends On: 363531
Blocks: 363551
  Show dependency treegraph
 
Reported: 2007-11-02 05:35 EDT by Adam Tkac
Modified: 2013-04-30 19:37 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2008-0708
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-24 15:53:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Tkac 2007-11-02 05:35:40 EDT
+++ This bug was initially created as a clone of Bug #363531 +++

Description of problem:
L.ROOT-SERVERS.NET have new address. caching-nameserver package has to be updated

Version-Release number of selected component (if applicable):
9.3.3-10
Comment 1 Adam Tkac 2007-11-02 05:47:38 EDT
(In reply to comment #0)
> +++ This bug was initially created as a clone of Bug #363531 +++
> 
> Description of problem:
> L.ROOT-SERVERS.NET have new address. caching-nameserver package has to be updated
> 
> Version-Release number of selected component (if applicable):
> 9.3.3-10

caching-nameserver exists only in RHEL5 . But We also need update some pieces in
bind
Comment 2 RHEL Product and Program Management 2008-02-01 13:59:46 EST
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 4 RHEL Product and Program Management 2008-03-13 09:27:54 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 9 Dan Harkless 2008-05-19 16:23:10 EDT
Shouldn't this be higher than "low" severity given the spoofing discussed at
<http://www.renesys.com/blog/2008/05/identity_theft_hits_the_root_n_1.shtml>?  I
guess the particular spoofers discussed in the article have been shut down, but
that doesn't necessarily mean someone else won't start spoofing the old IP.
Comment 10 Adam Tkac 2008-05-20 08:51:42 EDT
(In reply to comment #9)
> Shouldn't this be higher than "low" severity given the spoofing discussed at
> <http://www.renesys.com/blog/2008/05/identity_theft_hits_the_root_n_1.shtml>?  I
> guess the particular spoofers discussed in the article have been shut down, but
> that doesn't necessarily mean someone else won't start spoofing the old IP.

Problem isn't so hot as looks from message written above. BIND uses root hints
only as hints. When it is started it loads root zone from one of the root
servers and uses it. So it has to hit wrong IP and on that IP spoofed DNS server
has to respond with wrong root zone. We decided this is not really high severity
problem.
Comment 11 Tomasz Ostrowski 2008-05-21 02:21:35 EDT
(In reply to comment #10)

> Problem isn't so hot as looks from message written above. BIND uses root hints
> only as hints. When it is started it loads root zone from one of the root
> servers and uses it. So it has to hit wrong IP and on that IP spoofed DNS
> server has to respond with wrong root zone. We decided this is not really
> high severity problem.

There's a 1/13 chance for it to hit a spoofed server when it is started. And
this server could respond with everything, for example that every root server is
his address. And then every domain for this 1/13 of users could be compromised.
I think this is a very high chance of successful attack and I do not understand
how is it not a serious security issue.
Comment 12 Adam Tkac 2008-05-21 03:39:19 EDT
(In reply to comment #11)
> There's a 1/13 chance for it to hit a spoofed server when it is started. And
> this server could respond with everything, for example that every root server is
> his address. And then every domain for this 1/13 of users could be compromised.
> I think this is a very high chance of successful attack and I do not understand
> how is it not a serious security issue.

Yes, now problem become important. Let me explain why we decided not release
this update as security update.
When change of IP of L root server was announced (1st November 2007) ICANN said
that old IP should be available at least 6 months so we decided to release this
update in 5.2 (which should be available today). If we had have information that
ICANN doesn't honor their information "6 months at least" we have had reacted
differently. But when information about L root spoofing comes to me one day
before 5.2 GA it doesn't make sence release security update when standard update
is going to be released today.
Comment 14 Adam Tkac 2008-05-21 06:25:26 EDT
Ok, I wrote some confusions in comments #10 and #12 because I thought this bug
is against RHEL5, not RHEL4, my fault. I'm going to discuss with our security
team how act in RHEL4 case.
Comment 15 Tomas Hoger 2008-05-28 06:46:59 EDT
The Red Hat Security Response Team do not view this issue as being a
current security threat as the old IP address is controlled by a
trusted party.  We therefore advise a 'bug fix' and not a 'security
update'.

The issue itself may need to be addressed on following places:
- bind - Source code contains hard-coded list of root server IPs that
  is used if configuration does not define root zone.
- caching-nameserver - Configuration-only package that provides
  configuration skeleton as well as root zone definition file.  Users
  are expected to use configuration in this package as base for their
  own bind configurations.

Current status:
- IP address is changed on both places in Red Hat Enterprise Linux 5
  bind and caching-nameserver packages.
- IP address hard-coded in bind is planned to be changed in the
  upcoming Red Hat Enterprise Linux 4.7 update.
- Configuration in caching-nameserver packages on Red Hat Enterprise
  Linux 2.1, 3, and 4 is currently outdated.

Given the important role of the DNS systems in the infrastructure of
the today's Internet, asynchronous RHBA/RHEA for configuration-only
caching-nameserver package on Red Hat Enterprise Linux 2.1, 3, and 4
will be considered.
Comment 16 Tomas Hoger 2008-05-28 07:25:36 EDT
Bugfix of caching-namerserver packages on Red Hat Enterprise Linux 2.1, 3 and 4
proposed in bugs: bug #448703, bug #448707 and bug #448708.
Comment 17 errata-xmlrpc 2008-07-24 15:53:43 EDT
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 therefore 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-2008-0708.html

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