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
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 21:00:26 EST