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

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

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.

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.

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.

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?

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

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

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

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

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

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

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

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

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 ?

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

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

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.

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