Re: setsppfp bug

Dan,

>what are the practical steps a shop can take *NOW* to prevent someone from
>using the setsppfp API?  

Option 1: Run level 50.  Also secure your sign-on DSPF from changes.
Implement a means to watch for new or changed objects running in the
system state.

Option 2: Make a minor variation of Gene's program, but when you find
that the first byte of "Work" is not 0 or 1, then alter the first 20
bytes of Work to blanks or another filler character.  Create a CL
program which calls this RPG, then does a TFRCTL to QCMD.  Make your
CL the routing entry which gets called in each interactive subsytem in
place of QCMD.  Your program will then get control fairly quickly
after sign-on to clear the buffer data.  I suspect there is still a
small window of exposure here.  Secure routing entries from being
changed, and ensure current routing entries do not have a trojan horse
or sniffer.

And secure your sign-on DSPF from changes.

What amazes me is how much attention Gene's 17-line RPG program is
attracting, while nobody has said anything about the 1-line DDS change
which works even at security level 50!  Like so many things, it seems
so blatantly obvious when you hear about it.  It makes you wonder why
you didn't think of it years ago.

I'm not saying Gene's program doesn't deserve the attention it gets --
it does -- but why has nobody mentioned the trivial LOGINP exploit?

I'd hesitate to call either of the techniques a "bug", but exploit
seems like a good word.

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