Slashdot Mirror

Anonymous Coward writes "Kevin Poulson writes in an article in SecurityFocus that in an early draft of the White House's "National Strategy to Secure Cyberspace", the DOJ proposes that the US enact European style 'data retention' laws, which force ISPs to log and retain all of your email headers, as well as your Web browsing history." Nothing worse for the DOJ to be upstaged by Europe in oppressive lawmaking, they must feel like they're losing their edge. Update: 06/19 23:04 GMT by M : The SecurityFocus article has been updated with this note, saying that the U.S. denies having any plans for data-retention laws. Guess we'll have to wait until the plan is released to see.

Anonymous Coward writes "Kevin Poulson writes in an article in SecurityFocus that in an early draft of the White House's "National Strategy to Secure Cyberspace", the DOJ proposes that the US enact European style 'data retention' laws, which force ISPs to log and retain all of your email headers, as well as your Web browsing history." Nothing worse for the DOJ to be upstaged by Europe in oppressive lawmaking, they must feel like they're losing their edge. Update: 06/19 23:04 GMT by M : The SecurityFocus article has been updated with this note, saying that the U.S. denies having any plans for data-retention laws. Guess we'll have to wait until the plan is released to see.

Anonymous Coward writes "Kevin Poulson writes in an article in SecurityFocus that in an early draft of the White House's "National Strategy to Secure Cyberspace", the DOJ proposes that the US enact European style 'data retention' laws, which force ISPs to log and retain all of your email headers, as well as your Web browsing history." Nothing worse for the DOJ to be upstaged by Europe in oppressive lawmaking, they must feel like they're losing their edge. Update: 06/19 23:04 GMT by M : The SecurityFocus article has been updated with this note, saying that the U.S. denies having any plans for data-retention laws. Guess we'll have to wait until the plan is released to see.

sevenn writes "A new worm, targeting the Microsoft SQL daemon, has been sweeping the net. It uses massive scanning, default passwords, exploits against vulnerable versions and even attempts to brute force passwords. Here is the (vague) Microsoft bulliten, the SANS analysis, and a securityfocus article" Already over a thousand compromised system- you're apparently only vulnerable if you run MS SQL, but the worm is causing a substantial spike in traffic to port 1433 on the net.

Reverend Raven writes "This is from Security Focus and deals with how some people believe a group of uber-hackers controls the Vegas telecom system. Interesting read, indeed." A follow-up to this old story. The case seems to be still winding its way through the bureaucracy.

mkraft writes "Microsoft released another security patch for Internet Explorer to fix 6 'new' vulnerabilities. Info on the patch can be obtained via download or Windows Update. Not sure what 6 things the patch fixed, but I'm assuming they fixed 6 of the 14 known exploits listed at http://jscript.dk/unpatched/" Maybe not even all six -- the maintainer of the above URL claims in a post to Bugtraq that Microsoft got some facts wrong and "patched a symptom" of one of the vulnerabilities, "not its root cause," and that IE5 and IE5.5 remain unpatched with the same "Critical" vulnerability. Also, please compare to previous MSIE Uber-Patches Of The Month: December 2001, 3+? holes in IE; March 2002, 2+? holes in IE; April 2002, 2+? holes in Mac IE.

Anonymous Coward writes "Cable modem uncapping allows broadband customers to boost their bandwidth to 6 or 7 times what they're paying for, by spoofing their modem's TFTP client into downloading a hacked DOCSIS configuration file. Kevin Poulsen at SecurityFocus reports that a new underground program called OneStep makes the process easy and fun for the whole family. Broadband companies are cutting off the uncappers that they catch, but things could get out of control soon."

Anonymous Coward writes "Cable modem uncapping allows broadband customers to boost their bandwidth to 6 or 7 times what they're paying for, by spoofing their modem's TFTP client into downloading a hacked DOCSIS configuration file. Kevin Poulsen at SecurityFocus reports that a new underground program called OneStep makes the process easy and fun for the whole family. Broadband companies are cutting off the uncappers that they catch, but things could get out of control soon."

cjpez writes: "The people at the Honeynet have issued another challenge on the Bugtraq mailing list. Instead of hacking into a box, though, this time your goal is to submit the best analysis of a binary file they'll post on Monday, May 6th. Think you're good at reverse engineering? Then try it out! They're even offering actual prizes, so you can get something besides the feeling of personal fulfillment for your trouble. The post hasn't quite made it to SecurityFocus' Bugtraq Archive yet, but I did find it at another Bugtraq archive in Germany (slashdottings abound!). The URL included in the email, http://project.honeynet.org/reverse/, doesn't seem to be active yet, so presumably we can assume it'll go up on Monday. The post fails to address other concerns, though: will the winner be in violation of the DMCA? :P The challenge was also issued, obviously enough, on SecurityFocus' Honeypot mailing list."" In a later note, he points out that the announcement has finally made it to the Bugtraq archive page." (And that URL is active now.)

cjpez writes: "The people at the Honeynet have issued another challenge on the Bugtraq mailing list. Instead of hacking into a box, though, this time your goal is to submit the best analysis of a binary file they'll post on Monday, May 6th. Think you're good at reverse engineering? Then try it out! They're even offering actual prizes, so you can get something besides the feeling of personal fulfillment for your trouble. The post hasn't quite made it to SecurityFocus' Bugtraq Archive yet, but I did find it at another Bugtraq archive in Germany (slashdottings abound!). The URL included in the email, http://project.honeynet.org/reverse/, doesn't seem to be active yet, so presumably we can assume it'll go up on Monday. The post fails to address other concerns, though: will the winner be in violation of the DMCA? :P The challenge was also issued, obviously enough, on SecurityFocus' Honeypot mailing list."" In a later note, he points out that the announcement has finally made it to the Bugtraq archive page." (And that URL is active now.)

