Another BIND vulnerability (cache poisoning) - VMS

This is a discussion on Another BIND vulnerability (cache poisoning) - VMS ; JF Mezei wrote: > 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 ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 72

Thread: Another BIND vulnerability (cache poisoning)

  1. Re: Another BIND vulnerability (cache poisoning)

    JF Mezei wrote:
    > 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


    Nope. No DNS server released in, oh the past 10 years or so, will
    accept any data in the "additional data" section of a reply that does
    not match the domain of the original query. This is a bug that was
    discovered around 1995 or so and fixed long since.

    (Microsoft may be an exception to this. Their DNS server is broken in
    so many ways that I have never used it or checked its security bona
    fides. The Internet reference server, which comes from ISC, does work
    this way).

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


    You can't force the DNS server to send a transaction to you so you can
    look at its transaction ID (which is already random and not easily
    guessed) unless the DNS server is not properly configured. And there is
    a lot more to sending a bogus response than just knowing the transaction ID.

    Mark Berryman

  2. Re: Another BIND vulnerability (cache poisoning)

    In article <48899c0b$1@mvb.saic.com>, Mark Berryman writes:
    >JF Mezei wrote:
    >> 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

    >
    >Nope. No DNS server released in, oh the past 10 years or so, will
    >accept any data in the "additional data" section of a reply that does
    >not match the domain of the original query. This is a bug that was
    >discovered around 1995 or so and fixed long since.
    >
    >(Microsoft may be an exception to this. Their DNS server is broken in
    >so many ways that I have never used it or checked its security bona
    >fides. The Internet reference server, which comes from ISC, does work
    >this way).
    >
    >>
    >> 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.

    >
    >You can't force the DNS server to send a transaction to you so you can
    >look at its transaction ID (which is already random and not easily
    >guessed) unless the DNS server is not properly configured. And there is
    >a lot more to sending a bogus response than just knowing the transaction ID.
    >
    >Mark Berryman


    Mark,

    As the SAN's article

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

    says your DNS systems which are setup to be recursive for your internal users
    are vulnerable via code downloaded from websites your users visit or from
    code on infected systems in your organisation eg botnet members.

    David Webb
    Security team leader
    CCSS
    Middlesex University

  3. Re: Another BIND vulnerability (cache poisoning)

    In article , david20@alpha1.mdx.ac.uk writes:
    >In article <48899c0b$1@mvb.saic.com>, Mark Berryman writes:
    >>JF Mezei wrote:
    >>> 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

    >>
    >>Nope. No DNS server released in, oh the past 10 years or so, will
    >>accept any data in the "additional data" section of a reply that does
    >>not match the domain of the original query. This is a bug that was
    >>discovered around 1995 or so and fixed long since.
    >>


    It appears that JF may be almost correct. Apparently the flaw relates to
    getting an entry for a non-existent subdomain of your target into the
    DNS cache and passing additional data for the main domain of the target ie
    related data

    see

    http://blaynesucks.com/2008/07/22/pr...level-dns-flaw

    ( With a name like blaynesucks.com I'm not sure how accurate this description
    is.)


    David Webb
    Security team leader
    CCSS
    Middlesex University


    >>(Microsoft may be an exception to this. Their DNS server is broken in
    >>so many ways that I have never used it or checked its security bona
    >>fides. The Internet reference server, which comes from ISC, does work
    >>this way).
    >>
    >>>
    >>> 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.

    >>
    >>You can't force the DNS server to send a transaction to you so you can
    >>look at its transaction ID (which is already random and not easily
    >>guessed) unless the DNS server is not properly configured. And there is
    >>a lot more to sending a bogus response than just knowing the transaction ID.
    >>
    >>Mark Berryman

    >
    >Mark,
    >
    >As the SAN's article
    >
    >http://isc.sans.org/diary.html?date=2008-07-25
    >
    >says your DNS systems which are setup to be recursive for your internal users
    >are vulnerable via code downloaded from websites your users visit or from
    >code on infected systems in your organisation eg botnet members.
    >
    >David Webb
    >Security team leader
    >CCSS
    >Middlesex University


  4. Re: Another BIND vulnerability (cache poisoning)

    This issue is now a high visibility one and it doesn't really matter
    much if I am correct or not, or whether VMS can or cannot be affected.

    If VMS is not affected, then HP should post this info on the CERT web
    site to indicate that VMS has been tested and while the public tests
    show it as vulnerable, it is not vulnerable to actual "attacks".

    Lack of any/all information about VMS and this CERT issue sends a strong
    message that VMS is no longer getting critical patches and they only
    produce patches now and then when they have spare time.

    Thankfully, the media already thinks VMS is dead, so they don't cover
    the story of HP not producing a patch for VMS.

    But VMS customers on support contracts should be mighty worried. If you
    have fought hard to keep VMS systems in place, and argued VMS had
    superior security, the lack of available patch for a very public issue
    makes you look like a fool within your organisation because you "so
    secure" VMS systems are no longer "so secure" and you will have to keep
    your mouth shut from now on.

    The standards have gone WAY down in terms of how much support is given
    to VMS. Whether this is due to staff reductions, clueless VMS group
    management who don't know how to manage human resources and see this as
    an important enoiugh issue to divert resources to get a fix out ASAP, or
    whether this is an HP strategy to wind down VMS ever so slowly doesn't
    matter. What matters is that VMS has not gotten a patch in a timely
    fashion for a high visibility item when tests show VMS is vulnerable.

  5. Re: Another BIND vulnerability (cache poisoning)

    david20@alpha1.mdx.ac.uk wrote:
    > In article <48899c0b$1@mvb.saic.com>, Mark Berryman writes:
    >> JF Mezei wrote:
    >>> 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

    >> Nope. No DNS server released in, oh the past 10 years or so, will
    >> accept any data in the "additional data" section of a reply that does
    >> not match the domain of the original query. This is a bug that was
    >> discovered around 1995 or so and fixed long since.
    >>
    >> (Microsoft may be an exception to this. Their DNS server is broken in
    >> so many ways that I have never used it or checked its security bona
    >> fides. The Internet reference server, which comes from ISC, does work
    >> this way).
    >>
    >>> 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.

    >> You can't force the DNS server to send a transaction to you so you can
    >> look at its transaction ID (which is already random and not easily
    >> guessed) unless the DNS server is not properly configured. And there is
    >> a lot more to sending a bogus response than just knowing the transaction ID.
    >>
    >> Mark Berryman

    >
    > Mark,
    >
    > As the SAN's article
    >
    > http://isc.sans.org/diary.html?date=2008-07-25
    >
    > says your DNS systems which are setup to be recursive for your internal users
    > are vulnerable via code downloaded from websites your users visit or from
    > code on infected systems in your organisation eg botnet members.


    That particular attack works like this:

    Say you want to redirect people from Google to your nefarious site:

    The steps are as follows:

    1. Trick someone into fetching a web page from a site you have already
    hacked. This site contains img tags that attempt to open
    aaaaa.google.com. It continues sequentially in this manner, from
    aaaaa.google.com to zzzzz.google.com. Simultaneously, the attacker must
    know what DNS server the web client is using and it is attempting to
    flood that web server with bogus answers to these queries, hoping to
    beat the real answers from Google. The malicious web page must pass all
    of the security checks that are on the victimized web client and the
    victimized web client must be configured to run javascript from
    untrusted sources.

    2. The bogus packets contain an answer for www.google.com in the
    additional information section. Because it matches the same domain as
    the original query (aaaaa.google.com) it passes the bailiwick test and
    gets accepted. In theory.

    3. The attacker must know which query the host is currently making. The
    attacker must also know the transaction ID (and, with the patch, the
    source UDP port). The only way for the attacker to know the query is
    for the web page the victimized host loaded to tell it. This is a lot
    of traffic that is not only detectable with IDS but also slows down the
    attack. The attacker has to guess the transaction ID (and the source
    port with the patch). The idiot user who got tricked has to stay on the
    web page while the attack takes place.

    4. The attacker is now flooding the DNS server with various answers
    hoping that one of them will not only match the necessary criteria but
    that it will beat the real answer. The firewall that the DNS server is
    behind (which includes IDS) detects this flood and sends an alert and
    starts blocking it.

    5. The victimized host is now flooding the DNS server with queries. The
    DNS server detects this and blocks the host.

    6. Because other domains have sometimes misconfigured themselves, and
    end up sending out incorrect data for their domains for a short period
    of time, our DNS servers are configured to severely limit the amount of
    time an answer can stay in cache. That way, bogus answers stop being
    used fairly quickly.

    So, as you can see, properly configuring your DNS setup makes it really
    really difficult to poison the cache. However, this little issue does
    make a good argument for getting rid of windows on your network. Of all
    of the DNS clients on our network, windows is the only one that requires
    a recursive DNS server since it uses a stub resolver that can't do the
    recursion itself. Non-recursive servers are not vulnerable to this attack.

  6. Re: Another BIND vulnerability (cache poisoning)

    Mark Berryman wrote:
    > david20@alpha1.mdx.ac.uk wrote:
    >> In article <48899c0b$1@mvb.saic.com>, Mark Berryman
    >> writes:
    >>> JF Mezei wrote:
    >>>> 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
    >>> Nope. No DNS server released in, oh the past 10 years or so, will
    >>> accept any data in the "additional data" section of a reply that does
    >>> not match the domain of the original query. This is a bug that was
    >>> discovered around 1995 or so and fixed long since.
    >>>
    >>> (Microsoft may be an exception to this. Their DNS server is broken
    >>> in so many ways that I have never used it or checked its security
    >>> bona fides. The Internet reference server, which comes from ISC,
    >>> does work this way).
    >>>
    >>>> 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.
    >>> You can't force the DNS server to send a transaction to you so you
    >>> can look at its transaction ID (which is already random and not
    >>> easily guessed) unless the DNS server is not properly configured.
    >>> And there is a lot more to sending a bogus response than just knowing
    >>> the transaction ID.
    >>>
    >>> Mark Berryman

    >>
    >> Mark,
    >>
    >> As the SAN's article
    >> http://isc.sans.org/diary.html?date=2008-07-25
    >>
    >> says your DNS systems which are setup to be recursive for your
    >> internal users are vulnerable via code downloaded from websites your
    >> users visit or from code on infected systems in your organisation eg
    >> botnet members.

    >
    > That particular attack works like this:
    >
    > Say you want to redirect people from Google to your nefarious site:
    >
    > The steps are as follows:
    >
    > 1. Trick someone into fetching a web page from a site you have already
    > hacked. This site contains img tags that attempt to open
    > aaaaa.google.com. It continues sequentially in this manner, from
    > aaaaa.google.com to zzzzz.google.com. Simultaneously, the attacker must
    > know what DNS server the web client is using and it is attempting to
    > flood that web server with bogus answers to these queries, hoping to
    > beat the real answers from Google. The malicious web page must pass all
    > of the security checks that are on the victimized web client and the
    > victimized web client must be configured to run javascript from
    > untrusted sources.
    >
    > 2. The bogus packets contain an answer for www.google.com in the
    > additional information section. Because it matches the same domain as
    > the original query (aaaaa.google.com) it passes the bailiwick test and
    > gets accepted. In theory.
    >
    > 3. The attacker must know which query the host is currently making. The
    > attacker must also know the transaction ID (and, with the patch, the
    > source UDP port). The only way for the attacker to know the query is
    > for the web page the victimized host loaded to tell it. This is a lot
    > of traffic that is not only detectable with IDS but also slows down the
    > attack. The attacker has to guess the transaction ID (and the source
    > port with the patch). The idiot user who got tricked has to stay on the
    > web page while the attack takes place.
    >
    > 4. The attacker is now flooding the DNS server with various answers
    > hoping that one of them will not only match the necessary criteria but
    > that it will beat the real answer. The firewall that the DNS server is
    > behind (which includes IDS) detects this flood and sends an alert and
    > starts blocking it.
    >
    > 5. The victimized host is now flooding the DNS server with queries. The
    > DNS server detects this and blocks the host.
    >
    > 6. Because other domains have sometimes misconfigured themselves, and
    > end up sending out incorrect data for their domains for a short period
    > of time, our DNS servers are configured to severely limit the amount of
    > time an answer can stay in cache. That way, bogus answers stop being
    > used fairly quickly.
    >
    > So, as you can see, properly configuring your DNS setup makes it really
    > really difficult to poison the cache. However, this little issue does
    > make a good argument for getting rid of windows on your network. Of all
    > of the DNS clients on our network, windows is the only one that requires
    > a recursive DNS server since it uses a stub resolver that can't do the
    > recursion itself. Non-recursive servers are not vulnerable to this attack.


    Now, exactly *what* part of TCPIP on VMS is it that
    "needs" a patch ? Is when/if the VMS systems is set up to
    act as a DNS/BIND *server* ? Or is it something in the DNS/BIND
    *resolver* ?

    I'm failing to see how this is a major problem for
    my VMS systems, at least...

    Jan-Erik.


  7. Re: Another BIND vulnerability (cache poisoning)

    In article <488a10c0$0$14356$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >
    > If VMS is not affected, then HP should post this info on the CERT web
    > site to indicate that VMS has been tested and while the public tests
    > show it as vulnerable, it is not vulnerable to actual "attacks".


    How does HP define whether VMS is affected, when HP doesn't own all
    the BIND implementations being run on VMS? The best HP can do is
    tell us whether UCX (clear throat, "HP TCP/IP Services for OpenVMS")
    is affected.

    What has Process got to say about theirs?


  8. Re: Another BIND vulnerability (cache poisoning)

    Bob Koehler schrieb:
    > JF Mezei writes:
    >> If VMS is not affected, then HP should post this info on the CERT web
    >> site to indicate that VMS has been tested and while the public tests
    >> show it as vulnerable, it is not vulnerable to actual "attacks".

    >
    > How does HP define whether VMS is affected, when HP doesn't own all
    > the BIND implementations being run on VMS? The best HP can do is
    > tell us whether UCX (clear throat, "HP TCP/IP Services for OpenVMS")
    > is affected.
    >
    > What has Process got to say about theirs?


    Process has issued patches for TCPware and MultiNet.

    cu,
    Martin
    --
    One OS to rule them all | Martin Vorlaender | OpenVMS rules!
    One OS to find them | work: mv@pdv-systeme.de
    One OS to bring them all | http://vms.pdv-systeme.de/users/martinv/
    And in the Darkness bind them.| home: martin.vorlaender@t-online.de

  9. Re: Another BIND vulnerability (cache poisoning)

    On Jul 25, 9:37*pm, Jan-Erik Söderholm
    wrote:
    > Mark Berryman wrote:
    > > davi...@alpha1.mdx.ac.uk wrote:
    > >> In article <48899c0...@mvb.saic.com>, Mark Berryman
    > >> writes:
    > >>> JF Mezei wrote:
    > >>>> 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
    > >>> Nope. *No DNS server released in, oh the past 10 years or so, will
    > >>> accept any data in the "additional data" section of a reply that does
    > >>> not match the domain of the original query. *This is a bug that was
    > >>> discovered around 1995 or so and fixed long since.

    >
    > >>> (Microsoft may be an exception to this. *Their DNS server is broken
    > >>> in so many ways that I have never used it or checked its security
    > >>> bona fides. *The Internet reference server, which comes from ISC,
    > >>> does work this way).

    >
    > >>>> 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.
    > >>> You can't force the DNS server to send a transaction to you so you
    > >>> can look at its transaction ID (which is already random and not
    > >>> easily guessed) unless the DNS server is not properly configured. *
    > >>> And there is a lot more to sending a bogus response than just knowing
    > >>> the transaction ID.

    >
    > >>> Mark Berryman

    >
    > >> Mark,

    >
    > >> As the SAN's article
    > >>http://isc.sans.org/diary.html?date=2008-07-25

    >
    > >> says your DNS systems which are setup to be recursive for your
    > >> internal users are vulnerable via code downloaded from websites your
    > >> users visit or from code on infected systems in your organisation eg
    > >> botnet members.

    >
    > > That particular attack works like this:

    >
    > > Say you want to redirect people from Google to your nefarious site:

    >
    > > The steps are as follows:

    >
    > > 1. Trick someone into fetching a web page from a site you have already
    > > hacked. *This site contains img tags that attempt to open
    > > aaaaa.google.com. *It continues sequentially in this manner, from
    > > aaaaa.google.com to zzzzz.google.com. *Simultaneously, the attacker must
    > > know what DNS server the web client is using and it is attempting to
    > > flood that web server with bogus answers to these queries, hoping to
    > > beat the real answers from Google. *The malicious web page must pass all
    > > of the security checks that are on the victimized web client and the
    > > victimized web client must be configured to run javascript from
    > > untrusted sources.

    >
    > > 2. The bogus packets contain an answer forwww.google.comin the
    > > additional information section. *Because it matches the same domain as
    > > the original query (aaaaa.google.com) it passes the bailiwick test and
    > > gets accepted. *In theory.

    >
    > > 3. The attacker must know which query the host is currently making. *The
    > > attacker must also know the transaction ID (and, with the patch, the
    > > source UDP port). *The only way for the attacker to know the query is
    > > for the web page the victimized host loaded to tell it. *This is a lot
    > > of traffic that is not only detectable with IDS but also slows down the
    > > attack. *The attacker has to guess the transaction ID (and the source
    > > port with the patch). *The idiot user who got tricked has to stay on the
    > > web page while the attack takes place.

    >
    > > 4. The attacker is now flooding the DNS server with various answers
    > > hoping that one of them will not only match the necessary criteria but
    > > that it will beat the real answer. *The firewall that the DNS server is
    > > behind (which includes IDS) detects this flood and sends an alert and
    > > starts blocking it.

    >
    > > 5. The victimized host is now flooding the DNS server with queries. *The
    > > DNS server detects this and blocks the host.

    >
    > > 6. Because other domains have sometimes misconfigured themselves, and
    > > end up sending out incorrect data for their domains for a short period
    > > of time, our DNS servers are configured to severely limit the amount of
    > > time an answer can stay in cache. *That way, bogus answers stop being
    > > used fairly quickly.

    >
    > > So, as you can see, properly configuring your DNS setup makes it really
    > > really difficult to poison the cache. *However, this little issue does
    > > make a good argument for getting rid of windows on your network. *Of all
    > > of the DNS clients on our network, windows is the only one that requires
    > > a recursive DNS server since it uses a stub resolver that can't do the
    > > recursion itself. *Non-recursive servers are not vulnerable to this attack.

    >
    > Now, exactly *what* part of TCPIP on VMS is it that
    > "needs" a patch ? Is when/if the VMS systems is set up to
    > act as a DNS/BIND *server* ? Or is it something in the DNS/BIND
    > *resolver* ?
    >
    > I'm failing to see how this is a major problem for
    > my VMS systems, at least...
    >
    > Jan-Erik.



    As far as I can see you only have a problem if you have BIND resolver
    that does recursive searches using DNS servers you don't control.
    So if you use local host file then not a problem. If you use internal
    corporate DNS servers only then not a problem either.
    I suspect few VMS systems are vulnerable in practice.

    As usual, the problem is perception not reality. HP have not yet
    produced a patch therefore they don't care rather than actually
    looking at how many VMS systems that you manage have problem and doing
    something about it (if necessary).


  10. Re: Another BIND vulnerability (cache poisoning)

    IanMiller wrote:
    > On Jul 25, 9:37 pm, Jan-Erik Söderholm
    > wrote:
    >
    >> I'm failing to see how this is a major problem for
    >> my VMS systems, at least...
    >>
    >> Jan-Erik.

    >
    >
    > As far as I can see you only have a problem if you have BIND resolver
    > that does recursive searches using DNS servers you don't control.
    > So if you use local host file then not a problem. If you use internal
    > corporate DNS servers only then not a problem either.
    > I suspect few VMS systems are vulnerable in practice.
    >


    OK, as I thought.

    So probably the only affected VMS systems are a few hobbyist
    systems with direct Internet connections here and there.
    Hardly something to care *that* much about.

    And I'd guess that the only case when a VMS systems has to
    resolve a lot of external domains, is if you use your
    VMS systems for "surfing", and I can't realy see why
    you'd want to do that. There are much better and cheaper
    "surf-platforms" available...

    So, again, where *is* the problem ?? Besides of the
    possible perception that HP don't care, of course...

    Jan-Erik.



    > As usual, the problem is perception not reality. HP have not yet
    > produced a patch therefore they don't care rather than actually
    > looking at how many VMS systems that you manage have problem and doing
    > something about it (if necessary).
    >



  11. Re: Another BIND vulnerability (cache poisoning)

    In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    >In article <488a10c0$0$14356$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >>
    >> If VMS is not affected, then HP should post this info on the CERT web
    >> site to indicate that VMS has been tested and while the public tests
    >> show it as vulnerable, it is not vulnerable to actual "attacks".

    >
    > How does HP define whether VMS is affected, when HP doesn't own all
    > the BIND implementations being run on VMS? The best HP can do is
    > tell us whether UCX (clear throat, "HP TCP/IP Services for OpenVMS")
    > is affected.
    >


    That is ALL that is being asked of them.

    > What has Process got to say about theirs?
    >


    They have already released patches for the vulnerability

    see

    http://www.multinet.process.com/scri...NAMED-050_A052

    released 16th July


    and for TCPWARE

    http://vms.process.com/scripts/eco/e...NAMED_V582P010

    released 18th July


    David Webb
    Security team leader
    CCSS
    Middlesex University


  12. Re: Another BIND vulnerability (cache poisoning)

    In article , =?ISO-8859-1?Q?Jan-Erik_S=F6derholm?= writes:
    >IanMiller wrote:
    >> On Jul 25, 9:37 pm, Jan-Erik Söderholm
    >> wrote:
    >>
    >>> I'm failing to see how this is a major problem for
    >>> my VMS systems, at least...
    >>>
    >>> Jan-Erik.

    >>
    >>
    >> As far as I can see you only have a problem if you have BIND resolver
    >> that does recursive searches


    pretty much all windows systems

    > using DNS servers you don't control.


    Using any unpatched DNS server which is setup to do recursive queries for
    your internal systems.


    >> So if you use local host file then not a problem. If you use internal
    >> corporate DNS servers only then not a problem either.


    No - unpatched internal DNS servers which are setup to do recursive queries are
    vulnerable to attack from compromised internal windows systems.

    >> I suspect few VMS systems are vulnerable in practice.
    >>

    >
    >OK, as I thought.
    >
    >So probably the only affected VMS systems are a few hobbyist
    >systems with direct Internet connections here and there.
    >Hardly something to care *that* much about.
    >
    >And I'd guess that the only case when a VMS systems has to
    >resolve a lot of external domains, is if you use your
    >VMS systems for "surfing", and I can't realy see why
    >you'd want to do that. There are much better and cheaper
    >"surf-platforms" available...
    >
    >So, again, where *is* the problem ?? Besides of the
    >possible perception that HP don't care, of course...
    >


    So you are now saying VMS Security in HP's mind has been reduced to

    1) Hardly anyone is using VMS anymore
    2) There must be even less using VMS as a major DNS server in their
    organisation.

    So we won't bother putting out a patch.


    Yes that really is a great perception to be pushing.

    Would save them a lot of time writing patches since they can probably use that
    argument for practically any VMS security problem.


    David Webb
    Security team leader
    CCSS
    Middlesex University






    >Jan-Erik.
    >
    >
    >
    >> As usual, the problem is perception not reality. HP have not yet
    >> produced a patch therefore they don't care rather than actually
    >> looking at how many VMS systems that you manage have problem and doing
    >> something about it (if necessary).
    >>

    >


  13. Re: Another BIND vulnerability (cache poisoning)

    On Mon, 28 Jul 2008 06:42:43 -0700, wrote:

    > No - unpatched internal DNS servers which are setup to do recursive
    > queries are
    > vulnerable to attack from compromised internal windows systems.


    How do you check if it is set up that way?

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

  14. Re: Another BIND vulnerability (cache poisoning)

    In article , "Tom Linden" writes:
    >On Mon, 28 Jul 2008 06:42:43 -0700, wrote:
    >
    >> No - unpatched internal DNS servers which are setup to do recursive
    >> queries are
    >> vulnerable to attack from compromised internal windows systems.

    >
    >How do you check if it is set up that way?
    >


    Look in TCPIP$BIND.CONF

    If recursion is restricted to internal systems you will have something like

    acl "internal" {
    xxx.xxx.xxxx/24 ; 10/8 ;
    };

    options {
    directory "SYS$SPECIFIC:[TCPIP$BIND]";
    allow-recursion { "internal"; };
    max-cache-size 10M;
    };

    If there is no allow-recursion option specified then recursion is allowed
    from all hosts.

    see

    http://www.openvms.compaq.com/doc/83...nd9_access_tab

    and for the acl statement

    http://www.openvms.compaq.com/doc/83...#bind9_acl_sec


    David Webb
    Security team leader
    CCSS
    Middlesex University

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


  15. Re: Another BIND vulnerability (cache poisoning)

    I contacted HP support for one of my customers and got the following
    response:

    > There are 2 part to DNS.
    > 1) Server
    > - The vulnerability only affects the servers and may render it "compromised", and there is a fix for this.
    >
    > 2) Resolver/client
    > - The vulnerability will not affect the clients directly and there is no fix for it.
    >
    > But if your client is pointing to a server that was compromised, the client may not get the proper answers from the affected server.
    >
    > The only fix to this is to fix the affected server or point your client to another server that is not compromised.
    >
    > Regards,
    >
    > Jay So HP Services
    >


    Since these systems point to a corporate DNS server (at another location
    and the responsibility of another department) I am not asking for the
    patch but HP said they had one.

    At other customers, the OpenVMS systems point to DNS servers provided by
    their ISPs and I am checking those to see if they are patched. I am
    using http://www.doxpara.com/ to do the test.

    As I understand the problem, once the server your system points to is
    patched, there is nothing more you can do. If this is not correct,
    please let me know.

    Jeffrey Coffield
    www.digitalsynergyinc.com

  16. Re: Another BIND vulnerability (cache poisoning)

    david20@alpha1.mdx.ac.uk wrote:
    > Look in TCPIP$BIND.CONF
    >
    > If recursion is restricted to internal systems you will have something like
    >
    > acl "internal" {
    > xxx.xxx.xxxx/24 ; 10/8 ;
    > };
    >
    > options {
    > directory "SYS$SPECIFIC:[TCPIP$BIND]";
    > allow-recursion { "internal"; };
    > max-cache-size 10M;
    > };
    >
    > If there is no allow-recursion option specified then recursion is allowed
    > from all hosts.



    Pardon my ignorance, but this latest issue happens when a local client
    tries to resolve a list of foreign hosts and uses his designated DNS
    server to do this. So the requests come from the internal lan and are
    thus validated in the above rule, aren't they ?

  17. Re: Another BIND vulnerability (cache poisoning)

    In article ,
    koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
    > In article <488a10c0$0$14356$c3e8da3@news.astraweb.com>, JF Mezei writes:
    >>
    >> If VMS is not affected, then HP should post this info on the CERT web
    >> site to indicate that VMS has been tested and while the public tests
    >> show it as vulnerable, it is not vulnerable to actual "attacks".

    >
    > How does HP define whether VMS is affected, when HP doesn't own all
    > the BIND implementations being run on VMS? The best HP can do is
    > tell us whether UCX (clear throat, "HP TCP/IP Services for OpenVMS")
    > is affected.
    >
    > What has Process got to say about theirs?


    I thought it was already announced here that Process had fixed all
    of their software. And in a very timely manner as opposed to HP
    who I don't think has even admited there is a problem yet.

    Anyone want chime in here to defend VMS again as this is exactly
    what many people have said about the lack of CERT advisories in
    the first place and why they do not necessarily reflect greater
    security.

    bill


    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  18. Re: Another BIND vulnerability (cache poisoning)

    In article <488e0f25$0$1845$c3e8da3@news.astraweb.com>,
    JF Mezei writes:
    >
    > Would you trust HP for HP-UX when you look at how it is
    > handling VMS ?


    Why would their handling of VMS have any effect on the faith of HP-UX
    users? I thought they posted a timely patch to ensure HP-UX was fixed.

    bill


    --
    Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
    billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
    University of Scranton |
    Scranton, Pennsylvania | #include

  19. Re: Another BIND vulnerability (cache poisoning)

    billg999@cs.uofs.edu (Bill Gunshannon) writes:
    >
    > Why would their handling of VMS have any effect on the faith of HP-UX
    > users? I thought they posted a timely patch to ensure HP-UX was fixed.


    I saw how HP "supported" 68K HP-UX users when they went to PARC.
    We all saw how HP "supported" TruCluster users. Now they're showing
    equal levels of support for VAXen and UCX.

    Relying on HP for long term investment support has not been one of the
    brighter lights in the computer business. Gartner has tried now for
    about 20 years to kill VMS. HP may be thier best ally.


  20. Re: Another BIND vulnerability (cache poisoning)

    Jeffrey H. Coffield wrote:
    > I contacted HP support for one of my customers and got the following
    > response:
    >
    >> There are 2 part to DNS.
    >> 1) Server
    >> - The vulnerability only affects the servers and may render it
    >> "compromised", and there is a fix for this.
    >>
    >> 2) Resolver/client
    >> - The vulnerability will not affect the clients directly and there is
    >> no fix for it.
    >>


    I take it for granted that the above was regarding VMS, right ?

    And if so, it was more or less as I thought it was.

    Fine then, nothing to care about for me, those managing
    the DNS *servers* has to patch *their* systems...

    Was that realy what all the fuzz was about ?

    Jan-Erik.


    >> But if your client is pointing to a server that was compromised, the
    >> client may not get the proper answers from the affected server.
    > >
    >> The only fix to this is to fix the affected server or point your
    >> client to another server that is not compromised.
    >>
    >> Regards,
    >>
    >> Jay So HP Services
    >>

    >
    > Since these systems point to a corporate DNS server (at another location
    > and the responsibility of another department) I am not asking for the
    > patch but HP said they had one.
    >
    > At other customers, the OpenVMS systems point to DNS servers provided by
    > their ISPs and I am checking those to see if they are patched. I am
    > using http://www.doxpara.com/ to do the test.
    >
    > As I understand the problem, once the server your system points to is
    > patched, there is nothing more you can do. If this is not correct,
    > please let me know.
    >
    > Jeffrey Coffield
    > www.digitalsynergyinc.com


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