Evaluating A Selection of Tools for Extraction of Forensic Data: Disk ...

Apache web server and Microsoft Internet Information Services (IIS) as examples.
Reichenkron (2006) presented evidence that the Apache web Server has more
vulnerabilities than Microsoft IIS. Payne (2002) presented another argument that OSS
is easily subjected to malicious code planted in the software. Most of OSS projects use
Concurrent Versioning System (CVS) to keep track of project progress, publish new
versions of the software and collaborate with multiple developers. Projects like the
Apache web server will only publish patches or fixes to the public from trusted
developers or submissions after careful examination and extensive testing.
Boulanger (2005) presented another argument claiming that hiding the source
code does not provide additional security. A common way of looking for
vulnerabilities is to send or input unexpected commands or codes to test the validation
mechanism of the software. Knowledge of the source code is not required. If the
software does not respond with a correct exception, this might indicate the existence of
vulnerability in the system. For example, an online e-commerce website usually has
customer login and password protection. If the web server did not implement proper
input validation mechanism, the attacker may launch an attack like Structured Query
Language (SQL) injection to exploit vulnerability to query sensitive and valuable
information from the back-end database. Grossman (2007) reported that SQL Injection
attack has been classified as one of the top ten website vulnerabilities.
Vulnerability can be discovered much faster in OSS than in Proprietary
software. Raymond (2002) postulates the bug discovering in OSS as “Given enough
eyeballs, all bugs are shallow”. In matter of days or even minutes, software bugs are to
be reported once software is released or updated. For proprietary software, it can only
wait for the vendor to release patch to fix the problem. In some cases, vendor may not
even release a patch for a small problem because the problem may require huge effort
to fix and it is not cost efficient. However, OSS may have a few options. If the vendor
does not release patch for the problem, it is not unusual that some developers will
program their own fix and release their products to the public. In some rare cases, no
other developers offer any fix to a particular problem. Users still have options to
develop their own patch to fix the problem but for proprietary software these options
simply do not exist.
24