Kirsten Johnsen
Computer Ethics
Final Draft
December 6, 2000
The Internet is rapidly changing the world. Within a few decades, access to information has skyrocketed to mind-numbing heights. As the “digital age” progresses greater amounts of vital information is stored on machines that are connected to the Internet. At first, protection of this information wasn’t incredibly difficult because not enough people had the skills and access to tools to allow them to find and steal such information. As the Internet developed, such tools became common and it has become necessary to find ways to protect information from the general population. Two philosophies have arisen that address this question. The “closed source’’ community tends to hold to the idea of security through obscurity. The “open source” community holds to the idea of “many eyeballs.”
What are these communities and what do they stand for? The “closed source” community consists primarily of larger corporations that do not with to release the source to their programs. They do this for a myriad of reasons ranging from a simple wish for a profit to the belief that it’s harder to break into a system that you can’t see the code for. The “open source” community is the exact opposite. It thrives on code that is freely available to the public to both be seen and modified. The “open source” community believes that programs can only be easily and efficiently improved with the sharing of knowledge and ideas.
The “hacker community” thrives on the sharing of information about exploits and scripts and programs to help facilitate the use of such exploits. Security experts that hold with the “many eyeball” philosophy believe that in order to keep security up to date it is just as necessary to share data about common security holes and the holes in the existing software. Many companies and other groups of security experts have tried to create databases that contain lists of the security issues that are currently in programs, but have been unable to amount more than a small segment of the data. Even the companies that specialize in the logging the security issues don’t want to share with other such groups because they hope to possibly making a profit off of the information in the future.
The world of closed source doesn’t share information about security breaches if they can help it. They believe in the idea of security through obscurity and only release their code in binary format. “In one recent study conducted by the FBI and the Computer Security Institute, only about 17 percent of companies said they had reported their computer break-ins to law enforcement”[i] Why haven’t these companies publicized these break-ins and attempted to track down the perpetrator or perpetrators? Often, such companies are worried more about publicity then making the exploit known so people can protect against it. Most companies would prefer to quietly write a bug fix and simply put it in the next patch than inform people that there is a current security hole in the software, assuming, of course, that the bug fix is ever made. Without a well-publicized code in the bug there’s always the possibility that company won’t have enough incentive to bother with a security fix in the software.
Before the ethics of either method can be judged, ethics
needs to be understood. Ethics is defined as:
Ethics is often confused with morals, but while similar,
they are not the same. Morals is defined as:
As can be seen ethical principles are based on the moral standards of the society in question. What morals are “correct” is in question right now in regards to the new fields being opened up by computers. “Good” and “bad” have yet to be fully defined in regards to whether hacking is a “good” development in the world right now. I am going to work off the following basis for loose definitions of “good” and “bad.” Good: Anything that works in the favor of the general population. Bad: Anything that is the opposite, just benefits a select few.
The Security Through Obscurity method of protecting information only works when security bugs in software are actually fixed quickly. Because the user’s of the software are not informed of the existence of each bug they are vulnerable to attack and possibly may not be able to detect that such an attack has been made. Obscurity is only useful if the “hacker population” is unaware of the possible security hole, once one hacker knows that hole, it is quite likely to be learned of by many others because they share information with each other. Security Through Obscurity, in general, is not ethical when the obscurity is meant to protect the company providing the software rather than the user who is running the software because protecting the company only protects a select few.
Open software has its own problems with its design and the philosophy of the “many eyeballs” technique. In open source there are a lot of inexperienced programmers contributing to the general software pool. When the code goes public it doesn’t necessarily get as close a scrutiny as is required, especially if it is complex, badly written, or written in a less popular language. For example, the GNU mailing list program, Mailman, was written in Python by a team including John Viega. This code was included in corporate versions of Linux and was in general considered to be secure. However, after three years in the source tree, John Viega finally learned enough about security to realize that he had left numerous exploits in the program. No one had reported such exploits because the code was in a less known language. Fewer people could read the code and few people made an effort to change more than small parts of the code for their own personal use. However, when security bugs are found in Open Source software, they are fixed as soon as possible or the software is marked as insecure in some method that depends on which OS is in question. Open Source posts its bugs publicly and the public fixes them, this is consistent with the entire idea of open source and is quite ethical.
What happens when security bugs are posted for software following the closed source model? There are a number of sites and groups that keep track of security flaws in closed source software. These sites are designed to help the user protect him/herself from companies that aren’t fixing bugs in their software by keeping the user aware of where the bug is. There are two inherit questions that need to be answered before it can be decided whether such lists are ethical or not. When, if ever, should closed source model programs have their bugs publicly listed? How much information about the program should be posted?
Bugs should be publicly listed if and only if the company in question is unethical about updating its programs. If the company in question isn’t releasing a fix because they believe that posting a bug fix, or patch, would damage their relations with their customers (future and current), then that company is being unethical. Companies should be worried first about protecting their customers from attacks because of their software. Users and programmers should be working together for the common protection of both groups. If the company though, has given some sign to the person(s) who submitted the bug that the fix is in the works, than the bug should not be posted. What happens if a company is taking “too long” in fixing the bug? The problem with this question is the undefined quantity “too long.” How long is it viable for a known security hole to be out in the public while a patch is being made? This question is entirely subjective. Many believe that patches should be virtually instantaneous, but this would cause companies to be constantly patching their software. There is no right answer here, some companies wait to conglomerate a bunch of bugs together into one patch, or do patches at particular points during the year, while others wait until the next version of the software. It is ethical to do all but the last option from those listed above. The last option (generally) requires that the user pay for the patch. This really only benefits the corporation which should be relying on other incentives to get the user to upgrade their software and still leaves all the previous versions of the software with security holes.
How much information about bugs should be reported to mailing lists and in what form should the information be presented? This question is another muddy one. A lot of bug tracking mailing lists have bugs posted in the form of exploits. Many of these can just be copied and pasted by a “script-kiddie” who then takes advantage of the hole by attacking various computers. A script-kiddie is defined as:
Posting bugs, regardless of whether they pertain to open-source or closed-source model software is not ethical. Posting bugs is supposed to keep users aware of the inherent flaws in programs they may be running. Posting bugs is not supposed to tell script-kiddies how to go hack a system that they couldn’t previously hack. To post ethically, there should be enough information that a knowledgeable user can protect the system that the program is running without sending an attack beacon to every system running the program. Posting real information rather than a simple exploit also shows users exactly what the real problem is rather than just how to exploit it.
Which security model is more ethical? Which one will support the computing community at large? In 1998 Alan Cox announced to the Bugtraq mailing list, which is used to track security bugs in open source projects, a security hole in the Solaris operating system. Alan Cox had notified Sun of this whole over a year before he made the bug public and was told that he had failed to notify the “correct people.” What did Sun mean by the “correct people”? Did they want him to find the people in their company responsible for coding the bug? Or was this just a way to cover the fact that they’d been previously notified of the problem and hadn’t done anything about it? Is this moral? Is it wrong to not fix a bug in an operating system once it is known and keep the operating secure? Or is it better to sit on the problem and possibly fix it in the next distribution of the program or operating system? The second option certainly saves on the possibility of bad publicity, but the first leaves many systems high and dry in terms of security.
Which model is ethical? Both models can be approached in an ethical manner, provided that the common good is kept in mind. To remain ethical while deal with the security issues inherent in software security it is necessary to weight the possible ramification of each action and act accordingly. Not releasing fixes to known bugs because of possible bad publicity is not ethical. Providing bugs to the general public without giving closed-source companies a chance to fix the bug is also unethical. Providing exploits of bugs rather than explanations of bugs to mailing lists is unethical. Using the idea of security through obscurity is ethical when bug patches are released for known bugs. Providing information (possibly detailed) about bugs to a mailing list designed to track bugs is ethical under certain circumstances if in regards to closed source and is also expected in regards to open-source. Ethics in the computer industry should be based on the common good of the computing industry. Keeping the industry healthy and the users happy and secure is the best way to keep support and development of the Internet moving at the current rate.
Sources:
Security through obscurity - Why are we helping hackers?
“ by Carole Fennelly
http://www.sunworld.com/sunworldonline/swol-10-2000/swol-1013-unixsecurity.html
“The Other Side Of The Story” by Lewis Z. Koch
http://www.zdnet.com/intweek/stories/columns/0,4164,2634819,00.html
“Ranum
In The Lion's Den” by Lewis Z. Koch
http://www.zdnet.com/intweek/stories/columns/0,4164,2630983,00.html
“It's 'many eyes' vs. 'security
by obscurity' “ by scott_berinato
http://www.zdnet.co.uk/news/2000/12/ns-14378.html
Hacker puts big IIS sites on warning”
by Joris Evers, InfoWorld
http://www2.itworld.com/cma/ett_article_frame/0,2848,1_2844,00.html
“Musings on open source security
models” by Michael H. Warfield
http://www.linuxworld.com/linuxworld/lw-1998-11/lw-11-ramparts.html
“The Myth of Open Source
Security” by John Viega
http://www.earthweb.com/dlink.resource-jhtml.72.952.|repository||itmanagement|content|article|2000|07|19|EMviegaopen|EMviegaopen~xml.0.jhtml?pageNo=1&cda=true
[i] http://www.techweb.com/printable Article?doc_id=TWB19980925S001