Re: pt_chmod

[belal () sco COM (Bela Lubkin)]

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.
I appreciate the bug reports; I do not appreciate the infoterrorism.
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.

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?  If CERT believes in you then I assume you'll be receiving
a copy of my paper from them; if not, well, I know you're smart enough
to figure it out anyway.

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

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

As usual, not speaking for SCO...

> Bela<