cjpez writes: "The people at the Honeynet have issued another challenge on the Bugtraq mailing list. Instead of hacking into a box, though, this time your goal is to submit the best analysis of a binary file they'll post on Monday, May 6th. Think you're good at reverse engineering? Then try it out! They're even offering actual prizes, so you can get something besides the feeling of personal fulfillment for your trouble. The post hasn't quite made it to SecurityFocus' Bugtraq Archive yet, but I did find it at another Bugtraq archive in Germany (slashdottings abound!). The URL included in the email, http://project.honeynet.org/reverse/, doesn't seem to be active yet, so presumably we can assume it'll go up on Monday. The post fails to address other concerns, though: will the winner be in violation of the DMCA? :P The challenge was also issued, obviously enough, on SecurityFocus' Honeypot mailing list."" In a later note, he points out that the announcement has finally made it to the Bugtraq archive page." (And that URL is active now.)

Saint Aardvark writes: "From the Bugtraq mailing list comes this warning: 'Using the Back Button in IE is dangerous'. When hitting the back button, javascript links will be executed in the security zone of the last url viewed. Proof-of-concept included in the warning will execute minesweeper or read your Google cookies."

Saint Aardvark writes: "From the Bugtraq mailing list comes this warning: 'Using the Back Button in IE is dangerous'. When hitting the back button, javascript links will be executed in the security zone of the last url viewed. Proof-of-concept included in the warning will execute minesweeper or read your Google cookies."

Daffy writes "Jon Lasser at SecurityFocus has an idea for combating the tendancy most sysadmins have to leave old versions of software running long after they're known to have security holes. He proposes implanting time codes into all open source networking and security software that cause it to "expire" like a Blade Runner replicant when it reaches a certain age, forcing an update."

awptic writes "The March Netcraft survey is out. Among the changes is a 4% increase in the number of websites running IIS, primarily due, however, to register.com's domain name parking service switching to mostly IIS servers, which account for over 2 million of the 38 million sites surveyed. Ironically, a large number of the websites were defaced shortly thereafter."

antiher0 writes "According to an email from Lucky Green that came across bugtraq yesterday, 1024-bit encryption should no longer be considered pristine. Bernstein released a proposal that outlines the creation of a machine capable of breaking 1024-bit crypto on the order of minutes or even seconds for the measly cost of ~$1B USD. For a more thorough discussion, check out the original email." Update: 03/26 03:16 GMT by T : And don't forget to revisit Bruce Schneier's analysis of Bernstein's claims, which cast doubt on the practicality of breaking such large keys anytime soon.

antiher0 writes "According to an email from Lucky Green that came across bugtraq yesterday, 1024-bit encryption should no longer be considered pristine. Bernstein released a proposal that outlines the creation of a machine capable of breaking 1024-bit crypto on the order of minutes or even seconds for the measly cost of ~$1B USD. For a more thorough discussion, check out the original email." Update: 03/26 03:16 GMT by T : And don't forget to revisit Bruce Schneier's analysis of Bernstein's claims, which cast doubt on the practicality of breaking such large keys anytime soon.

Tim Jackson writes: "In a depressing development for those wanting to protect themselves against spam, it appears that popular open relay database ORBZ (formerly at www.orbz.org) has shut down effective immediately - see here for the final post from ORBZ admin Ian Gulliver on the ORBZ list explaining the reasons behind the closure. The 'Lotus Domino' issue he refers to is the issue he discovered in the course of running ORBZ and reported to Buqtraq, which means that certain SMTP envelopes (such as those sent by ORBZ when testing for open relays) cause Lotus Domino servers to go into a loop, effectively creating a DoS situation. Unfortunately (but understandably), irrelevant of the merits of the case, Ian doesn't want to risk jail for the sake of spam fighting. Of course, if common sense prevailed, it would be the mail server vendor in court for producing insecure mail server software, not a third party for happening to send requests that unintentionally crash poorly-written servers."

juliao writes "SecurityFocus is reporting that alleged eBay hacker Jerome Heckenkamp was jailed after his first solo court appearance." It's pretty funny actually, stuff like challenging the indictment on the grounds that they typed his name in all capital letters, demanding to immediately testify (even tho they were only there to schedule the trial), threatening the judge and so on. He would know better if he watched a couple episodes of Law & Order. Note that I base all court proceedings on the wisdom of Sam Watterston.

Selanit writes "I just found a link on Distrowatch to a SecurityFocus Review of IP Cop 0.1.1. IP Cop is a fork of the GPL version of the Smoothwall Linux firewall distro, which had a review linked by Slashdot. Though it has a slick, easy install. and good features, a number of people had issues with Smoothwall.. IPCop has implemented shadow passwords to fix the security flaw, and their mission statement includes a provision that they will "Provide an enjoyable environment for the Public to discuss and request assistance." The to-do list of features for the upcoming 0.2 version is also interesting. "

satch89450 writes: "SecurityFocus had a column that I missed when it was first published a few days ago, titled 'Responsible Disclosure' Draft Could Have Legal Muscle, but I discovered it when researching an answer to a comment on the CYBERIA mailing list. In this article, Mark Rasch discusses how the Draft would set the rules for reporting security vunerabilities, and in particular define the boundaries of liability assumed by bug-disclosers. By adopting a "Best Practices" RFC, the IETF could help the reporters of security-related bugs do their job, and put the onus of fixing the bugs on the vendors who make the mistakes, where it belongs. (The RFC draft described in the article, 'Responsible Vulnerability Disclosure Process, is here at the ISI repository.) This is, of course, in direct opposition to the process that Microsoft's Scott Culp, Manager of the Microsoft Security Response Center, would like to see. As Microsoft is more part of the problem than part of the solution, I believe that the path to a formal process would better serve the entire community - and that community includes Microsoft's customers. I'm taking this seriously because the mainstream press is talking about the issue, and what it's going to take to fix it. Here is an example from BusinessWeek that scares me silly. I'm glad I'm looking to change careers from software development to something safe, like law."

