[9081] in bugtraq
Re: Checking for most recent Solaris Security Patches
daemon@ATHENA.MIT.EDU (//Stany)
Fri Jan 15 14:30:10 1999
Date: Fri, 15 Jan 1999 08:43:32 -0500
Reply-To: //Stany <stany@PET.ML.ORG>
From: //Stany <stany@PET.ML.ORG>
X-To: Linux Mailing Lists <linux@AIIND.UPV.ES>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.LNX.3.96.990113212013.718A-100000@andercheran.aiind.upv.es>
On Wed, 13 Jan 1999, Linux Mailing Lists wrote:
> Doesn't sound very good to send the configuration of your machine over the
> internet by email. What if someone gets it and use that information to
> know the vulnerabilities of your server? Using your service he would know:
>
> * Which Software you have installed in your server
> * Which patches you have applied (and what's more interesting, which
> patches you *haven't* applied)
In my experience there is always a patch that have not been applied ;-)
I have not applied prtdiag patches on some of my machines, even though
they are listed as recommended. Why? prtdiag is useless on SS10 or SS20,
and only seems to apply to newer boxes.
However there is a reason why some patches are not made recommended and
shipped with the default jumbo cluster. I recall the embarrassing moment
of installing a stand-alone kernel patch and having the system panic on
boot-up, as a SS10 was not exactly an E10000 server for which the patch
was designed. patchdiag was claiming that I absolutely have to install it
to bring my systems up to date, though. This /is/ a part of the problem
- there are so many hardware configurations and so many different patches
that any automated service will have problems figuring out if you should
(or should not) patch something. What if I have SENA installed? What if
I have some bits of other uncommon hardware in the box as well? Will
patches work together OK?
Ultimately it seems to me that hardware in the box have to be consulted
too (and not just the software packages installed. I can recompile
and install the latest and greatest sendmail on my own, without
updating the pkg list, and then have it overwritten by the next
"Official Sun Sendmail Security Patch", which will look as a newer
package, but in fact be older software) before the patches are
installed, and I hope that the next version of patchdiag will be asking
for the output of prtconf before making a descission what patches should
or should not be installed on an given machine. After all, why do I need
to patch something that is not used by the system in a first place,
like PPP modem support, while new drivers for hardware which I /do/ have
do not get installed by default?
Guess the idea is that all the tools for keeping the system up to date are
great, but they are not a substitution to a clear head and reading of the
patch descriptions too. Automated, one size fits all updates just do not
cut it, unless you have 50 (or more) of identical machines, with identical
software on them all running the same OS revision. But how realistic is
this, and if it is, are you sure that your users (whom we all learn
to love) have not installed something on their own, and not running their
own services on unpriveledged ports?
> * The OS version, platform, etc...
Such things can be pretty closely guessed with other freely available
tools, like Fyodor's nmap (which will not be able to distinguish between
SunOS 5.6 and SunOS 5.7, but will tell you if the remote system is Solaris
2.5.x). There are still few good alternatives to well configured
firewall/proxy or bastion host as the entry point into your network.
> * Your server's name
> Mmmmmmm... Just the information someone would need to hack your system :)
It seems to that this is not that easy even with this info. Yes, I have
seen Solaris boxes that bleed services all over the local LAN, and for
which this is generally true. But from my experience any more or less
competent admin would close most of the gaping remote root holes just by
installing the lates jumbo patch right after the system's installation,
commenting a bunch of lines out in /etc/inetd.conf, and installing ssh, in
which case the information is only useful for local exploits (but in which
case you can run most of those tools by hand yourself) or for DoS. The
idea seems to be that the less ports are open, the better it is for the
system and for admin's peace of mind.
> What about making public the program you use, to run it locally?
>
> (showrev -p ; pkginfo -l)|yourniceprog
>
I haven't tried the above mentioned service for above mentioned reasons,
but from the information requested, this seems awfully like a perl
wrapper for Sun's own patchdiag script with the -p option and showrev and
pkginfo outputs fed to it in the proper way. If that is the case, there
might be different copyright problems with making this script accessible
to people without Sun support contract. However if that is the case,
server name means nothing at all to the script (as it should only use it
for cosmetic reasons) and anything can (and should) be plugged in in the
right place. I have to admit that the above paragraph is pure
speculation, though, and I would be interested to see how the original
poster have implemented this service.
> Greetings,
>
> Sergio
>
> PS: Who knows who is really receiving your information at
> pdiag@pogostick.net ;)
;-) You never know indeed. And one can only trust so far in this
world....
//Stany
--
+-----------------------------------------------------------------------------+
| Stanislav N. Vardomskiy - Procurator Odiosus Ex Infernis[TM] |
| This message is brought to you by letters jey, ow, el and tee. |
| Jolt! For all the sugar and twice the caffeine. |
+-----------------------------------------------------------------------------+
