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



Relevant Pages

  • Re: [Full-Disclosure] MS Anti Virus?
    ... > running the firewall it shouldn't be an issue. ... you would only supposedly have new bugs in the latest revisions. ... >> had patches well in advance of the worm that impacted it, blaster, ... > If you install windows and attempt to either patch it or install firewall ...
    (Full-Disclosure)
  • Re: Baulders Gate series and corrupt files
    ... you can just play BG1 out of the box and the move on to BG2 ... If you don't install any patches at all, there are quite a lot of bugs. ...
    (comp.sys.ibm.pc.games.rpg)
  • Re: This is [Re:] How to improve the quality of the kernel[?].
    ... The goal is to get all patches for a maintained subsystem submitted to ... The fact is, some maintainers are excellent. ... Let's say that we aim for 0.1 bugs ... Blarney, where mistakes don't happen, developers are perfect, hardware is ...
    (Linux-Kernel)
  • Re: Patch cluster 10_x86_Recommended fails at 119255-77 (thir one on list)
    ... The patch set will complete installation in this session. ... Application of patches finished: 2010.11.28 17:54:45 ... Aborting due to failure while applying patch 119255-77. ... Install log files written: ...
    (comp.unix.solaris)
  • Re: Patch push programs for Win2K domain world?
    ... install it on a domain controller, but you can install it on other servers ... files for patches and service packs of all kinds. ... > - Cannot find a reliable way to query a host or the controller itself for ... > - When scheduled for deployment, it sometimes took UE a few hours to push ...
    (microsoft.public.win2000.security)