SCO (was Re: pt_chmod)

[karl () bagpuss demon co uk (Karl Strickland)]

OK, I didnt really want this discussion on bugtraq, but since you brought
it here, lets fill people in on the rest of the details; otherwise it
becomes one-sided and a little unfair.

> Karl Strickland wrote:
>
> Bela> Full disclosure has been sent to CERT for dissemination to other OS
> Bela> vendors.  I am not in a position to publically disclose full details at
>
> Karl> you might have cc'd it to 8lgm, to save us a few hours!!! :-)
>
> Excuse me, but I'm not feeling particularly friendly to 8LGM right now.

You missed the ':-)' there; we wouldnt really expect you to send us details.

> I appreciate the bug reports; I do not appreciate the infoterrorism.

We dont know what you mean by infoterrorism.  If SCO's attitude towards
people trying to get bugs fixed, is that this-action constitutes infoterrorism,
then SCO has a very bad attitude.  Maybe this partly explains the bitching
about SCO customer-support/support-contracts going on in biz.sco.general
right now.

> You have made a point that disclosure "works", but you refuse to adjust
> your tactics to make it work better.  I was not blowing smoke when I
> asked you to delay the advisories.  We could have had the fixes in
> place, ready to download, with proper MD5 checksums, proper install
> scripts, etc., if you'd been willing to negotiate.

Some facts:

1. You indicated that you were not the proper 'security-contact' for SCO,
   and that you did not know who this was or if one even existed.  However
   you continued to answer mails to security-alert () sco com.

2. You originally indicated that SCO had no intention of providing any
   patches for previous releases of your operating system, and said that
   the reported problems would only be fixed in the next release.

3. You said that login(1) could not be made secure in previous releases
   of your operating system - ie a security fix was not possible.  We did
   not accept this and suggested that the 'offending' code be executed
   after login has revoked its root privileges.  You never replied to this
   point.

4. We offered to postpone our announcements for another week, if SCO could
   give us a reason for doing so.  Our mail was never answered.

You seem to imply that had we waited a few more days, SCO could have put
out a 'proper' patch.  You also imply that this had been SCO's position
all along, and that SCO had indicated this to us.  In fact the only timescale
you mentioned to us was '6 weeks'.  I quote from mail sent to us on 25th Nov:

        "6 weeks probably seems like an outrageous amount of time.
         Let me assure you, it would be a heroic act on the part of
         someone in Support to get an SLS (Support Level Supplement
         -- the likely delivery vehicle for security fixes) out within
         6 weeks."

The fact that the patches were available after 2 or so days of the advisories
being released speaks for itself.  I think that if we had not been persistent
and released the advisories, we'd be lucky to see a patch within the next
3 months.

I'm sure your customers would also rather have these patches sooner rather
than later even if it means they are delivered on punched cards, rather
than an SLS (whatever that is).  Are you seriously suggesting it takes
more than 5 weeks to produce an install script and an MD5 checksum?

> All that aside, it is not my position to send out full disclosure, much
> as I might like to.  What I sent to CERT was properly channeled through
> SCO's CERT contact.  CERT is a recognized and official carrier for such
> materials.  8LGM is, I don't know, some former "black hat" types who are
> trying pretty hard to wear what looks like a "white hat" these days, but
> who can tell? 
  ^^^^^^^^^^^^

Well if you, or anyone else has any evidence to the contrary, please
post copies to bugtraq, comp.security.unix, 8lgm@bagpuss & Scotland Yard.
Of course, if you're just competing for 'bitch of the year award' ... :-)

> If CERT believes in you then I assume you'll be receiving
> a copy of my paper from them;

Well we dont expect to receive anything from CERT either; nor do we want
to.  For years, many people who deal with CERT have regarded them as a
one-way channel - information goes in and never out.  Unfortunately a lot
of it also vanishes down a big black hole once its in there.  Thats why
you never see advisories for things like lpd.  lpd has been a known problem
since around 1986, but CERT regarded it as being 'too hot for them to
handle'.  So it went down the black-hole instead.

> if not, well, I know you're smart enough
> to figure it out anyway.

Thankyou, I think.

