Bug 363541

(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

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 "?".

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.

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.

(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.

(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.

(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.

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.

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.

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.

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