Re: [cobalt-security] Security Hardening Update 2.0.1 MAJOR FLAW!!!!!! ACTION REQUIRED!

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Eugene,

> Well, theoretically it is not impossible to save all replaced files in a
> safe place (== directory unique to this package), together with
> checksums of _replacing_ files.  Then the uninstaller could restore the
> files from backup, and do it only if they where not replaced by yet
                                                       ~~~~~~~~~~~~~~~~~~~~~
> another package in the meantime.

Exactly that's the point, Eugene. The thing is as follows:

The underlying OS on the Cobalt's is an RPM based Linux distribution. You can 
install and uninstall RPM packages at leizure - as often as you want. 

Ok, lets say we install the package Neomail-1.20-1.PKG which contains the RPM 
file neomail-1.2.5-1.noarch.rpm. When you install a PKG file (which contains 
one or more RPMs), then the RPMs are deleted after installation as they are 
no longer needed. That's a standard procedure of the PKG installation process 
designed by Cobalt.

With "rpm -ql neomail-1.2.5-1" you can query which files it brought aboard and 
where they are on the system. However, you cannot (reasonably) recreate the 
neomail-1.2.5-1.noarch.rpm and tuck it away as backup. The PKG file with 
which we installed it is gone and also the RPM which it contained has been 
erased automatically after or during the installation.

Lets spin this thought further: 

Now we install a newer PKG file of the same software: Neomail-1.20-2.PKG

It contains neomail-1.2.5-2.noarch.rpm and upon installation it replaces all 
files which the older neomail-1.2.5-1.noarch.rpm brought aboard.

Lets assume we don't like the new Neomail and want to go back to the old one. 
But even if we backed up all files of the old neomail-1.2.5-1.noarch.rpm and 
copy 'em back to where they belong: The RPM database still will claim that 
the newer RPM neomail-1.2.5-1.noarch.rpm is installed.

So although the original functionality could be restored by a smart and 
automated uninstaller, it wouldn't restore the server to the same exact 
condition, as the RPM database still claims otherwise. Unfortunately the RPM 
database is usually the authority which an installer queries to find out if 
it's OK to go ahead with an installation or not. 

For unimportant stuff like Nemail this is of no consequence, but for critical 
stuff like Apache, Sendmail, Qpopper, IMAP and so on it's a different matter.

The resolution would be:

If an installer replaced an existing (older) RPM, then a proper and complete 
uninstall has to reinstall the old RPM which previously was aboard. But where 
do you get it from when RPMs are always deleted after PKG installation? :o)

It could be remotely downloaded from the internet and then installed. 
ftp.cobalt.com contains the RPMs which a stock and unpatched RaQ usually has 
aboard. That would be one possibility in case were third party software 
installs RPM which replace system services. Or an uninstaller could download 
and (partially or completly) re-install the official Sun Cobalt PKG which 
contains the replaced RPM file in such a case. 

This adds a full new layer of complexity not only in the installer and 
uninstaller of a PKG, but also requires a working internet connection and 
working DNS on the server during the uninstall. Furthermore it requires that 
the URLs of the download sites don't change between the PKG creation and the 
date and time of the attempted uninstall. Just remember that 
ftp.cobaltnet.com went out of business without prior notice. 

Alternatively the third party PKG contains not only the new RPM file of the 
service, but also the old RPM of the services which it replaces and tucks 
that one safely away until the time it's needed for an uninstall. Well, just 
pray that the admin doesn't find and delete it manually, or the uninstall 
would fail, too.

Sure, just from a technically point of view its possible to come up with a 
solution which will cope with all those difficulties. 

But is it worth the extra troubles? How many users would really want or need 
to uninstall the software? 

In the end all these measures still won't guarantee that it all works right 
out of the box on all RaQs and under all circumstances. 

For instance: I know of a couple of stock RaQ4's with all prior patches 
installed where the PKG installation of SHP failed utterly for unknown 
reasons. The installation script of SHP is very straightforward and without 
much room for things to go wrong, but even having an unmodified RaQ with all 
prior patches won't guarantee 100% success for the install of that PKG. Or 
others that we know of. OS Update 2.0 or Apache Update 2.0.1 anyone? ;o)

> I am not telling this is a "must do", or even a "good idea" for the
> particular case, but at least it is possible.

Yeah, I see your point and say that when a clean uninstall is feasible and 
achieveable with reasonable extra efforts, then it sure should be implemented 
into the PKG. That's what most PKG developers try to do (including me), but 
if it's too complex or not worth the effort, then more often than not the 
uninstaller will be left out.

FWIW: Windows 2000 Service Pack 3 can't be uninstalled either. ;o)

-- 

With best regards,

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer