COMMAND

    BIND

SYSTEMS AFFECTED

    Systems runnig BIND described as below

PROBLEM

    Alan Brown posted following about vulnerability on bind.  If an  A
    record is assigned  with leading zeros  to pad out  the number and
    make  it  slightly  easier  to  throw  through  sort, the assigned
    number goes wonky.  Example of this follows:

        fubar IN A 202.50.64.125 = 202.50.64.125

        fubar IN A 202.050.64.125 = 202.40.52.125

        fubar IN A 1.2.3.4 = 1.2.3.4

        fubar IN A 001.002.003.004 = 1.2.3.4

    As can be seen, it only happens with one padding 0.  If there  are
    2 it's fine and  (I assume) that's why  it's not been notified  up
    till now.

    Alan used static  assignments for his  dialin users and  they were
    setting off stacks of alarms  as they accessed the pop  port until
    he realised what'd happend and back out the changes.

    The other  problem would  be that  IPs which  had been locked from
    getting offsite may have been able to get out, but also they  were
    so whacked out that nothing will come back.

    RFC  1035  is  quite  explicit  that  the dotted quad format is in
    DECIMAL.   (RFC 1035,  section 3.4.1).   This RFC  is obseleted by
    RFC 2065,  but that  RFC makes  no mention  of A  records at  all,
    concentrating more on security aspects of DNS.

    If RFC  1035 holds,  then either  the specification  of an A field
    needs to  be updated  or Bind  does. if  not, then  RFC 2065 needs
    revising to specify all the items covered in the RFC it obseletes.

SOLUTION

    Use two padding 0.  So far... not expert on this one.