Re: [Phplib-users] phplib 6.1, php3 and php4

[Lindsay H. <fm...@fm...>]

Thus spake Michael Chaney on Wed, Jan 23, 2002 at 07:30:11PM CST
> On Wed, Jan 23, 2002 at 02:27:39PM -0600, Lindsay Haisley wrote:
> > I appreciate notice that there's some kind of security problem with phplib
> > 6.1, but until I get something specific w. regard to exactly what this is, I
> > really can't consider it more than a rumor.  The software isn't broken.  It
> > works fine.  Everyone is happy.  I'd like to upgrade to take advantage of
> > new features in php4, and I'd really rather hold off on upgrading phplib
> > until v8 comes out which, I understand, will take advantage of native php4
> > session management.
>  
> |http://www.securereality.com.au/studyinscarlet.txt

This is an excellent document.  Thank you.  I browsed it, and bookmarked it
for further study.  Some of these security issues I've already dealt with,
and others are non-applicable since I have no users doing PHP programming on
the system.  Others certainly merit my further study.  There is no mention,
however, of any vulnerabilities implicit in phplib 6.1 which is the
reference you quote.

> Please see the php.net web site for a full list of vulnerabilities.
> Note also that session management is flakey in 4.0.6, the broken version
> that you wish to upgrade to.

I believe you misunderstood me.  I have no wish to upgrade to a specific
version of php4, and I'm aware that there are problems with early versions
of php4, which is one reason I've held off on upgrading.  Debian stable
offers this version, I believe, as a stock package and having been reminded
by you and other of these problems I'll consider other options.
  
> > I had hoped to get more technical specifics from people on this list, but
> > all I've received is grandfatherly advice, which really hasn't told me
> > anything I don't already know.
>  
> We're giving you "grandfatherly advice" because you need it.  Sorry to
> sound like I'm looking down my nose at you; I'm not.  But you're making
> some bad decisions which could negatively impact your customers.

Bullshit.  The article you cited above is the first piece of solid 3rd party
information I've received from anyone on this list, and I would be totally
remiss in my responsibilities to my business if I made decisions based on
"you ought to do this or that" from people about whose backgrounds,
experience and credentials I know nothing.  Your claim that I'm making "bad
decisions" bears no weight until you back it up with something more solid
than rumors.  If you know of specific vulnerabilities and problems, cite
references to them.

> > I have a replacement server in the planning stage, and it'll be set up with
> > php4 (a recent version) and a more recent version of phplib, but unless and
> > until I get more information on exactly what breaks in phplib 6.1 between
> > php3 and php4 I don't plan to migrate stuff on the existing server.
>  
> Not a bad idea.  Note, folks: we're getting through.

Actually, to poke a bit of a needle in your ego, this move has been in the
planning stages since before I wrote this list, and as usual with such
moves, it offers me an path to a smooth service upgrade without disrupting
anyone's service.

> > If it works, don't fix it.  migration from phplib 6.1 to v7.x involves
> > code rewrites for subclasses so that they can be properly serialized. Other
> > than a greatly expanded feature set, I have seen no reason to upgrade and
> > have to do all this work.
>  
> What we're trying to explain to you, and you'll have none of it, is that
> sometimes software looks like it's working, but in fact there are
> potential problems and real problems.  Exploitability is a real problem.

Oh!  I get it.  If it looks like a duck, walks like a duck and quacks like a
duck, it may, indeed, be a chicken ;-)  And I don't believe you speak for
anyone on the list except yourself, since others on this list have written
notes which either passed on my original question or indeed actually
suggested that I stay with older versions of the software.

I'm aware of a number of exploits for PHP, have dealt with a number of these
issues, and will review the article you referenced for further information. 

