Re: Upgrades and Security Requirements...

   (Removing the pcsystems list from this discussion, and adding
MAGNet, with the thread to date viewable at
<http://ls.berkeley.edu/mail/micronet/2004/> ...)

In the message "Re: [Micronet] Upgrades and Security
Requirements...", dated 2004-06-22, Tom Holub wrote:

>I agree that it's not likely that "network-accessible" security holes
>in the default install of OS 9 are going to show up, but what about
>people who have file sharing on, or are using web browsers and other
>applications which expose them to vulnerabilities? It's certainly
>possible through social engineering to get the user to run
>applications on their computer, so the fact that OS 9 has no ports
>open by default doesn't constitute protection.

   Yes, that's clearly accurate. Mac OS 9 is not fundamentally immune
from attack. Any operating system is potentially at risk via social
engineering-based attacks, as well as through vulnerabilities in
non-vendor-provided (aka third party) applications and custom-written
code.

   However, none of these arguments negate my earlier assertion that
Mac OS 9 (and possibly 8.x) are worth examining carefully as a
potential exception to the requirement of the campus minimum security
standards that only OSes for which vendors are still actively
providing patches will be allowed on the campus network.

   *If* that's truly the requirement, that is ... Although it's been
asserted elsewhere that ambiguities in the standards are deliberate
and even helpful :-), this is one area in which the standards are
especially broad: the standards' implementing guidelines concerning
software patches seem to imply that software for which security
vulnerabilities have been identified, but not patched, must not be
run on the campus network, rather than software for which patches
simply aren't available at all from the vendor:
<http://security.berkeley.edu:2002/MinStds/Software-Patch.html>

>I think it's very likely that the recent Apple security problem that
>received so much press, also affects OS 9.

   Any operating system that allows the handling of arbitrary
URI-style protocols to be assigned to various applications could
potentially introduce some vulnerabilities via this mechanism. A
number of OSes, including Mac OS X and Mac OS 9, do this. (Some Mac
OS-specific background on this issue is at
<http://www.codepoetry.net/archives/2004/05/25/getting_the_security_holes_straight.php>.)

   However, the specific vulnerabilities identified in Mac OS X
involved design flaws in several Apple-provided applications which
served as default handlers for various protocols, such as Finder,
DiskImageMounter, Help Viewer, and Terminal. To the best of my
knowledge, despite the many years during which millions of Mac OS 9
machines have been nodes on the 'net, and the harsh spotlight of
publicity surrounding these issues in recent months, no similar
vulnerabilities have been reported in any Apple-provided applications
in Mac OS 9.

>There's another "critical" hole in the QuickTime media player which
>is very likely to affect versions of QuickTime which run on OS 9.

   Not to my knowledge. The only critical holes I'm aware of were
buffer overrun and heap overflow issues, respectively, in QuickTime
Player and a QuickTime extension file. This vulnerability was
introduced with version 6.5, and resolved in 6.5.1. However,
QuickTime 6.5 runs only under Mac OS X; the last version of QuickTime
for Mac OS 9 was 6.0.3, and I'm not aware of any reported
vulnerabilities in the latter.

   For completeness, there *was* a critical vulnerability reported in
earlier (pre-6.5) versions of QuickTime Player, but only in QuickTime
for Windows, not for any version of the Mac OS. I haven't seen any
open QuickTime vulnerabilities reported that would affect Mac OS 9
users. If you spot one, let us know ...

Aron Roberts
Workstation Software Support Group

------------------------------------------------------------------------
The following was automatically added to this message by the list server:

For information about Micronet, including subscribing to
or unsubscribing from its mailing list and finding out
about upcoming meetings, please visit the Micronet Web site:
<http://micronet.berkeley.edu/>.
Received on Tue Jun 22 14:38:45 2004