Re: CAIS-ALERT: Vulnerability in the sending requests control of BIND

From: Robert Tracz (rtracz@tele.pw.edu.pl)
Date: 12/02/02

  • Next message: Vagner Sacramento: "RE: CAIS-ALERT: Vulnerability in the sending requests control of BIND" 
    Date: Mon, 2 Dec 2002 14:02:01 +0100 (CET)
From: Robert Tracz <rtracz@tele.pw.edu.pl>
To: core.lists.bugtraq@core-sdi.com

    Hi Ivan,

    Ivn Arce wrote:
    >>>+ /*
    >>>+ * The 16 bit space is very small and brute force attempts are
    >>>+ * entirly feasible, we skip a random number of transaction ids
    >>>+ * so that an attacker will not get sequential ids.
    >>>+ */
    >>
    >>Using only brute force, the attack is very difficult to be applied. I
    >>tried this several times. I did several tests in my experiments. The
    >>probability of success is very low to get implement the attack using
    >>only brute force.
    >
    >
    > The probability of sucess is exactly:
    > m-responses-sent/65535
    > If I sent 65535 DNS responses with a different ID on each one one of
    > then will hit the right ID.
    >
    > The attack is basically the same.
    > Either you sent N spoofed requests or you send M spoofed responses.
    > The network traffic generated is also the same and in both cases
    > there is still a race to win against the real DNS.

     As far as I understand the issue Vagner is right at this point. The
    birthday paradox comes into play: If you send m requests and m
    responses the probability of collision is:

    p = 1 - 65535*(65535-1)*(65535-2)*...*(65535-m+1)/65535^m

    In practice, if you send m = 256 responses and requests you have already
    p = 39.2%, while if you would send 1 request and 511 responses (the
    same traffic burden) you would get only p = 0.77%. And sending m = 1024
    requests and responses gives you probability of success p = 99.9%.

    However I agree with you that it would be better to enhance the
    protocol.

    Regards,

    Robert

     

    Relevant Pages

    • Re: So called "stimulus/response" models
      ... Instead of answering to each misunderstood, ironic and out of context ... Sorry, you exhibit a simplistic view of probability theory, and an even more ... of acquiring the consequences of responses. ... distribution over consequences of a given act. ...
      (comp.ai.philosophy)
    • Re: Good God, What Happened to this Group?
      ... doing and that I've fallen into the habit of reading responses to my posts. ... > Cabbi I hope you'll take his words to heart, as this would be a much ... support still comes through. ... but I can't abide blind items of attack from one member ...
      (alt.support.chronic-pain)
    • Re: Mixed Sync/Async communications pattern
      ... responses, but someone may already have solved the problem. ... after which the requests gathered so far would be sent off in a ... into a dict or similar. ... proc something:real {state env} { ...
      (comp.lang.tcl)
    • IDS responses
      ... I'm currently trying to learn about the different repsonses an IDS can ... responses can traditionally be divided into two ... the attack is carried out, ... As seen above the SNMP Trap explanation is not satisafctory. ...
      (Focus-IDS)
    • Re: So called "stimulus/response" models
      ... claiming that all learning is operant conditioning. ... of acquiring the consequences of responses. ... distribution over consequences of a given act. ... Sorry, you exhibit a simplistic view of probability theory, and an even more ...
      (comp.ai.philosophy)
    • Quantcast