RE: setsppfp bug -- MI400

Gentlemen:

This type of action goes completely against IBM's stated policy.

However, I must agree with the gentleman. I had similar experiences but it
was many years ago.

Even today...good resources in the community are being wasted by the "you're
too dumb" attitude.

Steve Glanstein
mic@aloha.com

> -----Original Message-----
> From: owner-mi400@midrange.com [mailto:owner-mi400@midrange.com]On
> Behalf Of Gary Guthrie
> Sent: Friday, June 09, 2000 12:16 PM
> To: MI400@midrange.com
> Subject: Re: setsppfp bug
>
>
> 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
> +---
>

+---
| 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
+---