|
I kept a lid on it from the USER community. I DID go to IBM. I won't mention names, but there was no interest shown. The IBMer didn't want to give me enough credit that I knew what I was talking about. When I next tried, I could have maybe gotten through to them, but first they wanted a Support Line contract or hourly rates paid. That was enough for me to just let them ignore it. Let's all be realistic - there's no way in the world that IBM just simply didn't realize that the user's password was stuffed out there at sign-on time. They knew it and ignored it because those of us not in the security-clique are just plain too dumb to discover things on our own. This is nothing new, though. Way back to the days of the S/38 I've witnessed the user community getting the "you're too dumb" attitude from IBM in a variety of ways. Don't get me wrong - I'm a HUGE, even GIGANTIC, IBM fan and have an excellent working relationship with them for the most part. It seemed they wanted to ignore this problem, so I obliged them by ignoring and not telling, too. Gary Guthrie Leif Svalgaard wrote: > > Gary, > > It would seem to me that "keeping a lid" on a hole is a > dubious way of dealing with a real issue. That's security > by obscurity. Why did you not urge IBM to fix it a long, > long time ago rather to allow the hole to exist. > The assumption that "the bad guys" would not > come across it is not a valid security policy. > > Leif > > ----- Original Message ----- > From: Gary Guthrie <GaryGuthrie@home.com> > To: <MI400@midrange.com> > Sent: Friday, June 09, 2000 1:31 PM > Subject: Re: setsppfp bug > > > Dan, > > > > I've kept a lid on this hole for a long, long time. It appears that it > > is now becoming common knowledge. You have almost everything you need to > > take care of the problem except perhaps a little work management > > knowledge. I'll send you details on plugging this hole (unfortunately, > > there are other holes). > > > > Gary Guthrie > > > > > > > > "Bale, Dan" wrote: > > > > > > Since the startup program can be secured, would this be a good interim > step > > > until (if?) IBM fixes this bug? Would you be willing to publish this > > > "eraser"? > > > > > > - Dan Bale > > > > > > > -----Original Message----- > > > > From: Leif Svalgaard [SMTP:leif@leif.org] > > > > Sent: Friday, June 09, 2000 1:13 PM > > > > To: MI400@midrange.com > > > > Subject: Re: setsppfp bug > > > > > > > > From: Bale, Dan <DBale@lear.com> > > > > > > > > > Well, this has been a fascinating, eye-opening, experience. I have > > > > > retrieved several user IDs and passwords now. So now we have a real, > > > > live, > > > > > working sniffer at level 30 & below. > > > > > > > > > > Don already asked the general question (and didn't get a direct > answer), > > > > so, > > > > > what are the practical steps a shop can take *NOW* to prevent someone > > > > from > > > > > using the setsppfp API? Can we slap *exclude authority on the > object? > > > > > Oops, I see there's no object by that name. Is there a way to sniff > the > > > > > sniffer? In other words, is there a way to tell if someone else is > > > > using > > > > > the setsppfp procedure? > > > > > > > > I think that Steve Glanstein's suggestion about having a startup > program > > > > that erases the information in the buffer is one way to go. Both Steve > and > > > > I have written such a program. The hole is that IBM does not erase it, > > > > but just lets it sit. > > > +--- > > > | This is the MI Programmers Mailing List! > > > | To submit a new message, send your mail to MI400@midrange.com. > > > | To subscribe to this list send email to MI400-SUB@midrange.com. > > > | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. > > > | Questions should be directed to the list owner/operator: > dr2@cssas400.com > > > +--- > > +--- > > | This is the MI Programmers Mailing List! > > | To submit a new message, send your mail to MI400@midrange.com. > > | To subscribe to this list send email to MI400-SUB@midrange.com. > > | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: dr2@cssas400.com > > +--- > > > > +--- > | This is the MI Programmers Mailing List! > | To submit a new message, send your mail to MI400@midrange.com. > | To subscribe to this list send email to MI400-SUB@midrange.com. > | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: dr2@cssas400.com > +--- +--- | This is the MI Programmers Mailing List! | To submit a new message, send your mail to MI400@midrange.com. | To subscribe to this list send email to MI400-SUB@midrange.com. | To unsubscribe from this list send email to MI400-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: dr2@cssas400.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.