Re: [Phplib-users] phplib 6.1, php3 and php4
Brought to you by:
nhruby,
richardarcher
From: Michael C. <mdc...@mi...> - 2002-01-24 01:26:55
|
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. |Message-ID: <3B5...@na...> |Date: Sat, 14 Jul 2001 10:26:36 +0200 |From: giancarlo pinerolo <gia...@na...> |Organization: navigare.net |X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12-20smp i686) |MIME-Version: 1.0 |To: "php...@li..." |<php...@li...>, | "php...@li..." <php...@li...> |Subject: security: READ THIS! |Content-Type: text/plain; charset=us-ascii |Content-Transfer-Encoding: 7bit | |Gosh |with regards to this paper, named PHP Security Paper (a study in scarlet)... | |http://www.securereality.com.au/studyinscarlet.txt | |I always thought _PHPLIB was a defined constant, now I realize it is an array |try this script please, which can override the $_PHPLIB[libdir] value. | |in the third input field, which overrides _PHPLIB[libdir], type '/tmp/', |and it will include a file named 'test' there > > Package management is great. But PHP changes too quickly, and the > > upgrades are too important to miss, for package management to be an > > option. Breath deep, download the sources, and do a build. And get > > used to it. > > The bottom line is, 'if it works, don't fix it'. Unless there are known, > documented exploits with a given piece, or known bugs that make it really > problematic, the only difference between old and new is more features. If I 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 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. > 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. > > The reason that we're not answering that is because your version of > > phplib is so incredibly old that we have no idea what all will break. > > Incredibly old? The file dates indicate that it was installed in Nov of > 1998? That's a little over 3 years ago, really not long enough, I would > hope, for everyone to forget about it, but long enough that there should be > some solid evidence w. regard to problems in a php version upgrade. > Granted, with the growth of php and phplib, I expect that _most_ people on > this list weren't using phplib in Nov. of 1998. Oh well... > > > I cannot fathom that someone would update software so rarely. > > 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. > > 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. Also, if you're running 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. There are plenty of other problems throughout the last couple of years, unless you're keeping up with them your box is vulnerable. > > 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? 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. You've received a lot of excellent suggestions from this group. I would recommend that you consider it all. Michael -- Michael Darrin Chaney mdc...@mi... http://www.michaelchaney.com/ |