Messages in this thread | | | Date | Mon, 10 Sep 2001 00:54:31 -0400 | From | "Michael H. Warfield" <> | Subject | Re: [OT] LDAP vs NIS+ security |
| |
On Sun, Sep 09, 2001 at 11:40:39PM -0400, Michael H. Warfield wrote: > On Sun, Sep 09, 2001 at 10:07:06PM -0400, Trever L. Adams wrote: > > I am sorry to write this off topic message. I should probably go look > > in google for the answer... however -
> > Someone in arguing about implimenting directory services into the kernel > > said that NIS+ will always be more secure than LDAP over SSL... why is this?
> FIIK... /;-(
> NIS (FKA Sun Yellow Pages) was so insecure it became know as > the "Network Intruder Service". NIS+ was suppose to address most of > the NIS security issues and it did to a large extent, but created > more than a few problems along the way (having had to managed a mixed > Sun OS 4.x and Solaris 2.x environment, I have more than my share of > horror stories).
Oh! Almost forgot the best one of all (and more related to the directory service issue than problems with the password map).
If you combine YP/NIS/NIS+ with something like the finger service and you have a large enough user identification base, you create this niffty DoS attack that I called "nisnuke" at the time I published the security advisory years ago.
Basically, if you have a sufficiently large user database and I can get to enough finger servers, I can time finger requests into an NIS* network in a way that crushes the INTERNAL bandwidth destructively. With an experimental setup of only 10 finger servers and 1,000 users in the NIS maps I was able to uses a 30 second blast from perl script to cripple the test network for over 30 minutes. While most Linux systems recovered quickly, Solaris boxes took minutes to recover (most Solaris boxes had the screen savers freeze during the resulting NIS "storm") and some AIX boxes had to be power cycled. Most boxes would not even toggle the "caps lock" light on the keyboard during the meltdown period.
Note that the storm of NIS traffic cripples the internal bandwidth between the finger servers and the NIS[+] servers. This takes out everyone on that network, not just the NIS and finger servers. The conditions create a situation where RPC retries and failures (due to collisions) actually exceed the input to the cable you are generating from the finger traffic. It's a queueing theory meltdown where the input to the queue is higher than it's capacity.
Sun worked for months trying to solve the problem and the best they could come up with was to either "disable finger" or "install and open source version of the finger service which did not do wild card expansion on the databases".
This was all documented in an Internet Security Systems Advisory which I authored several years ago. AFAIK, if you put an NIS or NIS+ network together with a large enough user base and a few finger servers, I can cripple it with NIS traffic and tear it to it's knees and keep it there. And all finger is doing is "directory lookups" on users. :-/
See BugTraq or ISS Alert archives for more information.
Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |