Re: Sun Solaris login bug patches out

From: Jan-Philip Velders (jpv@jpv.xs4all.nl)
Date: 12/29/01


Date: Sat, 29 Dec 2001 22:35:49 +0100 (CET)
From: Jan-Philip Velders <jpv@jpv.xs4all.nl>
To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>


> Date: Thu, 27 Dec 2001 14:24:16 -0800
> From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
> Subject: Re: Sun Solaris login bug patches out
> [ ... ]

> A UNIX box with a high uptime is indicative of that box not being
> maintained with the latest security patches.

or in my book: a system which has been set up securely !

> IMO I think it's a shame that this attitude is part of the UNIX
> culture.

Why ? UNIX systems have been growing into a role, where downtime (no
matter what amount) is becoming more and more *unacceptable*.

Hell, I work in a scientific research centre, and people
moan-and-groan when the *extremely* *experimental* SGI O2000 system is
down because of various SGI IRIX bugs ! Known bugs which where enabled
on users' requests because the system otherwise wasn't "fast enough"
for them... Mind you, fast enough is in the percentile-range here...

Imagine how they behave when a production mail/news-server, or a
workgroup-server has problems ? (mostly introduced because people
where doing nasty network or NFS stuff !)

> A maintenance schedule that installs patches at regular intervals,
> including kernel patches which require a reboot, and including all
> security patches is a definite must.

Yes, for systems which are exposed to various risks. Take the SVR4
Login bug which affected a lot of 'telnet'-services.

At work we only had to install the patch onto one Solaris 8 machine.
Why ? Because that machine allows logins from 'outside' (read: isn't
firewalled for telnet), it has been given that task explicitly. The
Solaris 8 client machines only allow SSH logins...

Also, installing the latest-greatest patches whenever they come out,
is rather undoable for a lot of places... At work we have a cycle of 3
to 4 months, at which we perform scheduled updates of the OS on
servers. A more frequent cycle would only cause unnecessary downtime,
and a lot of hassle for the users. Plus it would introduce a lot of
variations between systems...
"What MU-level is server A at ?"
"I don't know ! server B is at MU3, but was patched last weekend..."

You have to take a lot of things into account:
* security
* stability
* work-load (how much overtime is allowed by management !?)
* homogenity between systems
etc.

> If I were cracker, I'd target UNIX systems with 3+ months of
> uptime because I'd have a better probability of finding
> exploitable bugs.

Hm... let's take a realworld example:
An SGI Indy (IRIX 6.2) which provides Radius and telnet-based SLIP
access through a Cisco 2501. Has been operational for over 5 years,
has only had one patch-round applied for the IRIX IGMP vulnerability.

That would make a lot of scriptkids happy, at first glance.

But when you take a better look:
this system has a couple of dedicated tasks (SLIP/dialin, Radius,
etc.), all other access methods have been disabled, telnet access is
only allowed for a specified set of dialin accounts and only from one
Cisco 2501. System administration requires SSH or direct console
access. No unnecessary services and/or software has been installed.

Uptime right now is 124 days, we had to re-arrange some console
cables, so to avoid damaging the RS-232 ports, we shut it down...

Even if it were unfiltered from the Internet, it's a rather secure
system, and doesn't warrant any updates/patches/whatever...

Our primary mail/news/dns-server on the other hand, well that's a
system which is exposed and is the first to receive patches... ;)

> Why a system has been rebooted is more important than how often.

:) Hence I like the SGI IRIX 'shutdown' command, which asks for a
reason why you like to reboot:
# /etc/shutdown -y -g0 -i6
**** Enter Reason for Shutdown ****
Please select one of the following choices by number:
1. Administrative
2. Hardware upgrade
3. Software upgrade
4. Fix/replace hardware
5. Install patch
6. Fix software problem

:)

> Regards,
> Cy Schubert

Kind Regards,
JP Velders