> Bela> Your pt_chmod is safe if it coredumps when run as `pt_chmod <
> Bela> /etc/termcap`.  If not, it might or might not be safe.  Ask your OS
> Bela> vendor, "trace" or "truss".
>
> Karl> talking of trace, is sco's trace broken?  our copy at least, seems to
> Karl> miss out system calls.  eg for pt_chmod, trace never shows chown(2)
> Karl> being called; but if you disassemble it or single step it with adb,
> Karl> you can see that it does actually get called.
>
> RTFM -- our trace depends on a symbol table.  If you get anything at all
> out of a pt_chmod trace, it's because of the (unstripped) shared library
> it uses.  The COFF shared library doesn't cover every system call: those
> calls which are really just kernel stubs (move argument into register,
> trap into system) are statically linked because there was no space
> benefit, and a performance penalty, to calling them through a call table.
> (Yes, this means that the people who designed COFF shared libraries
> didn't understand all the potential benefits of shared libraries -- oh
> well -- probably one of the reasons ELF was developed).

Thanks for the info - I dont read RTF SCO M's :-)  I'd assumed trace
was implemented using ptrace(2) or whatever, and not a shared library
hack.

> Karl> Well done for getting those patches out so quickly. 
>
> Thanks, I guess.
>
> (and in another message)
>
> Karl> 8LGM have reverse engineered SCO's pt_chmod patch, and will be making
> Karl> exploit details available on Monday, along with exploit details for
> Karl> the (now patched) SCO problems reported last week.
>
> See, there you go again.  Have a little patience.  Let the fixed code
> propagate for a while.  Give administrators in far off corners of the
> world a chance to hear about this and put up defenses.  Also, let the
> gory details circulate via CERT for a while -- just because SCO has
> issued fixes does not mean there aren't other vendors whose code is
> still vulnerable.

Do you expect to be given any information from CERT as to when any other
affected vendors may have patches out?

> If you think this leaves out the freeware community,
> think again.  The people who maintain the various login suites and other
> such publically available utilities should be in contact with CERT just
> as commercial vendors are; they should receive this information through
> the same relatively secure conduits.

You are kidding yourself; CERT will generally not deal with these people.
Remember the rlogin -lf tricks of a couple of months ago?  I comitted the
patch to the FreeBSD 1.x src to fix this.  I asked CERT for information,
but they wouldnt tell me - I ended up having find it out elsewhere.  Its
not a big deal, and I dont really care - seeing as 8LGM probably now puts
out more advisories/patches per-year than CERT does, it doesnt really matter
much anymore.

But remember, CERT - for most people at least - is strictly a one way channel.

> They should have a chance to
> examine their code and if necessary, distribute corrected binaries
> and/or sources before disclosure.  (I realize that distributing fixed
> sources is very similar to disclosure, but it's not quite the same as
> posting exploitation scripts).

Distributing fixed binaries is the same; once you release a patch the game
is up.  Systems administrators and other people who may need to know what
the patch fixes probably do not have the time to disassemble your patches
and see whats changed.  Plenty of hackers have both the expertise and the
time to do this; so who looses out?  8LGM are trying to level out the
playing field here.

> As usual, not speaking for SCO...

Then lets hear from someone who does.

You claim not to speak for SCO, yet you post from their machines, do their
usenet PR work, CC your mails to security-alert@sco, receive mails sent to
security-alert@sco and answer mails sent to security-alert@sco.

In this matter, you are perceived by many to be 'SCO'; a one line 'disclaimer'
does not stop this.  If SCO thinks these issues are important enough to be
discussed, can they please get someone official to do it.

Most people want to know SCO's opinions and SCO's views on these issues -
not Bela Lubkin's.  If you're not speaking for SCO, is it correct for you to
be discussing confidential mails sent from 8lgm -> security-alert@sco
on bugtraq - seeing as you only have privileged access to this information
by virtue of your position within SCO?  You cannot have it both ways.

You brought this discussion to bugtraq, not us -- If you dont speak for
SCO, then who should we be dealing with?

------------------------------------------+-----------------------------------
Mailed using ELM on FreeBSD               |                    Karl Strickland
PGP 2.3a Public Key Available.            | Internet: karl () bagpuss demon co uk
                                          |