> > > I suppose that you're still running an
> > > exploitable 2.2 kernel, too.
> >
> > Actually, yes.  Exploits in the 2.2 kernels involve the ability to install
> > rogue modules from a shell.  There are no shell accounts on the server,
> > other than administrative accounts.  I know of no exploits implicating the
> > Linux 2.2 kernel involving attack from external sources, except possibly
> > from potentiail DoS attacks.  Frankly, I don't believe there are any. The
> > system is secure and has never been compromised.
>  
> There are also remote exploits with tcp/ip in some versions, please see
> your favorite security-oriented web site for details.  Sorry, you need
> to learn how to find this stuff out yourself.

Oh, I didn't realize that I didn't know how to research security issues. 
Thank you for enlightening me.  There's a setcap(2) vulnerability in 2.2.16,
IP masq (which I don't use) issues w. 2.2.20, a ptrace problem in 2.2.19
affecting only local users, and I really can't find much else.  There were
TCP/IP issues in the 2.0 series, but not in 2.2 as far as I know.  I'm sure
you're too busy with your important tasks to do more on this, but frankly, I
get the distinct feeling that you're blowing smoke.

> telnetd, and you didn't update it since last July, then it is fully
> exploitable (remote root shell) without needing access to an account on
> the box.

Negatory.  Telnetd is neither part of the kernel, nor for security reasons
related to those you cite, is telnetd running on any server here, nor are
port 23 requests even passed through my firewall.  Nor am I running
sendmail, wu-ftpd, rlogind nor a vulnerable version of ssh.  Thank you for
caring.

> There are plenty of other problems throughout the last couple
> of years, unless you're keeping up with them your box is vulnerable.

I keep up with them.  The problem with phplib which you cited, however,
appears to be nothing more than a rumor.  I'll honestly change my mind on
this if I can see something more solid.
  
> > > I would highly recommend that you get in the habit of upgrading PHP and
> > > Apache when upgrades are available, and update phplib when upgrades are
> > > available.  You do your customers a great disservice by not doing this.
> >
> > A disservice?  How?  No one complains?  No accounts have been compromised?
> > I really have a very high retention rate for customers, and almost all my
> > new business comes from referrals from satisficed existing customers.
>  
> Me too, so what?  You've already said your customers know nothing about
> what you're doing.
>  
> > Michael, thank you for your recommendations.  I will take your obvious
> > wisdom and many years of experience as a system administrator into account
> > when I consider your advice in planning future upgrades here.
>  
> Since you think you're too smart to listen to me, why not listen to
> everybody on here who's saying the exact same thing?

Actually, you're really the only one who has said most of this.

> I've been doing
> Unix administration professionally for well over 10 years now, and
> dynamic web content for 8 years (well, in two weeks, groups.google.com
> for more information), I've picked up a thing or two in that time.  You'd
> be wise to get off the know-it-all kick and listen.

Michael, I respect solid information, and I respect the advice of people
that can provide me with solid information and sound references.  What
you're saying is very weak on citations and references, and smacks seriously
of bravado and bs.  Sorry to be frank about this, but this is how you come
across.  If you've been doing system administration for 10 years and web
content programming for 8, then you should be able to correctly cite at
least a _general_ reference to a supposed security problem in phplib 6.1,
which was state of the art 3 years ago.  Maybe you spent most of your time
as a Windows NT administrator and programmer ;-)  Said security problem
doesn't show up in CERT's database, nor in any of the other security
references I have.  

Insofar as phplib partakes of underlying security problems with PHP then
yes, there are issues, and they have to be managed.  Security isn't an
absolute fix, it's a risk-management problem.  As an experienced system
administrator I'm sure you're aware of this.  I've managed it quite well so
far.  
 
> You've received a lot of excellent suggestions from this group.  I would
> recommend that you consider it all.

Yes, and none of it answered my original question, and some of it is in
direct contradiction to things you've said.  You're the only one who's
saying "exactly the same thing" - over and over....  :-(

I've gathered, or rather had my memory refreshed about some general PHP
issues, which I appreciate, and learned a few things here which were new,
none of them relating to the project at hand, and with the exception of the
security reference above, none of them from your offerings, unfortunately.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |