===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/Attic/press.html,v
retrieving revision 1.423
retrieving revision 1.424
diff -u -r1.423 -r1.424
--- www/Attic/press.html	2004/11/30 18:12:57	1.423
+++ www/Attic/press.html	2004/12/07 22:04:22	1.424
@@ -16,6 +16,53 @@
 <h2><font color="#e00000">Media Coverage</font></h2>
 <hr>
 
+<h2>December, 2004</h2>
+<ul>
+
+<li><font color="#009000"><strong>
+<a href="http://www.securityfocus.com/columnists/281">
+Closed Source Hardware</a>
+Security Focus, December 1, 2004</strong></font><br>
+Symantec Threat Analyst Jason Miller analyzes the potential security threats
+when hardware vendors won't provide device documentation and
+instead provide "binary only" driver code for inclusion in open source
+operating systems.
+Miller is an open-source fan who says he uses a variety of systems, including
+OpenBSD on his firewall.
+Of the recent trend to closed-source binary drivers for open-source
+systems, he writes:
+<blockquote>
+The closed-source component required to support this hardware is
+completely independent of the associated operating system, and as
+such, is also independent of the engineering team, security team,
+auditing process, and quality control procedures normally related
+to the operating system...
+<br/>
+What's possibly even more disturbing is that we're talking about
+a chunk of code in the operating system, running with the highest
+possible level of privilege (the kernel), which is supplied by a
+third-party vendor. This code could do anything once loaded, including
+leaking active WEP keys, gathering usage statistics, sniffing and
+disclosing traffic, and it could even introduce a subtle backdoor
+into the operating system itself (much the same as any device driver
+in a closed source operating system).
+<br/>
+[A]lthough some of these scenarios are a
+little far-fetched, the possibility for them to exist is there...
+Ultimately it becomes an issue of trust, which is a cornerstone of 
+good security: whom do you trust, and how much do you trust them?
+</blockquote>
+<p>And he comments that trust "seems to be a one-way street": vendors
+demand that you trust them, but they won't trust you to know how
+their hardware and software operates.
+This lack of trust is one reason why OpenBSD has recently completed
+reverse-engineering the 
+<a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ath&apropos=0&sektion=4">
+Atheros wireless chipset driver</a>
+that was originally provided as a binary insert.
+<p>
+</ul>
+
 <h2>November, 2004</h2>
 <ul>
 
@@ -4434,7 +4481,7 @@
 <hr>
 <a href="index.html"><img height=24 width=24 src=back.gif border=0 alt=OpenBSD></a>
 <a href="mailto:www@openbsd.org">www@openbsd.org</a>
-<br><small>$OpenBSD: press.html,v 1.423 2004/11/30 18:12:57 ian Exp $</small>
+<br><small>$OpenBSD: press.html,v 1.424 2004/12/07 22:04:22 ian Exp $</small>
 
 </body>
 </html>