RE: setsppfp bug

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