RE: setsppfp bug

[edfishel@xxxxxxxxxx]

The security team discovered the LOGINP sign-on exposure for the first time
several months ago.  We felt it was serious enough to fix. The fix was
shipped to all supported releases at the beginning of February this year.
If you routinely apply hyper integrity PTFs you probably already have the
fix on your system.

The PTF for V3R2 was SF60975. The PTFs for V4R1 were SF60976 and SF60977.
The PTF for  V4R2 was SF60980. The PTF for V4R3 was SF60978. The PTF for
V4R4 was SF60979.  No PTF was needed for V4R5.

The fix disables the LOGINP function for the input display buffer of
subsystem monitor jobs.

The reason we ship these types of fixes as hyper integrity PTFs (which
normally do not describe the problem being fixed) is because we want to
make the fix available to our customers before we tell the world how those
customers are exposed. Just because we do not publish the security problems
does not mean we are practicing security by obsecurity.  We are protecting
our customers by allowing them to apply the fix before the security
exposure become general knowledge.  The other side of this coin is that
customers who care about security and integrity must apply the hyper
integrity PTFs.

Ed Fishel,
IBM Rochester

>> -----Original Message-----
>> From: dhandy@isgroup.net [mailto:dhandy@isgroup.net]
>>
>> 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?
>
>The LOGINP exposure was "public" knowledge on the /38 back in the '80's -
my
>old mentor showed it to me in 1987.  (We demonstrated that a /38 at
another
>site was vulnerable to it, even though they had gone to the new user
>profile/password signon option.)  I suspect that back then IBM would
answer
>any reports of the problem with "working as designed" - after all, you
could
>still get the /38 to show you the passwords back then.  Even today, I'll
bet
>the answer is likely to be something like "secure your subsystems so that
>the display files can't be changed illegitimately".  After all, how can
IBM
>disallow LOGINP for specific fields in a specific type of display file?
>Come up with an implementation that won't break legitimate uses of the
>function, please.
>
>Dave Shaw
>Spartan International, Inc.
>Spartanburg, SC



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