APPENDIX B Unix vs. Windows: Which Is More Secure? 353 Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use. 354 Network Security: A Beginner’s Guide T he debate about which operating system is more secure has been raging for years. Is Unix more secure than Windows? Is Windows more secure than Unix? Which op - erating system should be used for mission-critical applications? If you ask these questions of ten security professionals, you are likely to get ten different answers and you will still not have a clear cut answer. An examination of both operating systems reveals that both have incorporated secu - rity into their designs. Both Unix and Windows have access control mechanisms, authen - tication mechanisms, and audit mechanisms. On the flip side, both Unix and Windows are made up of many lines of code (millions). There will certainly be bugs in that much code, and some of those bugs will cause security problems. In the following sections, we will take a look at various issues in the overall security debate. Hopefully, by the time you reach the end of this section, you will have a better un - derstanding of the issue (if not the solution). TIMES CHANGE The Internet has been around for a while. TCP/IP was designed many years ago and Unix followed closely behind it. In fact, the history of Unix and the history of the Internet are so intertwined that it is difficult to separate the two. Of course, the security issues surrounding the Internet were not immediately appar- ent. It took a while for the Internet to grow into an online community where some of the inhabitants were not completely trustworthy. When these individuals tried to break into systems, there was only one type of system to break into—Unix. And so they did. At first, the vulnerabilities that were used to gain access to systems were poor config- urations and even poorer passwords. Mostly the attackers did not do bad things to the systems but rather they wanted to see what the systems could do. Regardless of that, by the late 1980s criminal hackers were in the mix. In 1988, two events occurred that transformed the way we looked at security: ▼ The Morris worm was launched and disrupted the entire Internet. The worm used known vulnerabilities and weak passwords to gain access to a system. Once there, it replicated itself and gained access to more systems. ▲ At the end of 1988, the Computer Emergency Response Team (CERT) at Carnegie-Mellon University was formed. The first advisory was issued at the end of 1988. The perception that was gained from these events was that the Unix systems on the Internet were insecure. In fact, for all of 1989, 1990, and 1991, the only CERT advisories were about problems on Unix systems. It was not until 1992 that a CERT advisory men - tioned Windows systems (CA-92.02). This advisory was not about attacks against Win - dows systems but instead it was about the Michelangelo virus. The next CERT advisory that included Windows occurred in 1997 (CA-97.28), which described denial-of-service attacks called teardrop and land. These attacks also affected Unix systems. In fact, it was not until 1998 (CA-98.04) that a CERT advisory specifically for a vulner - ability in a Windows system was finally released. If you just look at the number of adviso - ries until that point, it would be easy to assume that Windows was a much more secure operating system. There were many fewer advisories against Windows than against Unix systems. Of course, the main reason for this was that Windows (specifically Windows NT) had not been in use very long and toward the end of the 1990s was only beginning to be used on the Internet. At the same time, the World Wide Web was coming into its own and Web servers were being made to run on Windows systems. Now there are many security advisories for Windows systems. In fact, every month there are several that are issued by Microsoft itself plus others that are issued by software vendors and other organizations. To the casual observer, it may appear that the tables have turned and now there are more vulnerabilities in Windows than in Unix. This is not quite true as vulnerabilities continue to be found in various versions of Unix and on Unix-specific applications. VIRUSES, TROJAN HORSES, AND WORMS, OH MY! Computer viruses have existed since MS-DOS was in use on PCs. First, they spread by people exchanging floppy disks. Then they spread over computer bulletin boards where unwary users downloaded infected files. Viruses were a PC problem and the problem has continued into Windows NT and Windows 2000. The newest viruses spread by e-mail and can infect documents as well as executables and boot sectors. Unix does not have any viruses, right? Wrong. There are Unix viruses but you don’t hear about them much because it is much harder for them to spread on Unix systems due to the way Unix systems segregate user memory and actions from the system and admin- istrator memory and actions. This would appear to show that Unix was more secure than Windows. Viruses are one of the most costly security issues in organizations today. Per - haps we could eliminate the problem if we all used Unix workstations? Perhaps, or per - haps the people that write such programs would just change the way they work. Unix systems have their own forms of malicious code. Remember the Morris worm that I mentioned? It was able to infect most of the systems on the Internet at the time. In fact, it was able to effectively shut down large portions of the Internet. Has any Windows virus done that? And just recently (late 2000, early 2001), the Ramen worm made an ap - pearance. This worm was capable of scanning target systems for vulnerabilities, identify - ing vulnerable systems, exploiting the vulnerability, and installing itself in the new system. Sounds pretty bad, doesn’t it? But what about the Trojan horse programs that are running around the Internet in - fecting Windows systems? (The most recent set of *.vbs programs are actually Trojan horses, not viruses as has been reported.) These programs masquerade as either a picture, movie, or program that people might want to run. When the unfortunate victim runs the file, the program infects the local system and spreads to others. The ability to call any DLL on the Windows system from inside a Visual Basic file (or a macro for that matter) allows Appendix B: Unix vs. Windows: Which Is More Secure? 355 the program to send itself via the victim’s e-mail to other potential victims. This certainly qualifies as a major security vulnerability in Windows, right? Perhaps, but Unix systems can also be infected with Trojan horses. They could arrive via e-mail attachments or they could be placed on the system by an intruder. The only real difference is that the administrator of the system must be tricked into running the pro - gram. In most cases, a normal user running the program will not achieve the same results. OPERATING SYSTEM VULNERABILITIES VS. APPLICATION VULNERABILITIES When we talk about vulnerabilities, we should note a difference between operating sys - tem vulnerabilities and vulnerabilities within an application running on the operating system. From a results point of view, many will say that it is a difference without a differ - ence since either type will get you root or administrator. While this is true, we are discuss - ing the relative security of operating systems and thus we should limit our discussion to operating system vulnerabilities, right? On the surface, this sounds like a no-brainer. But where do we draw the line between operating system and application? Is RPC part of Unix? Is Explorer part of Windows? In many cases, it is not so simple to separate out the application from the operating system. Perhaps a program like WU-FTP could be separated out as Unix systems do not need to have an FTP server and even if they did, it could be something other than WU-FTP. Same is true for MS IIS. A Windows system could use a Netscape Web server rather than IIS. But this is not the issue at all, is it? The real issue is that if an attacker can break an ap- plication, why does this allow the attacker to gain control over the entire system? Unfor- tunately, many applications must run as root or administrator in order to work properly. This forces the administrator of the system in question to trust the application to work properly and to not have any vulnerabilities. Well, we already know that that is not a good assumption. The list of application vulnerabilities is long and includes mail, DNS, FTP servers, Web servers, and so on. Just about every type of application that runs on top of Unix or Windows and makes services available over the network has had a serious vul - nerability at one time or another. And it seems that system administrators are powerless to control the root access of these applications! If for no other reason, applications that open ports below 1024 must be root just to open the port and listen for connections. Perhaps this is a reason to scrap both Unix and Windows and start from scratch to get rid of some of these problems! INTERACTIVE VS. NON-INTERACTIVE Let’s leave the discussion of vulnerabilities for a moment and talk about how the two op - erating systems are used. Unix systems tend to be interactive via the command line. If you telnet into the system, you are interacting with a shell and providing commands to be 356 Network Security: A Beginner’s Guide carried out by the operating system. You can move around the directory structure by is - suing cd commands. You can look at files and run programs. On a Windows system things are a little different. Sure, there is a command prompt where I can do similar things but the command prompt is available via the system con - sole (the desktop). I can’t telnet into a Windows system (by the way, with Windows 2000, you can start a telnet daemon and thus telnet into the system for a command prompt, but let’s talk more about history for a moment). Generally, it is difficult to get the same type of interactive access to a Windows system. There are, of course, programs that give you con - trol of a remote Windows desktop. These tools range from commercial tools like PC Any - where to hacker tools like Back Orifice and Sub Seven. Perhaps we should think of these remote control tools as the equivalent of telneting into a Unix system or gaining a root shell through an exploit. If you think about it, before these remote control tools came on the scene, hackers did bad things to Windows systems but they always had to load software to do it. Now, if the remote control tool exists on a system, I can look for the same types of vulnerabilities that I looked for on Unix sys - tems—bad configurations and weak passwords. If I can guess the administrator’s pass - word to PC Anywhere loaded on a server, I can control the server. So maybe there was something to this interactive versus non-interactive concept at one time but maybe it has gone away. Of course, the attacker still needs to get the remote control tool loaded on a system but there are many ways to do this (just think back to the fun you could have if one of the *.vbs Trojans loaded Back Orifice on all of your desktops!). SOURCE CODE OR NO SOURCE CODE There is a concept in the security world that says that a program that has been reviewed by others is more secure than one that has not. Cryptographers take this to extremes by saying that any algorithm that has not been reviewed by the world is not appropriate for use (OK, so I am exaggerating a bit). The U.S. government used to put all software that was written for nuclear weapons release through a program called IV&V (Independent Verification and Validation). This meant that the code was written by one team and an - other team from a different company would review it line by line to verify what it did. This makes sense for code that could launch a nuclear weapon. But does this concept make sense for operating systems or applications? Certainly, peer review makes code better. There are hundreds of stories of reviews identifying better ways to do things to make the code more efficient or to spot problems before they get into the complied executables. I am also sure that every manufacturer of software has some mechanism for internal peer review. It only makes sense. There is a difference here between some forms of Unix and Windows. You can get the source code for some forms of Unix (such as Linux, FreeBSD, and so on). You can’t get the source code for Windows. Does this mean that we should lump versions of Unix that do not have released source code in with Windows as far as security is concerned? I don’t know. How are we dividing up our operating systems? Is the debate no longer Unix Appendix B: Unix vs. Windows: Which Is More Secure? 357 versus Windows but rather open source versus closed source? That would change things a bit, wouldn’t it? I’m not sure that you would find the proof to make this type of argument anyway. Some of the software with the most security vulnerabilities has been open source. On the other hand, some of the most secure versions of Unix are also open source. One thing I should mention on this topic, however, is that open source had one real benefit. If I have the appropriate expertise and I have an open source operating system, I can change it and perhaps reduce the security vulnerabilities. If the operating system does not come with source code, I can’t do that. I have to live with the security provided by the vendor and wait for the vendor to make patches for security vulnerabilities. EXPERTISE There is one last issue I would like to mention on this topic. A good system administrator is the best security your organization can have. What makes a good system administra - tor? Perhaps it is knowledge of the operating system or number of years of experience. Perhaps there are other character traits that make someone just a good employee. Is a good system administrator a good system administrator on any operating sys- tem? I’m sure there are some people like this. But I would be willing to bet that a good Windows administrator might not be too good at Unix (at least at first) and vice versa. Maybe it is better to say that a good system administrator could be good at any oper- ating system given the appropriate amount of training and experience. If we accept this statement as true, then perhaps the expertise of the administrators plays a role in the se- curity of the operating system. It would be silly to claim otherwise. Of course, the exper- tise of the administrator plays a role in the security of a system. CONCLUSION So what can we finally say about the security of Unix versus Windows? In the end, not much. When Windows NT first began to be used for Internet applications, there may have been an argument (albeit weak) that Windows was more secure since it had fewer known vulnerabilities. Of course, the reason that fewer were known was that the systems were hard to find on the Internet. Most of them were deep inside organizations where the common attacker could not reach them. Over time we saw this myth contradicted. What about inherent problems in the operating systems? Windows allows viruses but both operating systems have trouble with Trojan horses and worms seem to be more of a problem for Unix. It would appear that malicious code causes problems for both operat - ing systems. We could almost argue that both operating systems are fairly secure and that it is the applications that cause all the problems. Almost. But where does the operating system stop and the application start? And, is it not the operating system’s problem when many applications have to run with excessive privileges? 358 Network Security: A Beginner’s Guide Both operating systems appear to be interactive these days. So if an attacker gains ac - cess, he can really gain access. Once into the system, the attacker can take total control of the system. Files can be deleted and even the CD-ROM can be opened remotely. Does peer review and the availability of source code make one more secure than the other? Hardly. If this were the case, Linux should have no bugs at all! And Solaris and Windows should be equivalent in security. What are we left with? The expertise of the administrator. When it comes right down to it, the security of the system depends overwhelmingly on the expertise of the adminis - trator. The administrator must configure the system securely on setup. The administrator must add and remove software as necessary. The administrator must follow procedure to add and remove users from the system. The administrator must keep up with patches and fixes on the system. And finally, the administrator must keep watch on the system to identify when problems occur. Is Unix more secure than Windows? Is Windows more secure than Unix? The answer to both questions is yes and no. Who is the system administrator for the system in question? Appendix B: Unix vs. Windows: Which Is More Secure? 359 This page intentionally left blank. TEAMFLY Team-Fly ® . no-brainer. But where do we draw the line between operating system and application? Is RPC part of Unix? Is Explorer part of Windows? In many cases, it is not so simple to separate out the application