iGawyn writes "As reported in this BugTraq post, Mac OS and Mac OS X (via Classic) are both subject to an auto-execution vulnerability. In short, the poster says that various web browsers can automatically download a disk image containing malicious code and run it without ever telling the user. vm_converter made a test page to demonstrate the vulnerability." Yes, this is a nice variation on a theme. The lesson is: don't ever have "CD-ROM AutoPlay" turned on in your QuickTime preferences.

Saint Aardvark writes: "Something interesting from the SecurityFocus Honeypot mailing list: a couple of honeypots for spammers. This message has a link to a how-to page for setting up a Sendmail honeypot to trap spammers, and the status page for a honeypot in Moscow that's trapped spam meant for >1.7 million recipients. The author mentions using a honeypot in conjunction with the Distributed Checksum Clearinghouse -- this seems like a great way identify both spammers and their messages."

And C-Moan writes: "Wireless spam volume is likely to increase in the coming years. But smart use of spam-fighting measures can go a long way toward eliminating the problem. This article provides info about the latest crop of e-mail filters and enhanced mail client options, as well as two roll-your-own programming platforms that could help keep your in-boxes spam free."

Saint Aardvark writes: "Something interesting from the SecurityFocus Honeypot mailing list: a couple of honeypots for spammers. This message has a link to a how-to page for setting up a Sendmail honeypot to trap spammers, and the status page for a honeypot in Moscow that's trapped spam meant for >1.7 million recipients. The author mentions using a honeypot in conjunction with the Distributed Checksum Clearinghouse -- this seems like a great way identify both spammers and their messages."

And C-Moan writes: "Wireless spam volume is likely to increase in the coming years. But smart use of spam-fighting measures can go a long way toward eliminating the problem. This article provides info about the latest crop of e-mail filters and enhanced mail client options, as well as two roll-your-own programming platforms that could help keep your in-boxes spam free."

Dare Obasanjo contributed this followup to an article entitled The Myth of Open Source Security Revisited that appeared on the website kuro5hin. He writes: "The original article tackled the common misconception amongst users of Open Source Software(OSS) that OSS is a panacea when it comes to creating secure software. The article presented anecdotal evidence taken from an article written by John Viega, the original author of GNU Mailman, to illustrate its point. This article follows up the anecdotal evidence presented in the original paper by providing an analysis of similar software applications, their development methodology and the frequency of the discovery of security vulnerabilities." Read on below for his detailed analysis, especially relevant with the currency of security initiatives in the worlds of both open- and closed-source software.

The Myth of Open Source Security Revisited v2.0 The purpose of this article is to expose the fallacy of the belief in the "inherent security" of Open Source software and instead point to a truer means of ensuring the quality of the security of a piece software is high.

Apples, Oranges, Penguins and Daemons

When performing experiments to confirm a hypothesis on the effect of a particular variable on an event or observable occurence, it is common practice to utilize control groups. In an attempt to establish cause and effect in such experiments, one tries to hold all variables that may affect the outcome constant except for the variable that the experiment is interested in. Comparisons of the security of software created by Open Source processes and software produced in a proprietary manner have typically involved several variables besides development methodology.

A number of articles have been written that compare the security of Open Source development to proprietary development by comparing security vulnerabilities in Microsoft products to those in Open Source products. Noted Open Source pundit, Eric Raymond wrote an article on NewsForge where he compares Microsoft Windows and IIS to Linux, BSD and Apache. In the article, Eric Raymond states that Open Source development implies that "security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed." However, upon investigation it is disputable that Linux distributions have less frequent or more minor security vulnerabilities when compared to recent versions of Windows. In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.

There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct. The following section analyzes the frequency of the discovery of security vulnerabilities in UNIX-like operating systems including HP-UX, FreeBSD, RedHat Linux, OpenBSD, Solaris, Mandrake Linux, AIX and Debian GNU/Linux.

Security Vulnerability Face-Off

Below is a listing of UNIX and UNIX-like operating systems with the number of security vulnerabilities that were discovered in them in 2001 according to the Security Focus Vulnerability Archive. AIX 10 vulnerabilities[6 remote, 3 local, 1 both] Debian GNU/Linux 13 vulnerabilities[1 remote, 12 local] + 1 Linux kernel vulnerability[1 local] FreeBSD 24 vulnerabilities[12 remote, 9 local, 3 both] HP-UX 25 vulnerabilities[12 remote, 12 local, 1 both] Mandrake Linux 17 vulnerabilities[5 remote, 12 local] + 12 Linux kernel vulnerabilities[5 remote, 7 local] OpenBSD 13 vulnerabilities[7 remote, 5 local, 1 both] Red Hat Linux 28 vulnerabilities[5 remote, 22 local, 1 unknown] + 12 Linux kernel vulnerabilities[6 remote, 6 local] Solaris 38 vulnerabilities[14 remote, 22 local, 2 both] From the above listing one can infer that source licensing is not a primary factor in determining how prone to security flaws a software application will be. Specifically proprietary and Open Source UNIX family operating systems are represented on both the high and low ends of the frequency distribution.

Factors that have been known to influence the security and quality of a software application are practices such as code auditing (peer review), security-minded architecture design, strict software development practices that restrict certain dangerous programming constructs (e.g. using the str* or scanf* family of functions in C) and validation & verification of the design and implementation of the software. Also reducing the focus on deadlines and only shipping when the system the system is in a satisfactory state is important.

Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record. Debian's track record is particularly impressive when one realizes that the Debian Potato consists of over 55 million lines of code (compared to RedHat's 30,000,000 lines of code).

The Road To Secure Software

Exploitable security vulnerabilities in a software application are typically evidence of bugs in the design or implementation of the application. Thus the process of writing secure software is an extension of the process behind writing robust, high quality software. Over the years a number of methodolgies have been developed to tackle the problem of producing high quality software in a repeatable manner within time and budgetary constraints. The most successful methodologies have typically involved using the following software quality assurance, validation and verification techniques; formal methods, code audits, design reviews, extensive testing and codified best practices.

