Re: /dev/openprom problems - Solaris 1 or Solaris 2

[matt () opcom ca (Matthew Harding)]

Dan Stromberg wrote:
> On Fri, 24 May 1996, Matthew Harding wrote:
>
> > Note that this is a registered bugid with Sun (1222940) but
> > it is marked closed with no patch. Why? Because Sun's
> > solution for SunOS 4.1.x is to remove permissions from
> > /dev/openprom for unprivileged users, without actually fixing
> > the problem. No comment on this approach to "security"...
>
> 1) 1.x is dead.  They'd be shooting themselves in the foot to fix this
> kind of problem in 1.x.

No kidding it's dead. But notice how the sendmail patches are
all backported to 4.1.x? Just because it's dead doesn't mean
they can't do backwards support. BTW, SunOS 4.1.3 and above
is still officially supported... customers have a right to
expect patches for supported OSs.


> 2) The problem is infinitesimal in 2.x.  (see #5, below)

I don't believe the ability to panic a system by reading the
/dev/openprom device is infitesmial. But that's a moot point.


> 3) If you chmod the file under 1.x, treat as #2, above.

Same comments apply. The hole is still there, even if you
chmod it out. Ever upgraded an OS and found out that file
permissions were all reset back to the originals from the
media...?


> 4) One might argue that they should issue a patch for 1.x,
> consisting of nothing more than a README that says "chmod
> 640 /dev/openprom".

There is actually a SunOS 4.1.x patch that does exactly this,
patch# 100103. From the description:

" File permissions on numerous files were set incorrectly in
the build tape of 4.1.x FCS. This script changes them back to
what they should be. "

However, it hasn't been updated since 1993.


> 5) It makes vastly more sense for sun (or or any other OS development
> team) to spend time on new features, instead of fixing "problems" where
> priviledged users "can" crash their own machines (/oh boy!  I get to
> crash a machine I'm responsible for!/).  Consider:
>
>         dd if=/dev/zero of=/dev/dsk/c0t3d0s1.
>
> This is a generally bad thing to do, but I sure don't want _any_ vendor to
> waste time disallowing dd'ing to certain partitions.  (If someone tries out
> that dd command, I'm not responsible for the results.)


You're missing the point. Of course there are commands you
can perform that will crash your system... how about my
favourite, rm -rf /. The point is that this is operating _AS
DESIGNED_. The ability to panic a system by merely reading
the openprom is an error in implementation, not design. And
should be fixed (in my opinion).


> It's helpful to fish around for bugs, no matter what their significance, but
> it is more helpful if one also maintains a sense of where these bugs
> fit into the overall picture, which is: setting up operating systems that
> allow users to get things done.  This should include minimizing
> boobytraps waiting for sysadmins, which result in downtime for users -
> but even that doesn't really apply in this case.


Agreed. And the point I was making is that all sunos 4.1.x
boxes (including 4.1.4) is a waiting time bomb... And the
fact that bug crosses all the way from 4.1.x up to and
including Solaris 2.5 bothers me... I'm glad you're not
worried about it.


> BTW, I just added a "chmod 640 /dev/openprom" to our SunOS 4.1.x
> autoinstall environment.  Any new 4.1.4 boxes we set up (very few), will
> have this fixed automatically.

As I said, there is a patch from Sun ostensibly to do just
this, but it wasn't updated with this or other "permission"
problems. But keep in mind that this is a flaw in design,
whether masked by permission changes or not. For people
running firewalls under SunOS 4.1.x (and there's a lot of
you!), keep this in mind.

I think we've beaten this to death... any other comments not
germane to this disclosure, please email me offline.

Cheers,
Matthew (matt () ott opcom ca)