Re: Another BIND vulnerability (cache poisoning)
On Aug 1, 11:16*am, davi...@alpha2.mdx.ac.uk wrote:[color=blue]
> In article <a45cc262-41ac-4efc-893d-e58089038...@s50g2000hsb.googlegroups..com>, Rich Jordan <jor...@ccs4vms.com> writes:
>[color=green]
> >On Jul 29, 7:37=A0am, "Richard Whalen" <Whal...@process.com> wrote:[color=darkred]
> >> Note that Apple is behind on this patch too:[/color][/color]
>[color=green][color=darkred]
> >>[url]http://db.tidbits.com/article/9706[/url][/color][/color]
>[color=green]
> >Apple has released a fix for OS-X 10.4 and 10.5[/color]
>[color=green]
> >[url]http://support.apple.com/kb/HT2647[/url][/color]
>[color=green]
> >So I guess now we're just waiting on HP for a fix or at least a
> >statement.[/color]
>
> 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[/color]
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.
Re: Another BIND vulnerability (cache poisoning)
> As I mentioned before, we do have the updated images in hand -- just need to[color=blue]
> confirm that you need them and for which platform and version (Alpha or
> Integrity; V5.6, V5.5, or V5.4).[/color]
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 ?
Re: Another BIND vulnerability (cache poisoning)
On Aug 1, 1:07*pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:[color=blue][color=green]
> > 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).[/color]
>
> 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 ?[/color]
Why not ask them?
Re: Another BIND vulnerability (cache poisoning)
JF Mezei wrote:[color=blue][color=green]
>> 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).[/color]
>
>
>
> 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 ?
>[/color]
How can you watch Hopelessly Pathetic and pretend to be surprised about
this sort of thing?
Re: Another BIND vulnerability (cache poisoning)
JF Mezei wrote:
[color=blue]
> How can VMS management be so incompetant or so out of touch with reality ?[/color]
How can *you* ?
Re: Another BIND vulnerability (cache poisoning)
[email]david20@alpha2.mdx.ac.uk[/email] writes in article <g6v8be$5r7$1@south.jnrs.ja.net> dated Fri, 1 Aug 2008 14:58:54 +0000 (UTC):[color=blue]
>In article <op.ue7netj9hv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:[color=green]
>>On Thu, 31 Jul 2008 20:53:24 -0700, Spud Demon
>><no_spam@e.THUNDERMAKER.NET> wrote:[color=darkred]
>>> Next migrations: HTTP and the dreaded mail services (SMTP and IMAP).[/color]
>>
>>What don't you like about WASD or MX?
>>[/color]
>Or PMDF
>
>or even Communigate PRO[/color]
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
Re: Another BIND vulnerability (cache poisoning)
On Jul 28, 5:06*pm, Jan-Erik Söderholm <jan-erik.soderh...@telia.com>
wrote:[color=blue]
> 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 ?
>[/color]
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.
BIND Patch WAS: Another BIND vulnerability (cache poisoning)
On Sat, 02 Aug 2008 05:18:29 -0700, Jerry Eckert <Jerry.Eckert@gmail.com>
wrote:
[color=blue]
> On Jul 28, 5:06*pm, Jan-Erik Söderholm <jan-erik.soderh...@telia.com>
> wrote:[color=green]
>> 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 ?
>>[/color]
> 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.
>
>[/color]
It could be construed as negligence, and that has legal ramifications,
notwitstanding disclaimers to the contrary.
--
PL/I for OpenVMS
[url]www.kednos.com[/url]
Re: Another BIND vulnerability (cache poisoning)
On Jul 9, 5:36 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:[color=blue]
> Slashdot article:[url]http://it.slashdot.org/article.pl?sid=08/07/08/195225[/url]
>
> Offfical CERT article:[url]http://www.kb.cert.org/vuls/id/800113[/url]
>
> 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.[/color]
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...
[url]http://h71000.www7.hp.com/network/new.html[/url]
Cheers!
Keith Cayemberg
Better late than. . .Re: Another BIND vulnerability (cache poisoning)
[url]http://www.openvms.org/stories.php?story=08/08/12/8896640[/url]
Cheers Richard Maher
"IanMiller" <gxys@uk2.net> wrote in message
news:e6ed9e9f-d0e8-4c4f-b8d4-451c0df72c32@a1g2000hsb.googlegroups.com...
On 28 Jul, 14:12, Jan-Erik Söderholm <jan-erik.soderh...@telia.com>
wrote:[color=blue]
> IanMiller wrote:[color=green]
> > On Jul 25, 9:37 pm, Jan-Erik Söderholm <jan-erik.soderh...@telia.com>
> > wrote:[/color]
>[color=green][color=darkred]
> >> I'm failing to see how this is a major problem for
> >> my VMS systems, at least...[/color][/color]
>[color=green][color=darkred]
> >> Jan-Erik.[/color][/color]
>[color=green]
> > 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.[/color]
>
> 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.
>[color=green]
> > 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).[/color][/color]
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.
Re: Better late than. . .Re: Another BIND vulnerability (cache poisoning)
Richard Maher wrote:[color=blue]
> [url]http://www.openvms.org/stories.php?story=08/08/12/8896640[/url]
>
> Cheers Richard Maher[/color]
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.
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:[color=blue]
> [email]david20@alpha2.mdx.ac.uk[/email] writes in article <g6v8be$5r7$1@south.jnrs.ja.net> dated Fri, 1 Aug 2008 14:58:54 +0000 (UTC):[color=green]
>> In article <op.ue7netj9hv4qyg@murphus.hsd1.ca.comcast.net>, "Tom Linden" <tom@kednos.company> writes:[color=darkred]
>>> On Thu, 31 Jul 2008 20:53:24 -0700, Spud Demon
>>> <no_spam@e.THUNDERMAKER.NET> wrote:
>>>> Next migrations: HTTP and the dreaded mail services (SMTP and IMAP).
>>> What don't you like about WASD or MX?
>>>[/color]
>> Or PMDF
>>
>> or even Communigate PRO[/color]
>
> 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.[/color]
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.
[color=blue]
> 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.[/color]
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.
[color=blue]
>
> 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.[/color]
Get Multinet. The SSH that comes with TCPIP services, especially older
versions, is a joke.
[color=blue]
> 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.[/color]
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.
[color=blue]
> UCX IMAP is incredibly slow. I'm hoping for a 100x speed improvement when I
> migrate.[/color]
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