1. Formal Methods: One can use formal proofs based on mathematical methods and rigor to verify the correctness of software algorithms. Tools for specifying software using formal techniques exist such as VDM and Z. Z (pronounced 'zed') is a formal specification notation based on set theory and first order predicate logic. VDM stands for "The Vienna Development Method" which consists of a specification language called VDM-SL, rules for data and operation refinement which allow one to establish links between abstract requirements specifications and detailed design specifications down to the level of code, and a proof theory in which rigorous arguments can be conducted about the properties of specified systems and the correctness of design decisions.The previous descriptions were taken from the Z FAQ and the VDM FAQ respectively. A comparison of both specification languages is available in the paper, Understanding the differences between VDM and Z by I.J. Hayes et al.
   
   
2. Code Audits: Reviews of source code by developers other than the author of the code are good ways to catch errors that may have been overlooked by the original developer. Source code audits can vary from informal reviews with little structure to formal code inspections or walkthroughs. Informal reviews typically involve the developer sending the reviewers source code or descriptions of the software for feedback on any bugs or design issues. A walkthrough involves the detailed examination of the source code of the software in question by one or more reviewers. An inspection is a formal process where a detailed examination of the source code is directed by reviewers who act in certain roles. A code inspection is directed by a "moderator", the source code is read by a "reader" and issues are documented by a "scribe".
   
   
3. Testing: The purpose of testing is to find failures. Unfortunately, no known software testing method can discover all possible failures that may occur in a faulty application and metrics to establish such details have not been forthcoming. Thus a correlation between the quality of a software application and the amount of testing it has endured is practically non-existent.
   
   There are various categories of tests including unit, component, system, integration, regression, black-box, and white-box tests. There is some overlap in the aforementioned mentioned testing categories.
   
   Unit testing involves testing small pieces of functionality of the application such as methods, functions or subroutines. In unit testing it is usual for other components that the software unit interacts with to be replaced with stubs or dummy methods. Component tests are similar to unit tests with the exception that dummmy and stub methods are replaced with the actual working versions. Integration testing involves testing related components that communicate with each other while system tests involve testing the entire system after it has been built. System testing is necessary even if extensive unit or component testing has occured because it is possible for seperate subroutines to work individually but fail when invoked sequentialy due to side effects or some error in programmer logic. Regression testing involves the process of ensuring that modifications to a software module, component or system have not introduced errors into the software. A lack of sufficient regression testing is one of the reasons why certain software patches break components that worked prior to installation of the patch.
   
   Black-box testing also called functional testing or specification testing test the behavior of the component or system without requiring knowledge of the internal structure of the software. Black-box testing is typically used to test that software meets its functional requirements. White-box testing also called structural or clear-box testing involves tests that utilize knowledge of the internal structure of the software. White-box testing is useful in ensuring that certain statements in the program are excercised and errors discovered. The existence of code coverage tools aid in discovering what percentages of a system are being excercised by the tests.
   
   More information on testing can be found at the comp.software.testing FAQ .
   
   
4. Design Reviews: The architecture of a software application can be reviewed in a formal process called a design review. In design reviews the developers, domain experts and users examine that the design of the system meets the requirements and that it contains no significant flaws of omission or commission before implementation occurs.
   
   
5. Codified Best Practices: Some programming languages have libraries or language features that are prone to abuse and are thus prohibited in certain disciplined software projects. Functions like strcpy, gets, and scanf in C are examples of library functions that are poorly designed and allow malicious individuals to use buffer overflows or format string attacks to exploit the security vulnerabilities exposed by using these functions. A number of platforms explicitly disallow gets especially since alternatives exist. Programming guidelines for such as those written by Peter Galvin in a Unix Insider article on designing secure software are used by development teams to reduce the likelihood of security vulnerabilities in software applications.

Projects such as the OpenBSD project that utilize most of the aforementioned techniques in developing software typically have a low incidence of security vulnerabilities.

Issues Preventing Development of Secure Open Source Software

One of the assumptions that is typically made about Open Source software is that the availability of source code translates to "peer review" of the software application. However, the anecdotal experience of a number of Open Source developers including John Viega belies this assumption.

The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including

• complexity of code in addition to a lack of documentation makes it difficult for casual users to understand the code enough to give a proper review
  
  
• developers making improvements to the application typically focus only on the parts of the application that will affect the feature to be added instead of the whole system.
  
  
• ignorance of developers to security concerns.
  
  
• complacency in the belief that since the source is available that it is being reviewed by others.
  
  

Also the lack of interest in unglamorous tasks like documentation and testing amongst Open Source contributors adversely affects quality of the software. However, all of these issues can and are solved in projects with a disciplined software development process, clearly defined roles for the contributers and a semi-structured leadership hierarchy.

Benefits of Open Source to Security-Conscious Users

Despite the fact that source licensing and source code availability are not indicators of the security of a software application, there is still a significant benefit of Open Source to some users concerned about security. Open Source allows experts to audit their software options before making a choice and also in some cases to make improvements without waiting for fixes from the vendor or source code maintainer.

One should note that there are constraints on the feasibility of users auditing the software based on the complexity and size of the code base. For instance, it is unlikely that a user who wants to make a choice of using Linux as a web server for a personal homepage will scrutinize the TCP/IP stack code.

References

1. Frankl, Phylis et al. Choosing a Testing Method to Deliver Reliability. Proceedings of the 19th International Conference on Software Engineering, pp. 68--78, ACM Press, May 1997. < http://citeseer.nj.nec.com/frankl97choosing.html >
   
   
2. Hamlet, Dick. Software Quality, Software Process, and Software Testing. 1994. < http://citeseer.nj.nec.com/hamlet94software.html >
   
   
3. Hayes, I.J., C.B. Jones and J.E. Nicholls. Understanding the differences between VDM and Z. Technical Report UMCS-93-8-1, University of Manchester, Computer Science Dept., 1993. < http://citeseer.nj.nec.com/hayes93understanding.ht ml >
   
   
4. Miller, Todd C. and Theo De Raadt. strlcpy and strlcat - consistent, safe, string copy and concatenation. Proceedings of the 1999 USENIX Annual Technical Conference, FREENIX Track, June 1999. < http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/ >
   
   
5. Viega, John. The Myth of Open Source Security. Earthweb.com. < http://www.earthweb.com/article/0,,10455_626641,00 .html >
   
   
6. Gonzalez-Barona, Jesus M. et al. Counting Potatoes: The Size of Debian 2.2. < http://people.debian.org/~jgb/debian-counting/coun ting-potatoes/ >
   
   
7. Wheeler, David A. More Than A Gigabuck: Estimating GNU/Linux's Size. < http://www.counterpane.com/crypto-gram-0003.html >
   
   

Acknowledgements

The following people helped in proofreading this article and/or offering suggestions about content: Jon Beckham, Graham Keith Coleman, Chris Bradfield, and David Dagon. © 2002 Dare Obasanjo

Dare Obasanjo contributed this followup to an article entitled The Myth of Open Source Security Revisited that appeared on the website kuro5hin. He writes: "The original article tackled the common misconception amongst users of Open Source Software(OSS) that OSS is a panacea when it comes to creating secure software. The article presented anecdotal evidence taken from an article written by John Viega, the original author of GNU Mailman, to illustrate its point. This article follows up the anecdotal evidence presented in the original paper by providing an analysis of similar software applications, their development methodology and the frequency of the discovery of security vulnerabilities." Read on below for his detailed analysis, especially relevant with the currency of security initiatives in the worlds of both open- and closed-source software.

The Myth of Open Source Security Revisited v2.0 The purpose of this article is to expose the fallacy of the belief in the "inherent security" of Open Source software and instead point to a truer means of ensuring the quality of the security of a piece software is high.

Apples, Oranges, Penguins and Daemons

When performing experiments to confirm a hypothesis on the effect of a particular variable on an event or observable occurence, it is common practice to utilize control groups. In an attempt to establish cause and effect in such experiments, one tries to hold all variables that may affect the outcome constant except for the variable that the experiment is interested in. Comparisons of the security of software created by Open Source processes and software produced in a proprietary manner have typically involved several variables besides development methodology.

A number of articles have been written that compare the security of Open Source development to proprietary development by comparing security vulnerabilities in Microsoft products to those in Open Source products. Noted Open Source pundit, Eric Raymond wrote an article on NewsForge where he compares Microsoft Windows and IIS to Linux, BSD and Apache. In the article, Eric Raymond states that Open Source development implies that "security holes will be infrequent, the compromises they cause will be relatively minor, and fixes will be rapidly developed and deployed." However, upon investigation it is disputable that Linux distributions have less frequent or more minor security vulnerabilities when compared to recent versions of Windows. In fact the belief in the inherent security of Open Source software over proprietary software seems to be the product of a single comparison, Apache versus Microsoft IIS.

There are a number of variables involved when one compares the security of software such as Microsoft Windows operating systems to Open Source UNIX-like operating systems including the disparity in their market share, the requirements and dispensations of their user base, and the differences in system design. To better compare the impact of source code licensing on the security of the software, it is wise to reduce the number of variables that will skew the conclusion. To this effect it is best to compare software with similar system design and user base than comparing software applications that are significantly distinct. The following section analyzes the frequency of the discovery of security vulnerabilities in UNIX-like operating systems including HP-UX, FreeBSD, RedHat Linux, OpenBSD, Solaris, Mandrake Linux, AIX and Debian GNU/Linux.

Security Vulnerability Face-Off

Below is a listing of UNIX and UNIX-like operating systems with the number of security vulnerabilities that were discovered in them in 2001 according to the Security Focus Vulnerability Archive. AIX 10 vulnerabilities[6 remote, 3 local, 1 both] Debian GNU/Linux 13 vulnerabilities[1 remote, 12 local] + 1 Linux kernel vulnerability[1 local] FreeBSD 24 vulnerabilities[12 remote, 9 local, 3 both] HP-UX 25 vulnerabilities[12 remote, 12 local, 1 both] Mandrake Linux 17 vulnerabilities[5 remote, 12 local] + 12 Linux kernel vulnerabilities[5 remote, 7 local] OpenBSD 13 vulnerabilities[7 remote, 5 local, 1 both] Red Hat Linux 28 vulnerabilities[5 remote, 22 local, 1 unknown] + 12 Linux kernel vulnerabilities[6 remote, 6 local] Solaris 38 vulnerabilities[14 remote, 22 local, 2 both] From the above listing one can infer that source licensing is not a primary factor in determining how prone to security flaws a software application will be. Specifically proprietary and Open Source UNIX family operating systems are represented on both the high and low ends of the frequency distribution.

Factors that have been known to influence the security and quality of a software application are practices such as code auditing (peer review), security-minded architecture design, strict software development practices that restrict certain dangerous programming constructs (e.g. using the str* or scanf* family of functions in C) and validation & verification of the design and implementation of the software. Also reducing the focus on deadlines and only shipping when the system the system is in a satisfactory state is important.

Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record. Debian's track record is particularly impressive when one realizes that the Debian Potato consists of over 55 million lines of code (compared to RedHat's 30,000,000 lines of code).

The Road To Secure Software

Exploitable security vulnerabilities in a software application are typically evidence of bugs in the design or implementation of the application. Thus the process of writing secure software is an extension of the process behind writing robust, high quality software. Over the years a number of methodolgies have been developed to tackle the problem of producing high quality software in a repeatable manner within time and budgetary constraints. The most successful methodologies have typically involved using the following software quality assurance, validation and verification techniques; formal methods, code audits, design reviews, extensive testing and codified best practices.

