Below is a list of security holes in NeXTStep, along with the suggested patch. Those marked with a * are drop-in replacements for the affected NeXT programs, which I have compiled quad-fat. I have included the source code, so that you can see what I did (we are talking about security here).

Except for the Syslog patch, the programs marked with a * were derived from FreeBSD or OpenBSD sources, with minimal changes needed to get them to compile under NeXTStep. The latest version of the FreeBSD originals can be found here. The latest OpenBSD sources can be found here.

ProgramSecurity holeAffected NS versionFix
rlogin(1)local users can gain root accessearlier than OS 4.1*Replacement program.
syslog(3)buffer overrun in the syslog library routine -- effects varyAll? There is a test program included to see if your system is vulnerable. Mine was.*New library (blurb). This does not replace the NeXT shared library. You need to recompile programs to link to the new library. An example of a program recompiled with the new syslog() library is *logger(1).
talkd(8)remote users can gain root accessAll?Install BIND 8.2.3 and run a caching-only nameserver on your machine and/or install the *replacement daemon. Note that earlier versions of BIND have some serious security problems.
rpc.statd(8)remote users can gain root access on NFS server. Note that this is distinct from the previous root hole which was patched in OS 4.0All?None available yet.
rpc.ypupdated(8)remote users can gain root access on NIS serverAll?None available yet.
rdist(1)local users can gain root access in more than one way.All?Install Rdist-6.1.3.
lpr(1)local users can gain root access earlier than OS 4.2Install this wrapper provided in the AusCERT Advisory.
ftpd(8)remote users can gain root access in several ways. Other vulnerabilities include the FTP bounce attack, which can be used for all sorts of mischief. Note that wu-ftpd-2.6.0 and older have a remote root hole in the site exec command. It, and a large number of other ftpd's (not including NeXT's ftpd) have a similar setproctitle() vulnerability. AllInstall wu-ftpd-2.6.2.Version 2.6.2 compiles cleanly under NeXTStep 3.3 and definitively closes a longstanding security vulnerability associated to long pathnames. If you used a previous version of WU-ftpd or Pro-ftpd, you should update immediately, as significant security flaws have been found. If you are running 2.6.1, you should upgrade immediately.
If you're interested in S/Key support, see here.
Ping Flood ("Smurf") AttackKernel hangsAll? (Mine was)Filter broadcast ICMP ("ping") packets at your router.
Sendmail(8)Versions up through 8.8.8, by default, allows the relaying of SPAM. This can lead to severe denial of service attack, especially when the recipients start complaining to you!AllUpgrade to Sendmail 8.11.x, which has relaying turned off by default, as well as other anti-spam features built in. Here's a very simple sendmail.mc file to get you started.
Fingerd(8)Gives away too much information to potential attackers. For instance finger 0@44.192.95.161 gives a list of users on your system!All*Replacement daemon. It's compiled QUAD-fat, but you'll enjoy it more if you customize pathnames.h and recompile it. For even more control over what information you give out, use it with this version of *finger.

Disclaimer:

I should emphasize that I make absolutely no guarantee that these programs will keep your computer safe and warm. Indeed, for all I know, they may cause you: acne, hair-loss, and irreparable loss of data. Examine the source-code, and test them carefully before installing. On the other hand, they work great for me and I hope that they do the same for you.

All good things come to an end. I have migrated from NeXTStep to MacOSX, so I will no longer be actively updating this page (some of you may have remarked that I've been letting it slide for a while now). For instance, no mention is made above of the Berkeley Telnetd hole (which affect MacOSX 10.04, too). On MacOSX, I've migrated to the SRP Telnetd which, in addition to plugging the hole is infinitely more secure, offering strong SRP authentication and TLS/SSL encryption. Anyone interested in porting SRP Telnet to NeXTStep is welcome to try.