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

["Zeffie" <cobaltlist@xxxxxxxx>]

> > 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
> The underlying OS on the Cobalt's is an RPM based Linux distribution. You
> 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
> file neomail-1.2.5-1.noarch.rpm. When you install a PKG file (which
> one or more RPMs), then the RPMs are deleted after installation as they
> no longer needed. That's a standard procedure of the PKG installation
> With "rpm -ql neomail-1.2.5-1" you can query which files it brought aboard
> where they are on the system. However, you cannot (reasonably) recreate
> 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.

Actually you could...  and in some cases it's good to backup your configs
depending on who and how the rpms where built.

> Lets spin this thought further
Oh my head!
> 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
> 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
> But even if we backed up all files of the old neomail-1.2.5-1.noarch.rpm
> 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.

that's because we don't do things like that.  We would just reinstall the
old rpm.  If for some reason we can't move forward.  which doesn't happen
often because of the ways we build things.  (me anyway)

> 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
> 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

there is no diffrence.  you should still manage all files on a system.  .

> 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?

well thats what we have ftp sites for. :)
Granted that Sun.Cobalt does not have a location where we can get current
rpms and srpms.
grrrrrr

ak
> It could be remotely downloaded from the internet and then installed.
> ftp.cobalt.com contains the RPMs which a stock and unpatched RaQ usually
> 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.

not really because there are scripts inside of rpms and like a program there
is an order to these things..

<snip>

> FWIW: Windows 2000 Service Pack 3 can't be uninstalled either. ;o)
> Michael Stauber
> Unix/Linux Support Engineer

Ok I'm starting to see the problem.  But I knew it the first time I saw your
work. :) This is not windows.
Things work much different here..  In the development of rpms we have the
ability to verify how things are building through simple testing before
installing on production machines and then we are installing the same exact
thing.  We don't do ./configure make make install all over.  There is rarely
a need at all to uninstall things...  Unlike MS we build things correctly
and maintain various versions.  Which sometimes can make it into
production... but only after development on devel boxes.

There are reasons for all this rpm fun.

Zeffie
http://www.zeffie.com/
"Windows 2000 Support Engineer" (not)