1. Formal Methods: One can use formal proofs based on mathematical methods and rigor to verify the correctness of software algorithms. Tools for specifying software using formal techniques exist such as VDM and Z. Z (pronounced 'zed') is a formal specification notation based on set theory and first order predicate logic. VDM stands for "The Vienna Development Method" which consists of a specification language called VDM-SL, rules for data and operation refinement which allow one to establish links between abstract requirements specifications and detailed design specifications down to the level of code, and a proof theory in which rigorous arguments can be conducted about the properties of specified systems and the correctness of design decisions.The previous descriptions were taken from the Z FAQ and the VDM FAQ respectively. A comparison of both specification languages is available in the paper, Understanding the differences between VDM and Z by I.J. Hayes et al.
   
   
2. Code Audits: Reviews of source code by developers other than the author of the code are good ways to catch errors that may have been overlooked by the original developer. Source code audits can vary from informal reviews with little structure to formal code inspections or walkthroughs. Informal reviews typically involve the developer sending the reviewers source code or descriptions of the software for feedback on any bugs or design issues. A walkthrough involves the detailed examination of the source code of the software in question by one or more reviewers. An inspection is a formal process where a detailed examination of the source code is directed by reviewers who act in certain roles. A code inspection is directed by a "moderator", the source code is read by a "reader" and issues are documented by a "scribe".
   
   
3. Testing: The purpose of testing is to find failures. Unfortunately, no known software testing method can discover all possible failures that may occur in a faulty application and metrics to establish such details have not been forthcoming. Thus a correlation between the quality of a software application and the amount of testing it has endured is practically non-existent.
   
   There are various categories of tests including unit, component, system, integration, regression, black-box, and white-box tests. There is some overlap in the aforementioned mentioned testing categories.
   
   Unit testing involves testing small pieces of functionality of the application such as methods, functions or subroutines. In unit testing it is usual for other components that the software unit interacts with to be replaced with stubs or dummy methods. Component tests are similar to unit tests with the exception that dummmy and stub methods are replaced with the actual working versions. Integration testing involves testing related components that communicate with each other while system tests involve testing the entire system after it has been built. System testing is necessary even if extensive unit or component testing has occured because it is possible for seperate subroutines to work individually but fail when invoked sequentialy due to side effects or some error in programmer logic. Regression testing involves the process of ensuring that modifications to a software module, component or system have not introduced errors into the software. A lack of sufficient regression testing is one of the reasons why certain software patches break components that worked prior to installation of the patch.
   
   Black-box testing also called functional testing or specification testing test the behavior of the component or system without requiring knowledge of the internal structure of the software. Black-box testing is typically used to test that software meets its functional requirements. White-box testing also called structural or clear-box testing involves tests that utilize knowledge of the internal structure of the software. White-box testing is useful in ensuring that certain statements in the program are excercised and errors discovered. The existence of code coverage tools aid in discovering what percentages of a system are being excercised by the tests.
   
   More information on testing can be found at the comp.software.testing FAQ .
   
   
4. Design Reviews: The architecture of a software application can be reviewed in a formal process called a design review. In design reviews the developers, domain experts and users examine that the design of the system meets the requirements and that it contains no significant flaws of omission or commission before implementation occurs.
   
   
5. Codified Best Practices: Some programming languages have libraries or language features that are prone to abuse and are thus prohibited in certain disciplined software projects. Functions like strcpy, gets, and scanf in C are examples of library functions that are poorly designed and allow malicious individuals to use buffer overflows or format string attacks to exploit the security vulnerabilities exposed by using these functions. A number of platforms explicitly disallow gets especially since alternatives exist. Programming guidelines for such as those written by Peter Galvin in a Unix Insider article on designing secure software are used by development teams to reduce the likelihood of security vulnerabilities in software applications.

Projects such as the OpenBSD project that utilize most of the aforementioned techniques in developing software typically have a low incidence of security vulnerabilities.

Issues Preventing Development of Secure Open Source Software

One of the assumptions that is typically made about Open Source software is that the availability of source code translates to "peer review" of the software application. However, the anecdotal experience of a number of Open Source developers including John Viega belies this assumption.

The term "peer review" implies an extensive review of the source code of an application by competent parties. Many Open Source projects do not get peer reviewed for a number of reasons including

• complexity of code in addition to a lack of documentation makes it difficult for casual users to understand the code enough to give a proper review
  
  
• developers making improvements to the application typically focus only on the parts of the application that will affect the feature to be added instead of the whole system.
  
  
• ignorance of developers to security concerns.
  
  
• complacency in the belief that since the source is available that it is being reviewed by others.
  
  

Also the lack of interest in unglamorous tasks like documentation and testing amongst Open Source contributors adversely affects quality of the software. However, all of these issues can and are solved in projects with a disciplined software development process, clearly defined roles for the contributers and a semi-structured leadership hierarchy.

Benefits of Open Source to Security-Conscious Users

Despite the fact that source licensing and source code availability are not indicators of the security of a software application, there is still a significant benefit of Open Source to some users concerned about security. Open Source allows experts to audit their software options before making a choice and also in some cases to make improvements without waiting for fixes from the vendor or source code maintainer.

One should note that there are constraints on the feasibility of users auditing the software based on the complexity and size of the code base. For instance, it is unlikely that a user who wants to make a choice of using Linux as a web server for a personal homepage will scrutinize the TCP/IP stack code.

References

1. Frankl, Phylis et al. Choosing a Testing Method to Deliver Reliability. Proceedings of the 19th International Conference on Software Engineering, pp. 68--78, ACM Press, May 1997. < http://citeseer.nj.nec.com/frankl97choosing.html >
   
   
2. Hamlet, Dick. Software Quality, Software Process, and Software Testing. 1994. < http://citeseer.nj.nec.com/hamlet94software.html >
   
   
3. Hayes, I.J., C.B. Jones and J.E. Nicholls. Understanding the differences between VDM and Z. Technical Report UMCS-93-8-1, University of Manchester, Computer Science Dept., 1993. < http://citeseer.nj.nec.com/hayes93understanding.ht ml >
   
   
4. Miller, Todd C. and Theo De Raadt. strlcpy and strlcat - consistent, safe, string copy and concatenation. Proceedings of the 1999 USENIX Annual Technical Conference, FREENIX Track, June 1999. < http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/ >
   
   
5. Viega, John. The Myth of Open Source Security. Earthweb.com. < http://www.earthweb.com/article/0,,10455_626641,00 .html >
   
   
6. Gonzalez-Barona, Jesus M. et al. Counting Potatoes: The Size of Debian 2.2. < http://people.debian.org/~jgb/debian-counting/coun ting-potatoes/ >
   
   
7. Wheeler, David A. More Than A Gigabuck: Estimating GNU/Linux's Size. < http://www.counterpane.com/crypto-gram-0003.html >
   
   

Acknowledgements

The following people helped in proofreading this article and/or offering suggestions about content: Jon Beckham, Graham Keith Coleman, Chris Bradfield, and David Dagon. © 2002 Dare Obasanjo

nihilist_1137 excerpts from this WinInformant article, which reads in part: "For at least the first 8 months of 2001, open-source poster child Linux was far less secure than Windows, according to the reputable NTBugTraq, which is hosted by SecurityFocus, the leading provider of security information about the Internet. ... A look at the previous 5 years--for which the data is more complete--also shows that each year, Win2K and Windows NT had far fewer security vulnerabilities than Linux, despite the fact that Windows is deployed on a far wider basis than any version of Linux." I wonder how many sysadmins (Windows or Linux) would agree with this conclusion. Update: 02/04 16:54 GMT by T : Looks like the WinInfo site has gone down since the story was submitted, so you may have to content yourself in the meantime with the Bugtraq numbers. Update: 02/04 19:30 GMT by T :Several readers have pointed out that the conclusions WinInformant makes based on the Bugtraq data are not those of SecurityFocus; the headline has been changed accordingly.

Stuart of Wapping writes "Even patches are not safe, especially if they come from a closed background (maybe) - An interesting article on why coding, is naturally insecure, from SecurityFocus."

mercut writes: "A friend of mine recently wrote a Guest Feature on SecurityFocus about Biological Network Security. It has some interesting implications and I thought the /. community could provide some good perspective into IDS communication and security."

A number of readers have collected stories concerning the change of focus by Bill Gates to security. Bruce Schneier and Adam Shostack have written a piece, while Crag Mundie of MSFT has also chimed in, along with some commentary from ZD folks. SecurityFocus has other words, as does InfoWarrior.

A number of readers have collected stories concerning the change of focus by Bill Gates to security. Bruce Schneier and Adam Shostack have written a piece, while Crag Mundie of MSFT has also chimed in, along with some commentary from ZD folks. SecurityFocus has other words, as does InfoWarrior.

Billy writes "Unless you've been living in a cave, you've seen Oracle's Unbreakable campaign (Can't break it. Can't break in.), which was kicked-off by Larry Ellison personally at Comdex last November. Now U.K. security researcher David Litchfield says you can break in, thanks to at least seven different security holes in Oracle 9i, according to this SecurityFocus story. Oracle's top security manager is quoted as saying that "unbreakable" doesn't really mean unbreakable, or something."

BillTheKatt writes: "The formerly (as in a couple of weeks) "unbreakable" Oracle 9i has been found to be vulnerable to a Denial Of Service bug. ... Thanks [H]ardOCP for the link to the Article At SiliconValley.com. For more information see the official notice on SecurityFocus. More proof that Microsoft does not hold a monopoly on bugs. And of course a black eye to Mr. Larry 'Big Mouth' Ellison. I'm still waiting for my network computer, Larry."

A reader wrote to us about a summary article regarding IDS ^? . This is an interesting article in so far as it attempts to prognosticate what the future will be for detection, and that draws in some interesting work on security modelling. T: Readers may also want to see this vnunet article on IDS products -- guess what comes out on top?

Ademar writes: "A remote exploitable vulnerability was found in wu_ftp, which is distributed in all major distros. The CERT has a (private) list to coordinate this kind of disclosure so vendors can release updates together, but RH broke the schedule and released their advisory first. You can see the full advisory from securityfocus in bugtraq, but here is a quote: "This vulnerability was initially scheduled for public release on December 3, 2001. Red Hat pre-emptively released an advisory on November 27, 2001. As a result, other vendors may not yet have fixes available."" CNET has a story about this too.

Ademar writes: "A remote exploitable vulnerability was found in wu_ftp, which is distributed in all major distros. The CERT has a (private) list to coordinate this kind of disclosure so vendors can release updates together, but RH broke the schedule and released their advisory first. You can see the full advisory from securityfocus in bugtraq, but here is a quote: "This vulnerability was initially scheduled for public release on December 3, 2001. Red Hat pre-emptively released an advisory on November 27, 2001. As a result, other vendors may not yet have fixes available."" CNET has a story about this too.

zavyman writes: "I just noticed at Cryptome that the flaws in HDCP posted to Slashdot earlier this year, which one person refused to disclose due to possible threats from the DMCA, have been made public by different authors. Scott Crosby of Carnegie Mellon University, Ian Goldberg of Zero Knowledge Systems, and Robert Johnson, Dawn Song, and David Wagner of UC Berkeley have published a formal cryptanalysis of the High-bandwidth Digital Content Protection System that proves its fatal flaws. Interesting reading for those with some background with cryptanalysis."

umm qasr writes: "Security Focus has an interesting article on blocks of internet space that are hidden from most users, it is based on a survey by Arbor Networks. The most common 'invisible sites' being .mil, which seems is unintentional. The survey suggests others, which seem more sinister...using unused netblock addresses to send spam. It's a bit short on the details but interesting none the less."

umm qasr writes: "Security Focus has an interesting article on blocks of internet space that are hidden from most users, it is based on a survey by Arbor Networks. The most common 'invisible sites' being .mil, which seems is unintentional. The survey suggests others, which seem more sinister...using unused netblock addresses to send spam. It's a bit short on the details but interesting none the less."

titurel writes: "This article on SecurityFocus takes up some interesting thoughts about how Alan Cox's choice not to unveil securitychanges in the kernel changelog could affect other developers." And Jon Lasser is no security dummy -- Along with Jay Beale, he's one of the guys behind Bastille Linux, and the author of the excellent Think Unix.

