SECURITY BUG IN INTERACTIVE UNIX SYSV386

Garry M. Paxinos pax at megasys.com
Mon Feb 18 22:47:05 AEST 1991


In article <PCG.91Feb16210231 at teachk.cs.aber.ac.uk> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:

   On 15 Feb 91 12:25:34 GMT, pax at megasys.com (Garry M. Paxinos) said:

   pax> In article <6027 at unix386.Convergent.COM>
   pax> mburg at unix386.Convergent.COM (Mike Burg) writes:

   mburg> From a view of a person who has work for various Unix system
   mburg> houses - you can't really blame ISC, ESIX, or any other vendors
   mburg> that current has the bug in it's release.

[...]

   Now think of this: there are literally dozens (if not hundreds!) of
   thousands of 386 system with this trojan horse sold and installed in
   civilian and military Government offices, many installed under the
   premise that C2 security was what the Government needed for better
   protecting sensitive (but not classified, thank goodness) data. All
   these systems will not be updated overnight; most will keep the trojan
   horse for their entire useful life.

Not to mention the systems at Nuclear Power Plants running critical 
monitoring functions.  One thing, I can assure you the 'trojan horse' will
not remain in the systems that my company has installed.

   pax> I agree completely on the above, with systems as complex as a full
   pax> Unix operating system it is quite likely that some things will slip
   pax> thru.

   This is simply unbelievable. It did not slip thru; all we have read
   points out that all vendors knew it was there, and left it in by way of
   a conscious decision.  All vendors except AT&T, SCO and Dell, that is.

Just to make sure we are on the same wavelength, I was merely saying I 
can understand that some things will slip thru.  However, I was definetly
not refering to the security bug.  

There is simply no excuse to not fix a problem like this as soon as you know 
about it. And this isn't even a case of something slipping thru the cracks
as it is documented in their release notes.  And they still didn't fix
it when an update came out SEVEN months later!

   pax> [ ... ] Unfortunately, as they seem to be able to come up with a
   pax> fix by next Friday (the 22nd), the later appears to be the case...

   AT&T say (informally, in this newsgroup) that they corrected it in
   3.2.1, and sent the corrections in its update tape to its licensees. SCO
   and and Dell installed the corrections. Probably ISC and the others have
   now decided to just put those corrections in.

I really have to wonder what their motivation was to wait this long...
Did they really want to put themselves in to a litigaous (sp?) situation?

   Incidentally, note that Dell's 3.2 product is a derivative of ISC's, yet
   Dell's does not have the trojan horse and ISC has it.

   ISC and many others boasts of the stringent and very expensive QA
   process they run on their products, the same process that took two years
   after a public fix had been posted to these screens to find the inode
   bug (and some other System V vendors still haven't discovered it!).

The inode bug is simply amazing as fixes have been posted here..  But then
again, ISC received corrected code from AT&T and didn't put that in either..

   IMNHO it is some system vendors (and ISC are bettert han most!) who are
   the worst hackers; apart from engaging in mass denial of service attacks
   on their customers called 'releases' :-), which usually cost much more
   lost time than the Internet Worm, they put (or leave) trojan horses in
   their systems, including those advertised as C2 more "secure" and sold
   to the Government as such.

   If you want to read something really hair raising about the potential
   for vendor hackery, read Ritchie's musing on what can be done with
   virusing 'cc' in his Turing award lecture in CACM.

Offhand, do you know which issue?

   The military have independent source verification teams and other very
   expensive ways of protecting themselves against supplier hackery; we
   only have the GPL :-).

   Finally, it is easy to think that if the author of this incident were a
   graduate student or a random chap somewhere he would by now probably
   have been arrested by the Secret Service, his machines impounded, and
   would be facing the probability of years in prison, and certain ruin.
   Think of this, and get information about the EFF.

It would be poetic justice for ISC to have their machines impounded... <sigh>

pax
--
E-Mail:pax at megasys.com    pax at ankh.ftl.fl.us    gmp at pinet.aip.org
USNail:Megasystems, Inc.    2055 South Congress Ave,  Delray Beach,  FL  33445
UUCP  :{gatech!uflorida!novavax!ankh,   mthvax,  shark,   attmail}!megasys!pax
Voice :407-243-2405   Data: 407-243-2407  Fax: 407-243-2408   Telex: 156281499
          "This is America, Right?!?!?"  member of 2 Live Crew



More information about the Comp.unix.sysv386 mailing list