NetWare Changing IP Port 524
Quoted 7 lines · Jeff V. Merkey
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.
Quoted 8 lines
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]
-
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/
Quoted 34 lines · Petr Vandrovec
Quoted 7 lines · Jeff V. Merkey
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.
Quoted 8 lines
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.
Quoted 6 lines
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
Quoted 16 lines
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/
-
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/
Quoted 5 lines · Jeff V. Merkey
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.
-
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/
Quoted 8 lines · Gregory Maxwell
Quoted 5 lines · Jeff V. Merkey
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).
Quoted 4 lines
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
-
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/
Quoted 3 lines
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
-
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/