Another BIND vulnerability (cache poisoning) - VMS

This is a discussion on Another BIND vulnerability (cache poisoning) - VMS ; On Aug 1, 11:16*am, davi...@alpha2.mdx.ac.uk wrote: > In article , Rich Jordan writes: > > >On Jul 29, 7:37=A0am, "Richard Whalen" wrote: > >> Note that Apple is behind on this patch too: > > >> http://db.tidbits.com/article/9706 > > >Apple ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 72 of 72

Thread: Another BIND vulnerability (cache poisoning)

  1. Re: Another BIND vulnerability (cache poisoning)

    On Aug 1, 11:16*am, davi...@alpha2.mdx.ac.uk wrote:
    > In article , Rich Jordan writes:
    >
    > >On Jul 29, 7:37=A0am, "Richard Whalen" wrote:
    > >> Note that Apple is behind on this patch too:

    >
    > >>http://db.tidbits.com/article/9706

    >
    > >Apple has released a fix for OS-X 10.4 and 10.5

    >
    > >http://support.apple.com/kb/HT2647

    >
    > >So I guess now we're just waiting on HP for a fix or at least a
    > >statement.

    >
    > It seems they do have a fix available but for some reason don't seem to be
    > publicising that fact
    >
    > "
    > As I mentioned before, we do have the updated images in hand -- just needto
    > confirm that you need them and for which platform and version (Alpha or
    > Integrity; V5.6, V5.5, or V5.4). *I guess another option would be to goahead
    > and distribute a saveset containing images for all those versions; we have
    > such a saveset built also. *
    > I am pleased to hear that you are using the BIND server on OpenVMS, and I
    > wish more customers would choose such a configuration.
    > "
    >
    > Maybe VMS engineering should for security patches think of following the HP-UX
    > teams lead by notifying comp.os.vms. They regularly publish security patch
    > notifications to
    >
    > comp.sys.hp.hpux,
    > comp.security.unix
    > and
    > comp.security.misc
    >
    > David Webb
    > Security team leader
    > CCSS
    > Middlesex University


    Process has released a NAMED patch for TCPware V5.7-2 now, so its
    trickling back to earlier versions.

    I'm on the mailing list for patches and security updates for VMS from
    HP. So far I have not received anything concerning the DNS issue.

  2. Re: Another BIND vulnerability (cache poisoning)

    > As I mentioned before, we do have the updated images in hand -- just need to
    > confirm that you need them and for which platform and version (Alpha or
    > Integrity; V5.6, V5.5, or V5.4).




    Oh, what good stealth marketing !

    DAMNED IT ! GO TELL CERT THAT VMS HAS A PATCH AVAILABLE.

    Not doing so is negligence. This is a high visibility issue and lack fo
    mention that VMS has a patch makes VMS non-viable in modern times. If
    you want to artificially restrict VMS to "servers", then make ****en
    damned sure your bind SERVER is updated because that is part of what
    being a server is all about.


    How can VMS management be so incompetant or so out of touch with reality ?


  3. Re: Another BIND vulnerability (cache poisoning)

    On Aug 1, 1:07*pm, JF Mezei wrote:
    > > As I mentioned before, we do have the updated images in hand -- just need to
    > > confirm that you need them and for which platform and version (Alpha or
    > > Integrity; V5.6, V5.5, or V5.4).

    >
    > Oh, what good stealth marketing !
    >
    > DAMNED IT ! GO TELL CERT THAT VMS HAS A PATCH AVAILABLE.
    >
    > Not doing so is negligence. This is a high visibility issue and lack fo
    > mention that VMS has a patch makes VMS non-viable in modern times. If
    > you want to artificially restrict VMS to "servers", then make ****en
    > damned sure your bind SERVER is updated because that is part of what
    > being a server is all about.
    >
    > How can VMS management be so incompetant or so out of touch with reality ?


    Why not ask them?

  4. Re: Another BIND vulnerability (cache poisoning)

    JF Mezei wrote:
    >> As I mentioned before, we do have the updated images in hand -- just need to
    >> confirm that you need them and for which platform and version (Alpha or
    >> Integrity; V5.6, V5.5, or V5.4).

    >
    >
    >
    > Oh, what good stealth marketing !
    >
    > DAMNED IT ! GO TELL CERT THAT VMS HAS A PATCH AVAILABLE.
    >
    > Not doing so is negligence. This is a high visibility issue and lack fo
    > mention that VMS has a patch makes VMS non-viable in modern times. If
    > you want to artificially restrict VMS to "servers", then make ****en
    > damned sure your bind SERVER is updated because that is part of what
    > being a server is all about.
    >
    >
    > How can VMS management be so incompetant or so out of touch with reality ?
    >


    How can you watch Hopelessly Pathetic and pretend to be surprised about
    this sort of thing?

  5. Re: Another BIND vulnerability (cache poisoning)

    JF Mezei wrote:

    > How can VMS management be so incompetant or so out of touch with reality ?



    How can *you* ?

  6. Re: Another BIND vulnerability (cache poisoning)

    david20@alpha2.mdx.ac.uk writes in article dated Fri, 1 Aug 2008 14:58:54 +0000 (UTC):
    >In article , "Tom Linden" writes:
    >>On Thu, 31 Jul 2008 20:53:24 -0700, Spud Demon
    >> wrote:
    >>> Next migrations: HTTP and the dreaded mail services (SMTP and IMAP).

    >>
    >>What don't you like about WASD or MX?
    >>

    >Or PMDF
    >
    >or even Communigate PRO


    It's not a problem with each and every particular piece of software; it's
    that I want to be able to maintain my hobbyist site using a single hardware
    platform. My big deal is audio, and in order to keep it on my Alphas, I'm
    sticking to version 7.3-1, which means TCPIP 5.4.

    My first migration to Linux was NFS, because the Alpha hardware I own
    supports IDE poorly to not-at-all, and also because it's (near?) impossible to
    get VMS to talk to MacOS. The Mac NFS client wants to used non-privileged
    ports, and VMS insists they be privileged. Linux can be configured to allow
    both.

    SSH is also a big deal to me. UCX has a nasty old version which crashes a
    lot. On Linux, it just works. No more worries about whether somebody's
    capturing passwords from my telnet sessions, unless I have to manage the VMS
    boxes remotely.

    No problem with VMS Apache (CSWS) on my current pages, but what if I decide
    to write some Java servlets? VMS Java is perpetually behind, and my newer
    Linux hardware has more CPU cycles and available memory.

    UCX IMAP is incredibly slow. I'm hoping for a 100x speed improvement when I
    migrate.

    --Spud Demon

  7. Re: Another BIND vulnerability (cache poisoning)

    On Jul 28, 5:06*pm, Jan-Erik Söderholm
    wrote:
    > 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 ?
    >

    I believe many are concerned because HP hasn't announced to those who
    track these things that: (a) OpenVMS systems are affected by the
    vulnerability, and (b) that the patch is available. In other words,
    communication and perception.



  8. BIND Patch WAS: Another BIND vulnerability (cache poisoning)

    On Sat, 02 Aug 2008 05:18:29 -0700, Jerry Eckert
    wrote:

    > On Jul 28, 5:06*pm, Jan-Erik Söderholm
    > wrote:
    >> 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 ?
    >>

    > I believe many are concerned because HP hasn't announced to those who
    > track these things that: (a) OpenVMS systems are affected by the
    > vulnerability, and (b) that the patch is available. In other words,
    > communication and perception.
    >
    >

    It could be construed as negligence, and that has legal ramifications,
    notwitstanding disclaimers to the contrary.


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

  9. Re: Another BIND vulnerability (cache poisoning)

    On Jul 9, 5:36 am, 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
    >
    > 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.




    For those sites using OpenVMS as a "Name Server" in addition to the
    BIND Resolver capability of HP TCP/IP Services for OpenVMS, there are
    now patches available for BINDS's architectural design problem
    resulting in a DNS cache poisoning vulnerability in this "network
    level" service.

    Please review the information at the following URL...

    http://h71000.www7.hp.com/network/new.html



    Cheers!

    Keith Cayemberg



  10. Better late than. . .Re: Another BIND vulnerability (cache poisoning)

    http://www.openvms.org/stories.php?s.../08/12/8896640

    Cheers Richard Maher

    "IanMiller" wrote in message
    news:e6ed9e9f-d0e8-4c4f-b8d4-451c0df72c32@a1g2000hsb.googlegroups.com...
    On 28 Jul, 14:12, Jan-Erik Söderholm
    wrote:
    > 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).




    The reaction here is as expected. The usual arguments rehashed. :-(
    I expect those few people that have had a potential problem on their
    VMS systems have done something about it - changed configuration or
    contacted the vendor of their TCPIP product.



  11. Re: Better late than. . .Re: Another BIND vulnerability (cache poisoning)

    Richard Maher wrote:
    > http://www.openvms.org/stories.php?s.../08/12/8896640
    >
    > Cheers Richard Maher


    Thanks for the link.

    A while ago, I read an interview with the Mozilla foundation president
    (or whatever title she has).

    She was mentioning that these days, one doesn't measure the number of
    patches issues for a system, but rather how long a system remains
    vulnerable before a patch becomes available.

    When Kaminsky found the problem, he provided the technical info to the
    major OS vendors and gavce them time to produce a patch before the
    vulnerability was made public. Many system had the patch ready the day
    the vulnerability was made public on CERT.

    It took a few weeks for VMS to get the patch.


    Just keep that in mind the next time Mr Kerry brags about VMS having
    fewer patches than Linux.

  12. Re: Another BIND vulnerability (cache poisoning)

    I hardly ever read this forum any more so please forgive my answer for
    being 3 weeks after your posting. But,

    Spud Demon wrote:
    > david20@alpha2.mdx.ac.uk writes in article dated Fri, 1 Aug 2008 14:58:54 +0000 (UTC):
    >> In article , "Tom Linden" writes:
    >>> On Thu, 31 Jul 2008 20:53:24 -0700, Spud Demon
    >>> wrote:
    >>>> Next migrations: HTTP and the dreaded mail services (SMTP and IMAP).
    >>> What don't you like about WASD or MX?
    >>>

    >> Or PMDF
    >>
    >> or even Communigate PRO

    >
    > It's not a problem with each and every particular piece of software; it's
    > that I want to be able to maintain my hobbyist site using a single hardware
    > platform. My big deal is audio, and in order to keep it on my Alphas, I'm
    > sticking to version 7.3-1, which means TCPIP 5.4.


    I do all kinds of audio on my Alpha, using VMS V8.3. I also strongly
    recommend staying as far away as possible from TCPIP Services. Get a
    hobbyist copy of Multinet. You will be much happier.

    > My first migration to Linux was NFS, because the Alpha hardware I own
    > supports IDE poorly to not-at-all, and also because it's (near?) impossible to
    > get VMS to talk to MacOS. The Mac NFS client wants to used non-privileged
    > ports, and VMS insists they be privileged. Linux can be configured to allow
    > both.


    A limitation of your chosen IP stack. Either switch to Multinet or add
    -P to your MacOS NFS mount command to tell it to use a privileged port.
    All of my Macs NFS mount shares served by my VMS V8.3 system (using
    Multinet V5.2) and I have had no issues so far.

    >
    > SSH is also a big deal to me. UCX has a nasty old version which crashes a
    > lot. On Linux, it just works. No more worries about whether somebody's
    > capturing passwords from my telnet sessions, unless I have to manage the VMS
    > boxes remotely.


    Get Multinet. The SSH that comes with TCPIP services, especially older
    versions, is a joke.

    > No problem with VMS Apache (CSWS) on my current pages, but what if I decide
    > to write some Java servlets? VMS Java is perpetually behind, and my newer
    > Linux hardware has more CPU cycles and available memory.


    VMS has a very recent copy of Java V5. I don't know what you'd want to
    do in a servlet that might require V6 but I've had too many instances of
    long working code breaking in V6 that I wouldn't want to use it anyway.

    > UCX IMAP is incredibly slow. I'm hoping for a 100x speed improvement when I
    > migrate.


    The best IMAP server for VMS comes with PMDF. Add Precise Mail
    Anti-Spam and you've got the best mail server you can put together,
    especially for a hobbyist. No Linux system comes close (and I've tried
    most of what's out there). Both are available for hobbyists.

    Mark Berryman

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4