[2388] in bugtraq
Re: a point is being missed
daemon@ATHENA.MIT.EDU (Mike Shaver)
Fri Nov 10 14:36:46 1995
Date: Thu, 9 Nov 1995 23:02:38 -0500
Reply-To: Me <shaver@neon.ingenia.com>
From: Mike Shaver <mshaver@schoolnet.carleton.ca>
X-To: BUGTRAQ@CRIMELAB.COM
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@crimelab.com>
In-Reply-To: <Pine.SUN.3.91.951109084345.13012J-100000@itd> from "Bruce
Montrose" at Nov 9, 95 09:14:23 am
Bruce Montrose mumbled something vague about:
> On Wed, 8 Nov 1995, Scott Barman wrote:
> > Anonymous FTP: So you can put a copy of "ls" in the chroot area without
> > having to copy, and expose, the libraries. So you can include a program
> > that will allow the user to search your archive (see the "quote site
> > index" command for gatekeeper.dec.com) again, without exposing your
> > libraries to attack. Another example later.
How does exposing the libraries to attack create a bigger (or even
different) problem than exposing static binaries?
> These have been mentioned before but sometimes people need to be told
> things many times before they listen. I would like to add my own reason
> to the list: I'm against all forms of censorship and I think that it is
> inappropriate for Sun to limit our options so that we are forced to do
> what they feel we should be doing.
Well, they don't offer Solaris for the Alpha, either, so they're
limiting our options again.
For them to support everything under the sun would cause a significant
increase in the cost of developing their software. Rest assured that
this would be passed on to us, the consumers. =) Also, it increases
the complexity of the system, which increases the likelihood and
number of bugs.
> > Dynamic linking adds exposure to another aspect of your system. Leave
> > the libraries open for attack through a program that has to run setuid
> > or setgid and they will be attacked. Maybe not now, but they will be.
Just like static binaries, right?
If you can write to a library and change it, why not write to the binary?
> > > First of all: all authentication programs are extensible through dynamic
> > > linking, all localized programs are extensible through dynamic linking,
> > > etc. Dynamic linking is required.
> >
> > "Extensible through dynamic linking"? How so? Please explain? What
> > are we going to do, leave it dynamic so login user can add their own
> > options on the fly? Sounds real secure to me!
No, they're going to build everything staticly so that when a problem
like the syslog() bug is discovered everyone has to recompile the
entire system.
I think centralized management of security-critical system elements is
a smart thing...
> Hello. Anybody home here? I'm surprised that Sun would try this line on
> the group of individuals that recieve this mailing list. This is something
> that I expect to see (and do see often) on television commercials where
> sadly most of the American public assimilate the information directly as
> being factual without question.
I don't see what you're talking about, but I've never been a big
conspiracy fan.
> > > You're being unfair. Sun is pretty open about security. We publish
> > > security patches for problems not widely know.
> >
> > Gee... then why hasn't Sun done something about sendmail so we can get
> > off the sendmail advisory of the month club??
Like what?
2 days after the release of sendmail 8.7, there was an alert about a
hole in it. What can Sun do about that? Distribute smail?
> True, but lets not be drawn into another debate. Keep focused on the
> issue of statically bound censorship. A common tactic for a debater with
> a weak argument is to introduce other issues to drift away from or
> confuse the real issues of the debate.
Oh, the irony...
("Staticly bound censorship"... has someone contacted Amnesty
International?)
> > > Besides, I don't share you opinion that linking login statically contributes
> > > to the security of Solaris 2.x.
> >
> > It limits the attackable objects to one item, which can be secured far
> > better than the program plus EIGHT libraries currently being used by the
> > Solaris 2.4 login program. What's easier to tie down, nine items or one?
I think the use of dynamic linking reduces the amount of effort
involved in monitoring/maintaining/upgrading/fixing the large number
of binaries on a system...
> > > In Solaris 2.6, what would you rather have: a statically linked login or
> > > a totally dynamically configurable login?
> >
> > Sun, or anyone else, can make login configurable with a statically
> > linked program. Having something configurable is NOT does not mean
> > having to be dynamically linked!
> >
> > Besides, what kind of configuration options do you need? There are
> > parameters in /etc/default/login that pretty much covers everything
> > (with some exceptions I think would be worth looking into). Do you need
> > a dynamic library to process that file? I don't think so!
Dynamic linking allows them to fix a bug once, properly, for all
binaries on the system.
Also, a lot more can be changed via libraries than via a configuration
file. (I think this is actually part of your argument, if you think
about it...) You're interpreting "configuration" in a much more
narrow context than Casper intended, I think.
Mike
