===================================================================
RCS file: /cvsrepo/anoncvs/cvs/www/Attic/press.html,v
retrieving revision 1.423
retrieving revision 1.424
diff -c -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,21 ****
--- 16,68 ----
  <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,4440 ****
  <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>
  
  </body>
  </html>
--- 4481,4487 ----
  <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.424 2004/12/07 22:04:22 ian Exp $</small>
  
  </body>
  </html>