Re: Sun Solaris login bug patches out

From: Cy Schubert - ITSD Open Systems Group (Cy.Schubert@uumail.gov.bc.ca)
Date: 12/31/01


From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>
To: Jan-Philip Velders <jpv@jpv.xs4all.nl>
Date: Mon, 31 Dec 2001 10:54:28 -0800

In message <Pine.LNX.4.05.10112292206020.5128-100000@jp-gp.vsi.nl>,
Jan-Philip
Velders writes:
>
> > 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 !

So a system that hasn't been rebooted to install kernel or libc
security patches is just as secure as one that does not have the
patches?

I'm excluding clustered systems from this arguemnt.

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

I can see your point. I managed an Alpha with 617 days of uptime and
an HP system with 597 days of uptime. In both cases the customer
specifically gave instructions that no patches were to be applied.
period. Both systems were full of vulnerabilities that I had
successfully tried myself.

Applications that require 24x7 availability should be installed on
clustered systems.

Management should be made aware of business decisions that fly in the
face of good security practice. It should be in writing, not
argumentatively but to document the decision. An audit that lists
qualifications and makes recommendations, with responses to the
qualifications and recommendations would probably be better.

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

It's been documented that historically 80% of exploits are perpetrated
by insiders, e.g. employees. Your firewall protects you from the 20%
of the attacks that come from the outside. On the inside you need to
make sure that your software is as resistant to attack as possible.

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

This is exactly what we do. Every 3-4 months patches go in. We
publish a schedule and have our customers approve it. The patches go
in and the systems are rebooted.

If a vulnerability is discovered, e.g. telnetd, login, those patches
are installed as non-disruptively as possible. If a published security
bug is in the kernel or libc, a reboot is unavoidable and we negotiate
the downtime with each affected customer.

BTW, we install our patches on /foobar, a duplicate copy of the system
disk. Then boot off the alternate system disk. Downtime is limited to
about 30-45 minutes on Sunday morning at 6:00 AM for the larger Oracle
database systems and 5 minutes for systems that take less time to boot.

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

Agreed.

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

I can buy that.

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

Would you be willing to put your job on the line for that? Probably
not. A port scan might be a good idea to make sure you don't have any
surprises waiting for you.

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

Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/Alpha Team Email: Cy.Schubert@osg.gov.bc.ca
Open Systems Group, ITSD
Ministry of Management Services
Province of BC
                    FreeBSD UNIX: cy@FreeBSD.org