Another BIND vulnerability (cache poisoning) - VMS

This is a discussion on Another BIND vulnerability (cache poisoning) - VMS ; Slashdot article: http://it.slashdot.org/article.pl?sid=08/07/08/195225 Offfical CERT article: http://www.kb.cert.org/vuls/id/800113 The CERT announcement only goes by company name, and there is no status from HP. At least Microsoft has quickly acklnowledged that its virus collection software known as Windows is vulnerable. Alpha VMS ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 72

Thread: Another BIND vulnerability (cache poisoning)

  1. Another BIND vulnerability (cache poisoning)

    Slashdot article:
    http://it.slashdot.org/article.pl?sid=08/07/08/195225

    Offfical CERT article:
    http://www.kb.cert.org/vuls/id/800113


    The CERT announcement only goes by company name, and there is no status
    from HP. At least Microsoft has quickly acklnowledged that its virus
    collection software known as Windows is vulnerable.

    Alpha VMS hjas Bind 9. VAX-VMS is Bond 8, but then HP has never
    acknowledged/provided any "vulnerable/not-vulnerable status for the many
    BIND-8 issues over the years.

  2. Re: Another BIND vulnerability (cache poisoning)

    JF Mezei wrote:
    > Slashdot article:
    > http://it.slashdot.org/article.pl?sid=08/07/08/195225
    >
    > Offfical CERT article:
    > http://www.kb.cert.org/vuls/id/800113


    Test can be made at www.doxpara.com

    Essentially, what it does is cause a number of separate DNS requests to
    be made to their own DNS server and they check if each DNS request was
    made FROM a different port or not. If they all come from the same port,
    it deems the DNS server to be vulnerable.

    I used wireshark to trace the VMS TCPIP Services 5.6 (Bind 9) server
    while running this test and the 5 requests all came from the same port.


    My ISP has already patched their Linux servers.

    Anyone know if a patch is/will be available for TCPIP Services 5.6 ?

    Or is this something that the remaining VMS installed based doesn't care
    much about because they are enterprise systems not connected to the
    internet ?



  3. Re: Another BIND vulnerability (cache poisoning)

    On Jul 9, 9:35 am, JF Mezei wrote:
    > JF Mezei wrote:
    > > Slashdot article:
    > >http://it.slashdot.org/article.pl?sid=08/07/08/195225

    >
    > > Offfical CERT article:
    > >http://www.kb.cert.org/vuls/id/800113

    >
    > Test can be made atwww.doxpara.com
    >
    > Essentially, what it does is cause a number of separate DNS requests to
    > be made to their own DNS server and they check if each DNS request was
    > made FROM a different port or not. If they all come from the same port,
    > it deems the DNS server to be vulnerable.
    >
    > I used wireshark to trace the VMS TCPIP Services 5.6 (Bind 9) server
    > while running this test and the 5 requests all came from the same port.
    >
    > My ISP has already patched their Linux servers.
    >
    > Anyone know if a patch is/will be available for TCPIP Services 5.6 ?
    >
    > Or is this something that the remaining VMS installed based doesn't care
    > much about because they are enterprise systems not connected to the
    > internet ?


    I'm not sure why being "not connected to the internet" helps in this
    case (or in many other cases) as there too many uncontrolled leakage
    paths to the Internerd in many corporates these days anyway (and there
    often were even before the days of 3G phones and widespread laptops).

    Anyway, if I've understood right, this is an instance of "defective by
    design" in BIND. an error in BIND which djb (of djbdns and qmail fame)
    first talked about with CERT back in 2002, and first discussed in
    public by djb himself in 2001: http://cr.yp.to/djbdns/forgery.html

    As of December 2007 djbdns is in the public domain, so managers of
    commodity OSes on commodity hardware may well have an easy BIND-
    independent fix. No idea whether a VMS version is available.

  4. Re: Another BIND vulnerability (cache poisoning)

    On 9 Jul, 17:54, johnwalla...@yahoo.co.uk wrote:
    > On Jul 9, 9:35 am, JF Mezei wrote:
    >
    >
    >
    > > JF Mezei wrote:
    > > > Slashdot article:
    > > >http://it.slashdot.org/article.pl?sid=08/07/08/195225

    >
    > > > Offfical CERT article:
    > > >http://www.kb.cert.org/vuls/id/800113

    >
    > > Test can be made atwww.doxpara.com

    >
    > > Essentially, what it does is cause a number of separate DNS requests to
    > > be made to their own DNS server and they check if each DNS request was
    > > made FROM a different port or not. If they all come from the same port,
    > > it deems the DNS server to be vulnerable.

    >
    > > I used wireshark to trace the VMS TCPIP Services 5.6 (Bind 9) server
    > > while running this test and the 5 requests all came from the same port.

    >
    > > My ISP has already patched their Linux servers.

    >
    > > Anyone know if a patch is/will be available for TCPIP Services 5.6 ?

    >
    > > Or is this something that the remaining VMS installed based doesn't care
    > > much about because they are enterprise systems not connected to the
    > > internet ?

    >
    > I'm not sure why being "not connected to the internet" helps in this
    > case (or in many other cases) as there too many uncontrolled leakage
    > paths to the Internerd in many corporates these days anyway (and there
    > often were even before the days of 3G phones and widespread laptops).
    >
    > Anyway, if I've understood right, this is an instance of "defective by
    > design" in BIND. an error in BIND which djb (of djbdns and qmail fame)
    > first talked about with CERT back in 2002, and first discussed in
    > public by djb himself in 2001:http://cr.yp.to/djbdns/forgery.html
    >
    > As of December 2007 djbdns is in the public domain, so managers of
    > commodity OSes on commodity hardware may well have an easy BIND-
    > independent fix. No idea whether a VMS version is available.


    Note that the MS patch for this breaks zonealarm. So you have a
    choice. remove this patch or turn down the security settings on
    zonealarm. I expect a fix from MS or Zonealarm will be along shortly.

  5. Re: Another BIND vulnerability (cache poisoning)

    "IanMiller" wrote in message
    news:73bbb49b-bb4e-4b03-9c46-7cbb67baa53d@s50g2000hsb.googlegroups.com...
    > On 9 Jul, 17:54, johnwalla...@yahoo.co.uk wrote:
    >> On Jul 9, 9:35 am, JF Mezei wrote:
    >>
    >>
    >>
    >> > JF Mezei wrote:
    >> > > Slashdot article:
    >> > >http://it.slashdot.org/article.pl?sid=08/07/08/195225

    >>
    >> > > Offfical CERT article:
    >> > >http://www.kb.cert.org/vuls/id/800113

    >>
    >> > Test can be made atwww.doxpara.com

    >>
    >> > Essentially, what it does is cause a number of separate DNS requests to
    >> > be made to their own DNS server and they check if each DNS request was
    >> > made FROM a different port or not. If they all come from the same port,
    >> > it deems the DNS server to be vulnerable.

    >>
    >> > I used wireshark to trace the VMS TCPIP Services 5.6 (Bind 9) server
    >> > while running this test and the 5 requests all came from the same port.

    >>
    >> > My ISP has already patched their Linux servers.

    >>
    >> > Anyone know if a patch is/will be available for TCPIP Services 5.6 ?

    >>
    >> > Or is this something that the remaining VMS installed based doesn't
    >> > care
    >> > much about because they are enterprise systems not connected to the
    >> > internet ?

    >>
    >> I'm not sure why being "not connected to the internet" helps in this
    >> case (or in many other cases) as there too many uncontrolled leakage
    >> paths to the Internerd in many corporates these days anyway (and there
    >> often were even before the days of 3G phones and widespread laptops).
    >>
    >> Anyway, if I've understood right, this is an instance of "defective by
    >> design" in BIND. an error in BIND which djb (of djbdns and qmail fame)
    >> first talked about with CERT back in 2002, and first discussed in
    >> public by djb himself in 2001:http://cr.yp.to/djbdns/forgery.html
    >>
    >> As of December 2007 djbdns is in the public domain, so managers of
    >> commodity OSes on commodity hardware may well have an easy BIND-
    >> independent fix. No idea whether a VMS version is available.

    >
    > Note that the MS patch for this breaks zonealarm. So you have a
    > choice. remove this patch or turn down the security settings on
    > zonealarm. I expect a fix from MS or Zonealarm will be along shortly.
    >



    Since this vulnerability was known back in 2002, I wouldn't blame MS for
    breaking Zonealarm. As a security product, Zonealarm should have fixed
    their product a long time ago.

    Mike.



  6. Re: Another BIND vulnerability (cache poisoning)

    JF Mezei wrote:
    > Slashdot article:
    > http://it.slashdot.org/article.pl?sid=08/07/08/195225
    >
    > Offfical CERT article:
    > http://www.kb.cert.org/vuls/id/800113


    Just a reminder that HP has yet to provide CERT with any information
    about its many DNS implementations.

    Linux had patches available day of this announcement, as did Microsoft.

    As one analyst put it some time ago, it isn't the number of patches tha
    is important, it is the number of days before a patch is issued that
    matters because that is the number of days a system remains vulnerable.

  7. Re: Another BIND vulnerability (cache poisoning)

    It is sad that my DSL provider (AT&T) hasn't patched their servers
    yet!
    Hopefully, they will get their act together soon.

  8. Re: Another BIND vulnerability (cache poisoning)

    On Wed, 16 Jul 2008 02:02:51 -0700, winston19842005@yahoo.com
    wrote:

    > It is sad that my DSL provider (AT&T) hasn't patched their servers
    > yet!
    > Hopefully, they will get their act together soon.


    Alan, how do you determine that?

    --
    PL/I for OpenVMS
    www.kednos.com

  9. Re: Another BIND vulnerability (cache poisoning)

    In article , "Tom Linden" writes:
    >On Wed, 16 Jul 2008 02:02:51 -0700, winston19842005@yahoo.com
    > wrote:
    >
    >> It is sad that my DSL provider (AT&T) hasn't patched their servers
    >> yet!
    >> Hopefully, they will get their act together soon.

    >
    >Alan, how do you determine that?


    Tom, look back through this thread. Somebody posted the URL to a site
    that purports to test for the cache poisoning vulnerability.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    c. 2008 Brian Schenkenberger. Any publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  10. Re: Another BIND vulnerability (cache poisoning)

    On Wed, 16 Jul 2008 10:55:43 -0700, VAXman- <@SendSpamHere.ORG> wrote:

    > Tom, look back through this thread. Somebody posted the URL to a site
    > that purports to test for the cache poisoning vulnerability.


    Thanks, I looked at that, www.doxpara.com but it doesn't give you the
    ability to enter an IP.

    --
    PL/I for OpenVMS
    www.kednos.com

  11. Re: Another BIND vulnerability (cache poisoning)

    In article , "Tom Linden" writes:
    >On Wed, 16 Jul 2008 10:55:43 -0700, VAXman- <@SendSpamHere.ORG> wrote:
    >
    >> Tom, look back through this thread. Somebody posted the URL to a site
    >> that purports to test for the cache poisoning vulnerability.

    >
    >Thanks, I looked at that, www.doxpara.com but it doesn't give you the
    >ability to enter an IP.


    I see now. Seems it check the DNS of the web request. I'll take a look
    at the underlying code later. Maybe there's a way to exploit it to look
    at other IP/DNS.

    --
    VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM

    .... pejorative statements of opinion are entitled to constitutional protection
    no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

    Copr. 2008 Brian Schenkenberger. Publication of _this_ usenet article outside
    of usenet _must_ include its contents in its entirety including this copyright
    notice, disclaimer and quotations.

  12. Re: Another BIND vulnerability (cache poisoning)

    JF Mezei wrote:

    > Offfical CERT article:
    > http://www.kb.cert.org/vuls/id/800113



    Have VMS customers on support contract been furnished with the required
    patches for the above ?

    Or is HP intent on not releasing patches for VMS so it can claim VMS has
    fewer patches than Windows/Linux ?

    Lack of patch for BIND on VMS makes a VMS manager look quite bad when
    their management asks if the VMS ssrvers have been patched for that
    vulnerability when all others servers in the corportayion have been patched.

  13. Re: Another BIND vulnerability (cache poisoning)

    On Jul 23, 11:34*pm, JF Mezei wrote:
    > JF Mezei wrote:
    > > Offfical CERT article:
    > >http://www.kb.cert.org/vuls/id/800113

    >
    > Have VMS customers on support contract been furnished with the required
    > patches for the above ?
    >
    > Or is HP intent on not releasing patches for VMS so it can claim VMS has
    > fewer patches than Windows/Linux ?
    >
    > Lack of patch for BIND on VMS makes a VMS manager look quite bad when
    > their management asks if the VMS ssrvers have been patched for that
    > vulnerability when all others servers in the corportayion have been patched.


    Hope we get some "official word" soon. The script kiddy 'metasploit'
    tool now has an exploit for this problem built in.

  14. Re: Another BIND vulnerability (cache poisoning)

    On 24 Jul, 16:30, Malcolm Dunnett wrote:
    > JF Mezei wrote:
    > > JF Mezei wrote:

    >
    > >> Offfical CERT article:
    > >>http://www.kb.cert.org/vuls/id/800113

    >
    > > Have VMS customers on support contract been furnished with the required
    > > patches for the above ?

    >
    > * *Nothing on ITRC as of this morning (most recent TCP/IP kit is from
    > Sept/07).
    >
    > * * I did get a BIND patch for Multinet (from Process Software) a couple
    > of days ago.



    Exploits have now been described on a full disclosure mailing list.
    Process Software have released patches for current version of MULTINET
    and TCPware and intend to back port the fix to earlier versions.

  15. Re: Another BIND vulnerability (cache poisoning)

    In article <48889ffd$1@flight>, Malcolm Dunnett writes:
    >JF Mezei wrote:
    >> JF Mezei wrote:
    >>
    >>> Offfical CERT article:
    >>> http://www.kb.cert.org/vuls/id/800113

    >>
    >>
    >> Have VMS customers on support contract been furnished with the required
    >> patches for the above ?
    >>

    >
    > Nothing on ITRC as of this morning (most recent TCP/IP kit is from
    >Sept/07).
    >

    And it is getting a bit late now - there is now an exploit in the metasploit
    hacking toolkit see

    http://www.networkworld.com/news/200...d-for-new.html

    > I did get a BIND patch for Multinet (from Process Software) a couple
    >of days ago.


    The latest versions of multinet and TCPWARE can be run on versions of VMS going
    back to VAX VMS 5.5-2. Given how tied UCX is to the OS version nowadays I
    wonder whether HP will produce patches for older versions of UCX Bind or just
    the latest release (when they do produce a patch that is) ?


    David Webb
    Security team leader
    CCSS
    Middlesex University



  16. Re: Another BIND vulnerability (cache poisoning)

    On Jul 24, 10:46*am, davi...@alpha1.mdx.ac.uk wrote:
    > In article <48889ffd$1@flight>, Malcolm Dunnett writes:
    > >JF Mezei wrote:
    > >> JF Mezei wrote:

    >
    > >>> Offfical CERT article:
    > >>>http://www.kb.cert.org/vuls/id/800113

    >
    > >> Have VMS customers on support contract been furnished with the required
    > >> patches for the above ?

    >
    > > * Nothing on ITRC as of this morning (most recent TCP/IP kit is from
    > >Sept/07).

    >
    > And it is getting a bit late now - there is now an exploit in the metasploit
    > hacking toolkit see
    >
    > http://www.networkworld.com/news/200...e-released-for...
    >
    > > * *I did get a BIND patch for Multinet (from Process Software) a couple
    > >of days ago.

    >
    > The latest versions of multinet and TCPWARE can be run on versions of VMSgoing
    > back to VAX VMS 5.5-2. Given how tied UCX is to the OS version nowadays I
    > wonder whether HP will produce patches for older versions of UCX Bind or just
    > the latest release (when they do produce a patch that is) ?
    >
    > David Webb
    > Security team leader
    > CCSS
    > Middlesex University


    OpenVMS engineering is moving from NH to MA probably as I'm writing
    this. I know they put off the June ECOs because of the move. Not
    making excuses, but that *might* be a reason we haven't seen anything
    from them yet. Of course with some (all?) of the TCPIP group being
    across ponds, that might negate what I said above unless all things
    OpenVMS related need to get qualified before being released in the
    US. Dunno.

  17. Re: Another BIND vulnerability (cache poisoning)

    Rich Jordan wrote:
    > On Jul 23, 11:34 pm, JF Mezei wrote:
    >> JF Mezei wrote:
    >>> Offfical CERT article:
    >>> http://www.kb.cert.org/vuls/id/800113

    >> Have VMS customers on support contract been furnished with the required
    >> patches for the above ?
    >>
    >> Or is HP intent on not releasing patches for VMS so it can claim VMS has
    >> fewer patches than Windows/Linux ?
    >>
    >> Lack of patch for BIND on VMS makes a VMS manager look quite bad when
    >> their management asks if the VMS ssrvers have been patched for that
    >> vulnerability when all others servers in the corportayion have been patched.

    >
    > Hope we get some "official word" soon. The script kiddy 'metasploit'
    > tool now has an exploit for this problem built in.


    Look folks, this is tempest in a teapot. If your DNS server is properly
    configured on a properly configured network, an attacker's ability to
    poison your cache is close enough to nil as to be practically
    indistinguishable from it. Specifically, if your DNS server is
    configured to not accept recursive queries from anything except your own
    hosts, and your network is configured to block packets that spoof your
    own addresses, both of which are long, long, established best practices,
    then the mechanism by which an attacker can exploit the fact that your
    UDP source port is not random (which is all this patch addresses) simply
    doesn't exist.

    In a nutshell, in order to poison the cache of a properly configured DNS
    server, an attacker must *guess* your DNS transaction ID, the UDP source
    port of your DNS query, the host you are querying, and the exact query
    you are making. The crafted packet with the attacker's guesses must
    also beat the real answer to your system. The transaction ID is a
    16-bit random number. All this patch does is add a portion of the
    16-bit range of the UDP source port to the randomness.

    The level of guessing needed is impractical (and nearly mathmatically
    impossible) unless the attacker can cause your DNS server to issue known
    queries. It cannot do that unless you don't have recursive query
    permissions set correctly.

    Mark Berryman

  18. Re: Another BIND vulnerability (cache poisoning)

    Mark Berryman wrote:

    > The level of guessing needed is impractical (and nearly mathmatically
    > impossible) unless the attacker can cause your DNS server to issue known
    > queries. It cannot do that unless you don't have recursive query
    > permissions set correctly.


    Not so. You visit some web site which causes your DNS server to resolve
    some host names. The DNS server at the other end then responds with
    additional data that loads the cache with www.google.com pointing to
    www.yahoo.com

    This isn't a case of some hacker attacking your DNS server. It is a case
    of your DNS server receiving corrupt responses because it is easy to
    guess the transaction ID once you've already received a transaction and
    you know it uses the same port to listen all the time.


    And it look very bad for VMS when no patch is available and everyone
    else has had a patch available for weeks. Note that HP and other vendors
    had been made aware of this vulnerability well before it was announced,
    this is why various Linux distros had the patch available the minute the
    ulnerability was announced.

    So next time Mr Kerry Main uses the "VMS has fewer patches", please keep
    this in mind. When there needs to be a patch, VMS doesn't get them.

  19. Re: Another BIND vulnerability (cache poisoning)

    In article <4888f53e$0$5454$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >Mark Berryman wrote:
    >
    >> The level of guessing needed is impractical (and nearly mathmatically
    >> impossible) unless the attacker can cause your DNS server to issue known
    >> queries. It cannot do that unless you don't have recursive query
    >> permissions set correctly.

    >
    >Not so. You visit some web site which causes your DNS server to resolve
    >some host names. The DNS server at the other end then responds with
    >additional data that loads the cache with www.google.com pointing to
    >www.yahoo.com
    >
    >This isn't a case of some hacker attacking your DNS server. It is a case
    >of your DNS server receiving corrupt responses because it is easy to
    >guess the transaction ID once you've already received a transaction and
    >you know it uses the same port to listen all the time.
    >
    >
    >And it look very bad for VMS when no patch is available and everyone
    >else has had a patch available for weeks. Note that HP and other vendors
    >had been made aware of this vulnerability well before it was announced,
    >this is why various Linux distros had the patch available the minute the
    >ulnerability was announced.
    >


    Especially since HP were publicising the availability of a patch for this on
    HP-UX by the 17th July see

    http://groups.google.com/group/comp....7a894a706bfd93

    which was then updated on the 19th July

    http://groups.google.com/group/comp....cb7b1849a67e1f


    David Webb
    Security team leader
    CCSS
    Middlesex University

    >So next time Mr Kerry Main uses the "VMS has fewer patches", please keep
    >this in mind. When there needs to be a patch, VMS doesn't get them.


  20. Re: Another BIND vulnerability (cache poisoning)

    On Jul 25, 5:23*am, davi...@alpha2.mdx.ac.uk wrote:
    > In article <4888f53e$0$5454$c3e8...@news.astraweb.com>, JF Mezei writes:
    >
    >
    >
    > >Mark Berryman wrote:

    >
    > >> The level of guessing needed is impractical (and nearly mathmatically
    > >> impossible) unless the attacker can cause your DNS server to issue known
    > >> queries. *It cannot do that unless you don't have recursive query
    > >> permissions set correctly.

    >
    > >Not so. You visit some web site which causes your DNS server to resolve
    > >some host names. The DNS server at the other end then responds with
    > >additional data that loads the cache withwww.google.compointing to
    > >www.yahoo.com

    >
    > >This isn't a case of some hacker attacking your DNS server. It is a case
    > >of your DNS server receiving corrupt responses because it is easy to
    > >guess the transaction ID once you've already received a transaction and
    > >you know it uses the same port to listen all the time.

    >
    > >And it look very bad for VMS when no patch is available and everyone
    > >else has had a patch available for weeks. Note that HP and other vendors
    > >had been made aware of this vulnerability well before it was announced,
    > >this is why various Linux distros had the patch available the minute the
    > >ulnerability was announced.

    >
    > Especially since HP were publicising the availability of a patch for thison
    > HP-UX by the 17th July see
    >
    > http://groups.google.com/group/comp....7a894a706bfd93
    >
    > which was then updated on the 19th July
    >
    > http://groups.google.com/group/comp....cb7b1849a67e1f
    >
    > David Webb
    > Security team leader
    > CCSS
    > Middlesex University
    >
    > >So next time Mr Kerry Main uses the "VMS has fewer patches", please keep
    > >this in mind. When there needs to be a patch, VMS doesn't get them.

    >
    >


    Update from SANS for today. They are not taking this lightly.

    http://isc.sans.org/diary.html?date=2008-07-25


+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast