Petr/Linux,
If you are relying on port 524 to get SAP information for NCPFS over
TCPIP, you may want to track this since it appears Novell will be
patching this port to close a security flaw. I
added the tracking URL so you can review what changes they are
proposing. I think what they
are proposing as an immediate patch may break NCPFS -- you will need to
check.
:-)
Jeff
Novell NetWare discloses system information
Novell's NetWare operating system contains a flaw that allows
system information to be leaked via TCP port 524 in pure IP
configurations. When NetWare is used in a mix Microsoft
environment, the Novell operating system leaks data via Service
Advertising Protocol (SAP). Other third-party applications
compound the problem as well. A hacker can use the data to gain
knowledge on the inner workings of the affected system. It is
recommended that port 524 be blocked to prevent any leaks. For
more information on SAP:
http://support.novell.com/cgi-bin/search/search.pl?database_name=kb&type=HTM
L&docid=%03%21F221133%3a973867389%3a%20%28%2010050864%20%29%20%20%07%01%00&b
yte_count=71624
**********
On 14 Nov 00 at 12:11, Jeff V. Merkey wrote:
> If you are relying on port 524 to get SAP information for NCPFS over
> TCPIP, you may want to track this since it appears Novell will be
> patching this port to close a security flaw. I
> added the tracking URL so you can review what changes they are
> proposing. I think what they
> are proposing as an immediate patch may break NCPFS -- you will need to
> check.
I think that it is unavoidable. Either you can browse network resources,
through SAP, NDS, DNS, SLP, bindery - and you also disclose
informations - or you cannot browse network and users will get angry
from typing 80 characters FQDN names...
You can limit it by removing [Search] right for [Public] from your NDS -
and I believe that it is only correct solution. Of course every NDS server
must be able to tell to [public] address of at least one other server
nearest to [root], as client must be able to find where r/w replica
resides - and because of you know that there is [root] object in every
tree, you can find also [root] owner IP/IPX address. But if even knowing
of address of server can kill your network, you should already firewall
everything out.
> Novell's NetWare operating system contains a flaw that allows
> system information to be leaked via TCP port 524 in pure IP
> configurations. When NetWare is used in a mix Microsoft
> environment, the Novell operating system leaks data via Service
> Advertising Protocol (SAP). Other third-party applications
> compound the problem as well. A hacker can use the data to gain
> knowledge on the inner workings of the affected system. It is
> recommended that port 524 be blocked to prevent any leaks.
Yeah. They forgot to note that after blocking port 524 nobody
can connect to server from outer world. They could say in less
words that Netware and IP are not on same boat ;-) I think they
should fix buffer overflows and possible abends in their NCP engine,
and issue warnings about not giving [Search] rights to [Public]
instead of blocking whole world from Netware servers.
BTW, in our tree not-logged-in object does not see anything, except
few objects which have explicitly granted visibility for [public].
But maybe that I misunderstood their information... If they are
talking about that information learned through SLP/SAP/NDS are
available through SLP/SAP/NDS, I do not see anything wrong with it.
If hacker can ask this server, it could also ask directly to source
of that information, unless your server is also serving as firewall
(and if it is, you should visit filtering section in FILTCFG.NLM...)
Best regards,
Petr Vandrovec
[email protected]
Petr Vandrovec wrote:
>
> On 14 Nov 00 at 12:11, Jeff V. Merkey wrote:
>
> > If you are relying on port 524 to get SAP information for NCPFS over
> > TCPIP, you may want to track this since it appears Novell will be
> > patching this port to close a security flaw. I
> > added the tracking URL so you can review what changes they are
> > proposing. I think what they
> > are proposing as an immediate patch may break NCPFS -- you will need to
> > check.
>
> I think that it is unavoidable. Either you can browse network resources,
> through SAP, NDS, DNS, SLP, bindery - and you also disclose
> informations - or you cannot browse network and users will get angry
> from typing 80 characters FQDN names...
>
> You can limit it by removing [Search] right for [Public] from your NDS -
> and I believe that it is only correct solution. Of course every NDS server
> must be able to tell to [public] address of at least one other server
> nearest to [root], as client must be able to find where r/w replica
> resides - and because of you know that there is [root] object in every
> tree, you can find also [root] owner IP/IPX address. But if even knowing
> of address of server can kill your network, you should already firewall
> everything out.
>
> > Novell's NetWare operating system contains a flaw that allows
> > system information to be leaked via TCP port 524 in pure IP
> > configurations. When NetWare is used in a mix Microsoft
> > environment, the Novell operating system leaks data via Service
> > Advertising Protocol (SAP). Other third-party applications
> > compound the problem as well. A hacker can use the data to gain
> > knowledge on the inner workings of the affected system. It is
> > recommended that port 524 be blocked to prevent any leaks.
>
> Yeah. They forgot to note that after blocking port 524 nobody
> can connect to server from outer world. They could say in less
> words that Netware and IP are not on same boat ;-) I think they
> should fix buffer overflows and possible abends in their NCP engine,
> and issue warnings about not giving [Search] rights to [Public]
> instead of blocking whole world from Netware servers.
Hopefully, sanity will rule out here. I information being leaked from
what I reviewed was the ability for a hacker to exploit port 524 and use
it
to obtain a local copy of the entire routing table for other IP servers
INSIDE an organization (which is a huge hole).
Jeff
>
> BTW, in our tree not-logged-in object does not see anything, except
> few objects which have explicitly granted visibility for [public].
> But maybe that I misunderstood their information... If they are
> talking about that information learned through SLP/SAP/NDS are
> available through SLP/SAP/NDS, I do not see anything wrong with it.
> If hacker can ask this server, it could also ask directly to source
> of that information, unless your server is also serving as firewall
> (and if it is, you should visit filtering section in FILTCFG.NLM...)
> Best regards,
> Petr Vandrovec
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, Nov 14, 2000 at 01:29:31PM -0700, Jeff V. Merkey wrote:
> Hopefully, sanity will rule out here. I information being leaked from
> what I reviewed was the ability for a hacker to exploit port 524 and use
> it
> to obtain a local copy of the entire routing table for other IP servers
> INSIDE an organization (which is a huge hole).
That is obviously the hole as it is clearly not the intended function of the
service. However, anyone who depends on the secrecy of their IP routing
tables or overall network topology for security has bigger problems then
some stupid Netware bug.
Gregory Maxwell wrote:
>
> On Tue, Nov 14, 2000 at 01:29:31PM -0700, Jeff V. Merkey wrote:
> > Hopefully, sanity will rule out here. I information being leaked from
> > what I reviewed was the ability for a hacker to exploit port 524 and use
> > it
> > to obtain a local copy of the entire routing table for other IP servers
> > INSIDE an organization (which is a huge hole).
>
> That is obviously the hole as it is clearly not the intended function of the
> service. However, anyone who depends on the secrecy of their IP routing
> tables or overall network topology for security has bigger problems then
> some stupid Netware bug.
Greg,
The TCPIP implementation of NCP is little more than the existing RIP/SAP
and NCP protocols enveloped inside of UDP/SLP. The problem has nothing
to do with IP routing, but the ability
to send envoloped RIP/SAP requests into port 524, and getting a complete
topology description of the other side of a NetWare server being used as
a firewall. It would be kind of like opening a port on Linux, then
letting people come into the server with root file read/write and
letting
them read the network topology on the other side. What's nasty about
this problem is that it would give any internet hackers the ability to
discover the network topology (including which servers host NDS master
and replica databases). Not very secure. The concern for Petr is if in
fixing this hole, Novell breaks features Petr needs. I doubt they can
change it at this point, other than allow firewall servers to turn it
off to the external world. As Petr pointed out, closing this port will
break all the clients, including theirs. To make a change of this
magnitude would require they rev their clients and servers (and break
access to the entire installed base). I provided Petr the URL so he can
track what changes they post.
You misunderstood, I think.
Jeff
> this problem is that it would give any internet hackers the ability to
> discover the network topology (including which servers host NDS master
> and replica databases). Not very secure. The concern for Petr is if in
If knowing the server makes it vulnerable, the server has other
problems still. Treating addresses and topology as secret is STO.
Olaf