Good guess, but no. The code overlays an instruction with R5, which contains a modified copy of the instruction. As a result the length of the move will be 256 instead of 8. It does not in any way subvert code. The code itself is bad, but that's a separate issue. It's not rocket science.
Shooting yourself in the foot is easy. Subverting the integrity of a properly administered z/OS installation, not so much. It's easy to write programs with trojan horses, but getting people to run them is social engineering, not cracking the security controls. If your company doesn't have proper procedures to control what goes into production, then the kimono is open and there's no way to protect their data no matter how good z/OS security is. And yes, I have found, and reported, loopholes, but it's not as easy as you seem to believe. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of MELVYN MALTZ [0000072265160664-dmarc-requ...@listserv.uga.edu] Sent: Sunday, June 13, 2021 11:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: A problem with OPEN and CLOSE macros Hi Guys, Thanks for the responses, here's mine... To Charles... You made my point exactly, as you didn't at first realise what the code was doing, but you did 10 minutes later :-) >>>Mark Nelson is not your guy for this, unless you think there is an >>>integrity issue I believe there is, it certainly got Mark's attention, also a UK RACF expert that I know >>>Your gun, your bullet, your foot What I was trying to demonstrate is how a hacker could subvert code without it being obvious what was happening. My code wasn't subtle, if I had wanted to hide my evil-doing...I could do If I rewrote the code to overlay an I/O buffer then your company's data integrity is at risk ! Subverting z/OS or RACF is a little more difficult To Seymour... Like Charles, you haven't realised what the code does...exactly my point >>>Further, your code would fail I sent Mark the full program, I tested it and it works >>>R5 doesn't contain a DCB address. I know...OPEN wouldn't get that far because the end-of-list bit stays with DCB 1 I'm using R5 to do something nasty to storage beyond the MF=L Melvyn Maltz. ----- Original Message ----- From: "Seymour J Metz" <sme...@gmu.edu> To: <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Sent: Sunday, June 13, 2021 3:29 PM Subject: Re: A problem with OPEN and CLOSE macros Using an operand with the wrong length is a basic error, not limited to OPEN or even to macros. Further, your code would fail even if you corrected HERE24O to OPEN (DCB1,INPUT,*,),MF=L; R5 doesn't contain a DCB address. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of MELVYN MALTZ [0000072265160664-dmarc-requ...@listserv.uga.edu] Sent: Friday, June 11, 2021 4:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: A problem with OPEN and CLOSE macros 1) An OPEN/CLOSE with MF=L,MODE=24 can be overlayed with an MF=E,MODE=31 (and vice-versa). This results in destruction of the list, abends would occur 2) An OPEN/CLOSE with MF=L with (say) 2 entries can be overlayed with an MF=E with 3 entries. The end-of-list bit isn't touched, but a storage violation occurs It is true that the "DFSMS Macro Instructions for Data Sets" does warn against mixed mode and MF=L/E length differences with the usual 'unpredictable results may occur' The first problem doesn't worry me, but the second one does, look at this cut-down code...no apologies for it being contrived...if I wanted to hide it, I could do... LA 2,8-1 EX R2,EXMVC L R5,EXMVC OILF R5,X'00FF0000' OPEN (DCB2,OUTPUT,(R5)),MF=(E,HERE24O),MODE=24 EX R2,EXMVC ... HERE DC 8C'A' THERE DC 8C'B' * DCB1 DCB ... DCB2 DCB ... * HERE24O OPEN (DCB1,INPUT),MF=L EXMVC MVC THERE(0),HERE Using OPEN/CLOSE to subvert code sends this into another dimension I've been exchanging Emails with Mark Nelson (RACF Development) about this and have offered a solution, I can quite understand why IBM aren't keen on it 1) The OPEN/CLOSE list structure must change The 'new' structure needs an 8-byte header eg. DC C'OPCL' eyecatcher DC X'mode bit' DC XL3'no. of entries' 2) The OPEN/CLOSE SVC processors must be able to detect the 'old' and 'new' formats in order not to disturb existing code 3) OPEN/CLOSE MF=E will have extra coding for the 'new' format only, to detect both mode and storage violation errors...setting an error code Whether this is worth doing is largely up to the user community, I would be worried if an innocent looking macro could subvert program code Your thoughts ? Melvyn Maltz.