titurel writes: "This article on SecurityFocus takes up some interesting thoughts about how Alan Cox's choice not to unveil securitychanges in the kernel changelog could affect other developers." And Jon Lasser is no security dummy -- Along with Jay Beale, he's one of the guys behind Bastille Linux, and the author of the excellent Think Unix.

Your day wouldn't be complete without Microsoft news. Ralph Nader has written an open letter to Judge Kollar-Kotelly. Seems he has a few bones to pick with the settlement. MSNBC is running a WSJ article detailing how Microsoft beat down the DOJ in settlement negotiations. Even Israel knows Microsoft is a monopoly. Microsoft reveals its keep-them-in-the-dark plan for Microsoft security vulnerabilities. Amazingly, some security firms seem to be willing to go along with it. I guess they figure setting up a sort of cartel for security flaws is in their best financial interest. SANS is keeping their list of top security vulnerabilities up to date with the latest IIS exploits. And finally, MS wishes their new disclosure rules were used for yet another huge hole in Windows. Microsoft says it's "irresponsible" to expect them to get a patch out for a critical flaw within "a few days". As usual, switch off active scripting, even though that will make essentially every webpage that's designed for IE not work.

Armin Herbert writes: "According to this mail from Rafal Wojtczuk and a german article on Heise Online, there's a new severe bug in all Linux Kernels, from 2.2.0 up to 2.4.10, which allows users to become root on your system. Kernel 2.4.12 fixes this problem, and RedHat, Caldera and other distributors already supply patches for their Kernels. See Bugtraq for more information." Important notes for anyone running a multi-user system. Update: 10/19 16:12 GMT by J : If I'm reading Nergal's writeup correctly, 2.4.10 is still vulnerable to the local DoS, but not to the local root exploit. Separate issues. And as pheared points out, there is one unverified report of a custom 2.4.12 being vulnerable as well; please try the exploit on your system and let us know what you find. This is a big one, you can expect the kiddies have already added this to their rootkits. Update your systems now!

Rogue_F writes: "The long running security mailing list Bugtraq is getting a new moderator. Elias Levy (the real name of the familiar Aleph1) has decided to move on to other things. For nearly six years he has been moderating bugtraq with a high degree of success. No one doubts the usefulness of bugtraq, but many people probably dont appreciate what a 'clean' list it is. No spam, no flames, no relgious security wars, instead you get good wholesome security information. Aleph1 details in this message that he is moving on to other security projects and that David Ahmad is taking over moderation duties. Bugtraq continues to churn out quality security information on a daily basis, and it looks like it will continue to do so for quite some time to come." List moderators and maintainers seem universally denied their due credit -- people like Zack Brown (of Kernel Traffic fame) end up getting noticed only when --infrequently -- they go on vacation.

Rogue_F writes: "The long running security mailing list Bugtraq is getting a new moderator. Elias Levy (the real name of the familiar Aleph1) has decided to move on to other things. For nearly six years he has been moderating bugtraq with a high degree of success. No one doubts the usefulness of bugtraq, but many people probably dont appreciate what a 'clean' list it is. No spam, no flames, no relgious security wars, instead you get good wholesome security information. Aleph1 details in this message that he is moving on to other security projects and that David Ahmad is taking over moderation duties. Bugtraq continues to churn out quality security information on a daily basis, and it looks like it will continue to do so for quite some time to come." List moderators and maintainers seem universally denied their due credit -- people like Zack Brown (of Kernel Traffic fame) end up getting noticed only when --infrequently -- they go on vacation.

Carlos writes "Most computer crimes are considered acts of terrorism under John Ashcroft's proposed 'Anti-Terrorism Act,' according to this story on SecurityFocus. The Act would abolish the statute of limitations for computer crime, retroactively, force convicted hackers to give the government DNA samples for a special federal database, and increase the maximum sentence for computer intrusion to life in prison. Harboring or providing advice to a hacker would be terrorism as well. This is on top of the expanded surveillance powers already reported on. The bill could be passed as early as this week. I feel safer already."

Carlos writes "Most computer crimes are considered acts of terrorism under John Ashcroft's proposed 'Anti-Terrorism Act,' according to this story on SecurityFocus. The Act would abolish the statute of limitations for computer crime, retroactively, force convicted hackers to give the government DNA samples for a special federal database, and increase the maximum sentence for computer intrusion to life in prison. Harboring or providing advice to a hacker would be terrorism as well. This is on top of the expanded surveillance powers already reported on. The bill could be passed as early as this week. I feel safer already."

Lifter writes "A hacker named Adrian Lamo had access for three weeks to the web-based content control system for Yahoo!'s news section, according to a story at SecurityFocus. He tinkered with a couple of stories without anyone noticing, then edited an August Reuters story about Dmitry Sklyarov, so that it said that Dmitry's program raised "the haunting specter of inner-city minorities with unrestricted access to literature, and through literature, hope." He also added a quote by John Ashcroft,"They shall not overcome. Whoever told them that the truth shall set them free was obviously and grossly unfamiliar with federal law." Funny stuff in itself, but the SecurityFocus story explores the harm that could come from a trusted news site being easily hacked in these times."

Lifter writes "A hacker named Adrian Lamo had access for three weeks to the web-based content control system for Yahoo!'s news section, according to a story at SecurityFocus. He tinkered with a couple of stories without anyone noticing, then edited an August Reuters story about Dmitry Sklyarov, so that it said that Dmitry's program raised "the haunting specter of inner-city minorities with unrestricted access to literature, and through literature, hope." He also added a quote by John Ashcroft,"They shall not overcome. Whoever told them that the truth shall set them free was obviously and grossly unfamiliar with federal law." Funny stuff in itself, but the SecurityFocus story explores the harm that could come from a trusted news site being easily hacked in these times."

sasha328 writes "I found reference to this email on the LWN.NET site which was sent to the SecurityFocus mailing list. It asks a very valid question about how much you can disclose before malicious virii can be possible."