Re: More of LOG4J
The HLASM code with the WTO messages was test code. The sploit is all in the C code. It’s recursive and takes a while to grok. Very clever. > On 31 Jan 2022, at 22:56, Tom Brennan wrote: > > On 1/30/2022 11:11 PM, David Crayford wrote: > >> See my other post for details and links to the exploit source code which >> sets the ACEE bits. > > Thanks, I did see your post and then mentioned the source code below which I > believe is what you are talking about. That's when talk of SVC 242 came up > (and how it got there), and Itschak replied, "No user SVC was involved, not > needed." so I left that out of my hacking procedure. Not that I'm trying to > create a "how-to" document :) but unless we know what happened it's a little > difficult to defend. > > https://github.com/mainframed/logica/blob/master/Tfy.source.backdoor > > My feeling is the ASM program was never used for a few reasons: > #1 The web site indicates they probably ran it on Hercules for testing. > #2 The program contains some joke WTO's that any hacker would have removed > before running in production. > #3 It would need the magic SVC already in place and as you mentioned, those > should all be long gone by now. > > Ok, I've probably asked enough about this, so I'll stop now. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 1/30/2022 11:11 PM, David Crayford wrote: See my other post for details and links to the exploit source code which sets the ACEE bits. Thanks, I did see your post and then mentioned the source code below which I believe is what you are talking about. That's when talk of SVC 242 came up (and how it got there), and Itschak replied, "No user SVC was involved, not needed." so I left that out of my hacking procedure. Not that I'm trying to create a "how-to" document :) but unless we know what happened it's a little difficult to defend. https://github.com/mainframed/logica/blob/master/Tfy.source.backdoor My feeling is the ASM program was never used for a few reasons: #1 The web site indicates they probably ran it on Hercules for testing. #2 The program contains some joke WTO's that any hacker would have removed before running in production. #3 It would need the magic SVC already in place and as you mentioned, those should all be long gone by now. Ok, I've probably asked enough about this, so I'll stop now. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 31/1/22 2:28 pm, Tom Brennan wrote: Yes, it's probably just me still interested in the details of the hack. So bear with me and I promise to be quiet soon. So if they had a non-admin id, they certainly could have setup 443 as a client to dump an unprotected RACF DB to a remote server. None of that would need root access and could easily go undetected. Then once cracked, they could look for an admin id that had SPECIAL/OPERATIONS/UID=0 or whatever they wanted, and simply logon using the hacked password. That makes sense so far. What doesn't make sense is the references to getting ACEE bits or UID=0 by various means. So maybe those references (like the ASM code snip that calls SVC 242) were never really used and this hack was as simple as: See my other post for details and links to the exploit source code which sets the ACEE bits. 1) Get network TCPIP access to a mainframe, either because the ports are publicly available, via a compromised VPN company PC, etc. 2) Get a non-admin userid that can be logged onto via TSO, SSH, or whatever, perhaps also from a compromised company PC. It's my understanding that Logica stupidly used default accounts and passwords for FTP which is how Anakata first gained access. After that he had control of several user accounts. Nobody knows how this happened. It could have been social engineering or an insider threat. He learned and z/OS and tested the exploit using Hercules and a pirated copy of the AD/CD. 3) Run some code under that id to dump the RACF DB to a remote server 4) Look for admin userids in the DB and crack a password 5) Logon to an admin userid through the same TCPIP method as #1 6) Do more bad stuff as root or SPECIAL, trying not to leave tracks. Come to think of it, I seem to remember maybe 10 years ago or more, wasn't it Thierry Falisard (sp.) who came up with a dictionary ripper program that caused everyone (including me) to go check their RACF DB read protection? On 1/30/2022 6:52 PM, Bob Bridges wrote: I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was invol
Re: More of LOG4J
Yes, it's probably just me still interested in the details of the hack. So bear with me and I promise to be quiet soon. So if they had a non-admin id, they certainly could have setup 443 as a client to dump an unprotected RACF DB to a remote server. None of that would need root access and could easily go undetected. Then once cracked, they could look for an admin id that had SPECIAL/OPERATIONS/UID=0 or whatever they wanted, and simply logon using the hacked password. That makes sense so far. What doesn't make sense is the references to getting ACEE bits or UID=0 by various means. So maybe those references (like the ASM code snip that calls SVC 242) were never really used and this hack was as simple as: 1) Get network TCPIP access to a mainframe, either because the ports are publicly available, via a compromised VPN company PC, etc. 2) Get a non-admin userid that can be logged onto via TSO, SSH, or whatever, perhaps also from a compromised company PC. 3) Run some code under that id to dump the RACF DB to a remote server 4) Look for admin userids in the DB and crack a password 5) Logon to an admin userid through the same TCPIP method as #1 6) Do more bad stuff as root or SPECIAL, trying not to leave tracks. Come to think of it, I seem to remember maybe 10 years ago or more, wasn't it Thierry Falisard (sp.) who came up with a dictionary ripper program that caused everyone (including me) to go check their RACF DB read protection? On 1/30/2022 6:52 PM, Bob Bridges wrote: I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: IN
Re: More of LOG4J
On 31/1/22 10:52 am, Bob Bridges wrote: I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. They got access to root so can change any file in the system with impunity. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
I've been away a while; are we talking about Logica again? You may be thinking of inet.conf, an OMVS file that I'm-not-an-OMVS-expert-but I'm sure is supposed to be write-protected against non-admins. From a report: /* Quote begins: */ One back door they installed once they were in is a program of their own design that initiated contact with an internet server designated by the hackers, using port 443. This routine port helped deflect attention, but even more important is that the mainframe program was acting as a client; since the traffic was outgoing, initiated by SY19, many of the firewall measures against hacking would ignore it. The hackers would contact the outside server at their convenience and communicate with the mainframe. They also updated inet.conf, a Unix configuration file that must surely be write-protected against unauthorized changes. It’s supplied by IBM, and a line added to it can define a service, granting SUPERUSER status to (in this case) an incoming port-443 stream There was also a description of a process by which an ordinary ID could gain be switched to UID(0) GID(0), gaining root access. My copy of the Logica report says “The actual content of ‘go.rx’ script can be seen in Figure 91 on page 156The script takes two arguments, first the numerical UID to switch to, then the numerical group ID for the group under which the new command interpreter should be launched. If successful executed, this program would switch the user to a new user, without logging out and in, thus effectively getting the new user’s system-access permissions without having been prompted for a password.” But the REXX code is redacted from my copy /* Quote ends */ The ID they stole initially, I gather, did have read access to the RACF database, never a good idea; that's how they were able to get so many passwords afterward, by downloaded it and applying John-the-Ripper to it at leisure. --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Every movie has maybe one or two or three compelling reasons why it should be made. One is that this is a beloved book and people are going to want to see an adaptation. But you had better figure out the other two, because at the end of the day, this is a motion picture. -Ron Howard */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Brennan Sent: Sunday, January 30, 2022 18:18 Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) --- On 1/30/2022 12:09 PM, Itschak Mugzach wrote: > Ho Tom, > > Once they got root, they were able to unload racf DB that was not well > protected and run an (open source) password cracker. They had time to > get many user passwords. No user SVC was involved, not needed. I don't > know where David collects his information, but the breach is well > documented in many reports. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 31/1/22 4:09 am, Itschak Mugzach wrote: Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. Wrong! The "John the Ripper" cracking of RACF data bases was a separate incident. Although, there could be a correlation. No user SVC was involved, not needed. I never claimed there was. You have incorrectly connected my comment about "magic SVC's" to the Logica breach. I don't know where David collects his information, but the breach is well documented in many reports. One of my colleagues was a member of the OMVS development team at the time of the Logica breach and we have discussed it at length. He was part of the investigation team and to this day he is convinced Anakata was not working alone. He was also surprised there was so much information about it in the public domain. A large portion of the source code of the attack is in the public domain. I know Tom is a more than capable C programmer so I suggest taking a look at the meat of the hack. Elevation to root exploited a NetView REXX exec called CNMEUNIX which enabled him to invoke "setuid 0" to get root. Getting root gives you admin control in z/OS UNIX but you're not running authorized and certainly can't steal the RACF data base. The interesting code is DeFeeStRaTe.C [1] which exploits an APF-authorized zFS module, IOELMD10. It's a classic clobber the return address (R14) and run my shell code exploit, similar to return-to-libc exploits on Linux systems where a hacker calls code in kernel space and then overflows a buffer with malicious code which gets control still in kernel space. Check out the "shellcode_full" string which contains the code which is called from the APF authorized code. That's where MODESET is called and the ACEEFLG3 bits are set. At this point the attacker has the keys to the kingdom. [1] https://github.com/mainframed/logica/blob/master/DeFeNeStRaTe.C * * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
AFAIK, UID(0) (via CNMEUNIX) has nothing to do with reading (downloading) the unprotected RACF Database. There is another factor ... the uneducated/inexperienced administrators did not protect a multi-session product (IIRC, it was TPX). As well, the hackers found a bug in NVAS ... changing a non-display field on the screen allowed them to bypass certain controls. On 2022-01-30 18:18, Tom Brennan wrote: Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. Best, ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Thanks, so the ASM program from the blog was never used, but the main problems were: 1) Some way to get UID=0 access (I think Soldier of Fortan mentioned this years ago, which I hope has been fixed). 2) RACF DB that was not read protected (not the brightest) On 1/30/2022 12:09 PM, Itschak Mugzach wrote: Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. Best, ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Ho Tom, Once they got root, they were able to unload racf DB that was not well protected and run an (open source) password cracker. They had time to get many user passwords. No user SVC was involved, not needed. I don't know where David collects his information, but the breach is well documented in many reports. Best, ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sun, Jan 30, 2022 at 9:39 PM Tom Brennan wrote: > Hi Itschak, > > Yes, like you I've written SVC's, although I never came across one of > these "magic" ones. I've also written code to mess with the ACEE bits > similar to that hack sample. But this was under control of APF, with > auditor and management approval. > > My question is how the user got that far, and I haven't yet figured that > out from the blog page. For example, how did they get an address space > going where they could even run the code to set the ACEE bits. And did > they implement the SVC 242 or was it there already. I just don't have > enough information to lay blame, or don't fully understand the blog. > > On 1/30/2022 12:07 AM, Itschak Mugzach wrote: > > Tom, > > > > This is an old trick that allows a program to call SVC to switch to > > supervisor mode and key zero. Once you are there, you can do almost > > everything. for example, login to another user without specifying a > > password, use the bypass userid, and so on. > > > > However, David only mentions a facility that is quite common, but hasn't > > proved it was used in an illegal operation. > > > > Best, > > ITschak > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Hi Itschak, Yes, like you I've written SVC's, although I never came across one of these "magic" ones. I've also written code to mess with the ACEE bits similar to that hack sample. But this was under control of APF, with auditor and management approval. My question is how the user got that far, and I haven't yet figured that out from the blog page. For example, how did they get an address space going where they could even run the code to set the ACEE bits. And did they implement the SVC 242 or was it there already. I just don't have enough information to lay blame, or don't fully understand the blog. On 1/30/2022 12:07 AM, Itschak Mugzach wrote: Tom, This is an old trick that allows a program to call SVC to switch to supervisor mode and key zero. Once you are there, you can do almost everything. for example, login to another user without specifying a password, use the bypass userid, and so on. However, David only mentions a facility that is quite common, but hasn't proved it was used in an illegal operation. Best, ITschak -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
+1 *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sun, Jan 30, 2022 at 3:27 PM Seymour J Metz wrote: > That only works if there is such an SVC. A competent auditor would red > flag it immediately. Alas, not every auditor is competent :-( > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu] > Sent: Sunday, January 30, 2022 3:07 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: More of LOG4J > > Tom, > > This is an old trick that allows a program to call SVC to switch to > supervisor mode and key zero. Once you are there, you can do almost > everything. for example, login to another user without specifying a > password, use the bypass userid, and so on. > > However, David only mentions a facility that is quite common, but hasn't > proved it was used in an illegal operation. > > Best, > ITschak > > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere > Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux > and IBM I **| * > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
An SVC runs in supervisor mode; that's a much stronger privilege than UID(0). It's trivial to write such an SVC, but any competent auditor would shoot you down if you suggested it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tom Brennan [t...@tombrennansoftware.com] Sent: Sunday, January 30, 2022 2:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J The badcyber.com page points to a program calling a magic SVC. Maybe that's what David is referring to? But I didn't read/understand enough to see if they used UID=0 somehow to implement that SVC, or if they had to rely on it already being in place, or if this program was used at all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
That only works if there is such an SVC. A competent auditor would red flag it immediately. Alas, not every auditor is competent :-( -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu] Sent: Sunday, January 30, 2022 3:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Tom, This is an old trick that allows a program to call SVC to switch to supervisor mode and key zero. Once you are there, you can do almost everything. for example, login to another user without specifying a password, use the bypass userid, and so on. However, David only mentions a facility that is quite common, but hasn't proved it was used in an illegal operation. Best, ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Tom, This is an old trick that allows a program to call SVC to switch to supervisor mode and key zero. Once you are there, you can do almost everything. for example, login to another user without specifying a password, use the bypass userid, and so on. However, David only mentions a facility that is quite common, but hasn't proved it was used in an illegal operation. Best, ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sun, Jan 30, 2022 at 9:57 AM Tom Brennan wrote: > The badcyber.com page points to a program calling a magic SVC. Maybe > that's what David is referring to? But I didn't read/understand enough > to see if they used UID=0 somehow to implement that SVC, or if they had > to rely on it already being in place, or if this program was used at all. > > https://github.com/mainframed/logica/blob/master/Tfy.source.backdoor > > On 1/29/2022 10:27 PM, Itschak Mugzach wrote: > > David, > > > > I am 40+ years developer in assembler. I believe I wrote and used SVCs > > before you. If you read my previous emails you would see that > modernisation > > is a must. However, you haven't given any sample of breach caused by > > standard mvs code, while I gave two. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
The badcyber.com page points to a program calling a magic SVC. Maybe that's what David is referring to? But I didn't read/understand enough to see if they used UID=0 somehow to implement that SVC, or if they had to rely on it already being in place, or if this program was used at all. https://github.com/mainframed/logica/blob/master/Tfy.source.backdoor On 1/29/2022 10:27 PM, Itschak Mugzach wrote: David, I am 40+ years developer in assembler. I believe I wrote and used SVCs before you. If you read my previous emails you would see that modernisation is a must. However, you haven't given any sample of breach caused by standard mvs code, while I gave two. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
David, I am 40+ years developer in assembler. I believe I wrote and used SVCs before you. If you read my previous emails you would see that modernisation is a must. However, you haven't given any sample of breach caused by standard mvs code, while I gave two. *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sun, Jan 30, 2022 at 3:58 AM David Crayford wrote: > On 29/1/22 11:53 pm, Itschak Mugzach wrote: > > It seems you haven't read the link you sent... This article says exactly > > what I claim. It was a UUS (aka UNIX) vulnerability that helped them get > > UID 0. This is how it started. > > You've changed direction now from open source to z/OS UNIX. Are you > aware of what a "magic SVC" is? There have been many such "magic SVC's" > shipped by vendors over the years > which could easily be exploited to grant an unauthorizd user access to > RACF SPECIAL without running in z/OS UNIX. You say you have a scanner. > Does it scan the SVC table? > > I'm confused by what your agenda is. Should be get rid of anything > modern, including z/OS UNIX which dates back to the 90s? Should we get > rid of TCP/IP and bunker down in caves like > a bunch of troglodytes punching out code using 1950s/60s programming > languages on terminal attached 3270 green screens using TSO? > > > > ITschak > > > > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere > > Platform* *|* *Information Security Continuous Monitoring for Z/OS, > zLinux > > and IBM I **| * > > > > *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 > **|* > > *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* > > > > > > > > > > > > On Sat, Jan 29, 2022 at 5:49 PM Raphaël Jacquot > wrote: > > > >> Le 29/01/2022 à 16:12, Itschak Mugzach a écrit : > >>> David, > >>> > >>> Prove your claim reg. "Enterprise software". Give at least one sample. > My > >>> claim is already proved. Nordea bank was penetrated from USS, LOG4J is > an > >>> open source. > >>> > >>> ITschak > >> here is an article about the Nordea hack. > >> > >> https://badcyber.com/a-history-of-a-hacking/ > >> > >> now go read it, in particular the details about RACF not being good > >> enough and stop blaming opensource for the failings > >> > >> -- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 29/1/22 11:53 pm, Itschak Mugzach wrote: It seems you haven't read the link you sent... This article says exactly what I claim. It was a UUS (aka UNIX) vulnerability that helped them get UID 0. This is how it started. You've changed direction now from open source to z/OS UNIX. Are you aware of what a "magic SVC" is? There have been many such "magic SVC's" shipped by vendors over the years which could easily be exploited to grant an unauthorizd user access to RACF SPECIAL without running in z/OS UNIX. You say you have a scanner. Does it scan the SVC table? I'm confused by what your agenda is. Should be get rid of anything modern, including z/OS UNIX which dates back to the 90s? Should we get rid of TCP/IP and bunker down in caves like a bunch of troglodytes punching out code using 1950s/60s programming languages on terminal attached 3270 green screens using TSO? ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Jan 29, 2022 at 5:49 PM Raphaël Jacquot wrote: Le 29/01/2022 à 16:12, Itschak Mugzach a écrit : David, Prove your claim reg. "Enterprise software". Give at least one sample. My claim is already proved. Nordea bank was penetrated from USS, LOG4J is an open source. ITschak here is an article about the Nordea hack. https://badcyber.com/a-history-of-a-hacking/ now go read it, in particular the details about RACF not being good enough and stop blaming opensource for the failings -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
It seems you haven't read the link you sent... This article says exactly what I claim. It was a UUS (aka UNIX) vulnerability that helped them get UID 0. This is how it started. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Jan 29, 2022 at 5:49 PM Raphaël Jacquot wrote: > Le 29/01/2022 à 16:12, Itschak Mugzach a écrit : > > David, > > > > Prove your claim reg. "Enterprise software". Give at least one sample. My > > claim is already proved. Nordea bank was penetrated from USS, LOG4J is an > > open source. > > > > ITschak > > here is an article about the Nordea hack. > > https://badcyber.com/a-history-of-a-hacking/ > > now go read it, in particular the details about RACF not being good > enough and stop blaming opensource for the failings > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Le 29/01/2022 à 16:12, Itschak Mugzach a écrit : David, Prove your claim reg. "Enterprise software". Give at least one sample. My claim is already proved. Nordea bank was penetrated from USS, LOG4J is an open source. ITschak here is an article about the Nordea hack. https://badcyber.com/a-history-of-a-hacking/ now go read it, in particular the details about RACF not being good enough and stop blaming opensource for the failings -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
David, Prove your claim reg. "Enterprise software". Give at least one sample. My claim is already proved. Nordea bank was penetrated from USS, LOG4J is an open source. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Sat, Jan 29, 2022 at 2:27 AM David Crayford wrote: > On 29/1/22 12:53 am, Phil Smith III wrote: > >> pipeline every time we merge into our development branch or master. > > > > > > I know YOU know this, David, but it bears stating explicitly: none of > these > > tools would (did) detect the log4j vuln. > > I'm cognizant to that. Humans find vulnerabilities. In the case of > log4shell it was a security researcher at Alibaba who then reported it > to Apache. > In the case of Shellshock, Heartbeat, Meltdown, Spectre etc it was > security researchers at google. Big tech offer bounties to anybody who > finds vulnerabilities in their products. > As soon as a 0day is found, it is reported to the maintainer and then > logged in the CVE database and disclosed to the world. Compare this to > IBM who have typically corporate > disclosure rules. A case in point is IBM rejecting a 0Day disclosure > which they said was "out of scope" with their disclosure rules and then > did a U-turn and blamed a process > error. > https://techmonitor.ai/techonology/cybersecurity/ibms-data-risk-manager > > ITschak is of the opinion that the mainframe is less secure because of > the use of open source software. I would argue that a lot of Enterprise > software is just as vulnerable. And in a lot of > cases more vulnerable because it is closed source doesn't have as many > eyes scrutinizing it. Others may have the opposite opinion. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 29/1/22 12:53 am, Phil Smith III wrote: pipeline every time we merge into our development branch or master. I know YOU know this, David, but it bears stating explicitly: none of these tools would (did) detect the log4j vuln. I'm cognizant to that. Humans find vulnerabilities. In the case of log4shell it was a security researcher at Alibaba who then reported it to Apache. In the case of Shellshock, Heartbeat, Meltdown, Spectre etc it was security researchers at google. Big tech offer bounties to anybody who finds vulnerabilities in their products. As soon as a 0day is found, it is reported to the maintainer and then logged in the CVE database and disclosed to the world. Compare this to IBM who have typically corporate disclosure rules. A case in point is IBM rejecting a 0Day disclosure which they said was "out of scope" with their disclosure rules and then did a U-turn and blamed a process error. https://techmonitor.ai/techonology/cybersecurity/ibms-data-risk-manager ITschak is of the opinion that the mainframe is less secure because of the use of open source software. I would argue that a lot of Enterprise software is just as vulnerable. And in a lot of cases more vulnerable because it is closed source doesn't have as many eyes scrutinizing it. Others may have the opposite opinion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Country of development was Re: More of LOG4J
https://en.wikipedia.org/wiki/Kaspersky_bans_and_allegations_of_Russian_government_ties Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Brennan Sent: Thursday, January 27, 2022 8:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Country of development was Re: More of LOG4J On 1/27/2022 6:03 PM, Clark Morris wrote: > On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan > wrote: > >> Those are things we don't like to talk about :) And even less talked >> about: What's to stop a trusted ISV or even IBM from being hacked or >> having a rogue employee that does the same? > > Does the country where the software is developed matter? In most > countries, the citizen is required to place nation above employer. One that comes to mind is Eugene Kaspersky, who (if I remember correctly) used to post in shareware newgroups I was involved with in the late 1990's. Super smart guy, and his company almost always discovered and mitigated PC viruses well prior to Norton, McAfee, and the others. Regardless, I think the USA banned his software on government computers, I assume with no evidence other than the country of origin. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Not only that. Many of the vulnerabilities are zero day. This means that they were not known at the time you packed your product. LOG4J is a great example for a 0D. As such, as Phill mentioned, they will not be discovered by any toll you have. ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Fri, Jan 28, 2022 at 6:53 PM Phil Smith III wrote: > David Crayford wrote: > > >It's company policy where I work to perform code scans using Synopsis > > >tools such as Black Duck and Polaris. These tools scan for license > > >issues, vulnerabilities, compliance etc. Polaris is so sophisticated > > >it flagged a violation because it had detected I was using an SSLSocket > > >without verifying the peer hostname. These scans are run in our DevOps > > >pipeline every time we merge into our development branch or master. > > > > I know YOU know this, David, but it bears stating explicitly: none of these > tools would (did) detect the log4j vuln. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
David Crayford wrote: >It's company policy where I work to perform code scans using Synopsis >tools such as Black Duck and Polaris. These tools scan for license >issues, vulnerabilities, compliance etc. Polaris is so sophisticated >it flagged a violation because it had detected I was using an SSLSocket >without verifying the peer hostname. These scans are run in our DevOps >pipeline every time we merge into our development branch or master. I know YOU know this, David, but it bears stating explicitly: none of these tools would (did) detect the log4j vuln. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Country of development was Re: More of LOG4J
On 1/27/2022 6:03 PM, Clark Morris wrote: On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan wrote: Those are things we don't like to talk about :) And even less talked about: What's to stop a trusted ISV or even IBM from being hacked or having a rogue employee that does the same? Does the country where the software is developed matter? In most countries, the citizen is required to place nation above employer. One that comes to mind is Eugene Kaspersky, who (if I remember correctly) used to post in shareware newgroups I was involved with in the late 1990's. Super smart guy, and his company almost always discovered and mitigated PC viruses well prior to Norton, McAfee, and the others. Regardless, I think the USA banned his software on government computers, I assume with no evidence other than the country of origin. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Country of development was Re: More of LOG4J
On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan wrote: >Those are things we don't like to talk about :) And even less talked >about: What's to stop a trusted ISV or even IBM from being hacked or >having a rogue employee that does the same? Does the country where the software is developed matter? In most countries, the citizen is required to place nation above employer. Clark Morris > >On 1/26/2022 11:41 AM, Gibney, Dave wrote: >> If I was a long term bad actor, or perhaps a nation/state, I might consider >> evaluating open source for useful/popular components. Then, contribute to >> their development, spread, and usefulness, while inserting subtle >> exploitable defects. >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 27/1/22 10:19 pm, Mike Schwab wrote: On Thu, Jan 27, 2022 at 10:12 AM David Crayford wrote: On 27/1/22 2:35 pm, ITschak Mugzach wrote: At Solarwind, twice the size of Rocket, the toxic code was injected during the build process, by someone(s) penetrated long before they started to interfere with code. BTW, the Solarwind attack was based on a vendor code, not open source. And how did the system get penetrated to inject the malicious code? Social engineering? What I find disconcerting is that nobody noticed malicous code in the code reviews and pull requests. It was added after that part. It was only sent to users. They don't know that. According to Microsofts analysis [1] the attackers were able to access the company’s software development or distribution pipeline. As this is obviously the work of a nation state is pretty difficult to protect against intelligence agencies. They could have bribed somebody on the inside, blackmailed them or had a bad actor on the inside. Almost all of the DoD leaks have been down to corrupt employees taking bribes. Remember Stuxnet and Flame? No hardware or operating system is secure from organisations that have teams of engineers with IQs of 170 backed by spies engaged in espionage. [1] https://www.microsoft.com/security/blog/2020/12/18/analyzing-solorigate-the-compromised-dll-file-that-started-a-sophisticated-cyberattack-and-how-microsoft-defender-helps-protect/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On Thu, Jan 27, 2022 at 10:12 AM David Crayford wrote: > > On 27/1/22 2:35 pm, ITschak Mugzach wrote: > > > At Solarwind, twice the > > size of Rocket, the toxic code was injected during the build process, by > > someone(s) penetrated long before they started to interfere with code. BTW, > > the Solarwind attack was based on a vendor code, not open source. > > And how did the system get penetrated to inject the malicious code? > Social engineering? What I find disconcerting is that nobody noticed > malicous code in the code reviews and pull requests. > It was added after that part. It was only sent to users. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Or something similar to this: https://www.theverge.com/2022/1/9/22874949/developer-corrupts-open-source-libraries-projects-affected Sebastian On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan wrote: >Those are things we don't like to talk about :) And even less talked >about: What's to stop a trusted ISV or even IBM from being hacked or >having a rogue employee that does the same? > >On 1/26/2022 11:41 AM, Gibney, Dave wrote: >> If I was a long term bad actor, or perhaps a nation/state, I might consider >> evaluating open source for useful/popular components. Then, contribute to >> their development, spread, and usefulness, while inserting subtle >> exploitable defects. >> > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 27/1/22 2:35 pm, ITschak Mugzach wrote: memento Solarwind... David, I like your confidence. What I am confident about is that if any vulnerability is discovered our infosec team will use BlackDuck to detect all of our products that need to be patched. At Solarwind, twice the size of Rocket, the toxic code was injected during the build process, by someone(s) penetrated long before they started to interfere with code. BTW, the Solarwind attack was based on a vendor code, not open source. And how did the system get penetrated to inject the malicious code? Social engineering? What I find disconcerting is that nobody noticed malicous code in the code reviews and pull requests. ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Thu, Jan 27, 2022 at 4:03 AM David Crayford wrote: On 27/1/22 4:35 am, Tom Brennan wrote: Those are things we don't like to talk about :) Indeed! And even less talked about: What's to stop a trusted ISV or even IBM from being hacked or having a rogue employee that does the same? Absolutely nothing. Any executable code that runs authorized can contain vulnerabilities. Some of our best guys, distinguished engineers etc run our Secure Engineer training. We also use IBMs Secure Engineering scanner which checks executable code for vulnerabilities. I haven't used it but I attended a training session and it can detect all sorts of nasties. You can see any example of a z/OS security vulnerability it detected here https://www.ibm.com/support/pages/apar/OA38586. I haven't checked lately but how many packages are there on the CBTtape the switch to supervisor state key0 when they don't require key0? Unfortunately, that was and still is quite a common practice. On 1/26/2022 11:41 AM, Gibney, Dave wrote: If I was a long term bad actor, or perhaps a nation/state, I might consider evaluating open source for useful/popular components. Then, contribute to their development, spread, and usefulness, while inserting subtle exploitable defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
memento Solarwind... David, I like your confidence. At Solarwind, twice the size of Rocket, the toxic code was injected during the build process, by someone(s) penetrated long before they started to interfere with code. BTW, the Solarwind attack was based on a vendor code, not open source. ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Thu, Jan 27, 2022 at 4:03 AM David Crayford wrote: > On 27/1/22 4:35 am, Tom Brennan wrote: > > Those are things we don't like to talk about :) > > Indeed! > > > > And even less talked about: What's to stop a trusted ISV or even IBM > > from being hacked or having a rogue employee that does the same? > > Absolutely nothing. Any executable code that runs authorized can contain > vulnerabilities. Some of our best guys, distinguished engineers etc run > our Secure Engineer training. We also use IBMs Secure Engineering > scanner which checks > executable code for vulnerabilities. I haven't used it but I attended a > training session and it can detect all sorts of nasties. You can see any > example of a z/OS security vulnerability it detected here > https://www.ibm.com/support/pages/apar/OA38586. > > I haven't checked lately but how many packages are there on the CBTtape > the switch to supervisor state key0 when they don't require key0? > Unfortunately, that was and still is quite a common practice. > > > > > > On 1/26/2022 11:41 AM, Gibney, Dave wrote: > >> If I was a long term bad actor, or perhaps a nation/state, I might > >> consider evaluating open source for useful/popular components. Then, > >> contribute to their development, spread, and usefulness, while > >> inserting subtle exploitable defects. > >> > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 27/1/22 3:36 am, ITschak Mugzach wrote: It is a nightmare to vendors and clients looking for potential security issues. Not if they invest in state of the art tooling. Black Duck and Polaris make short work of scanning for vulnerabilities. FRom other hand, open source is here to stay. In short, mainframe modernization has its price. Agreed. If the mainframe doesn't modernize it will wither on the vine. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 26/1/22 11:31 pm, Kirk Wolf wrote: Good companies have policies and processes for approving any open source used internally. What's the alternative, write everything from scratch? Surely there will be no vulnerabilities there:-) It's company policy where I work to perform code scans using Synopsis tools such as Black Duck and Polaris. These tools scan for license issues, vulnerabilities, compliance etc. Polaris is so sophisticated it flagged a violation because it had detected I was using an SSLSocket without verifying the peer hostname. These scans are run in our DevOps pipeline every time we merge into our development branch or master. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 27/1/22 4:35 am, Tom Brennan wrote: Those are things we don't like to talk about :) Indeed! And even less talked about: What's to stop a trusted ISV or even IBM from being hacked or having a rogue employee that does the same? Absolutely nothing. Any executable code that runs authorized can contain vulnerabilities. Some of our best guys, distinguished engineers etc run our Secure Engineer training. We also use IBMs Secure Engineering scanner which checks executable code for vulnerabilities. I haven't used it but I attended a training session and it can detect all sorts of nasties. You can see any example of a z/OS security vulnerability it detected here https://www.ibm.com/support/pages/apar/OA38586. I haven't checked lately but how many packages are there on the CBTtape the switch to supervisor state key0 when they don't require key0? Unfortunately, that was and still is quite a common practice. On 1/26/2022 11:41 AM, Gibney, Dave wrote: If I was a long term bad actor, or perhaps a nation/state, I might consider evaluating open source for useful/popular components. Then, contribute to their development, spread, and usefulness, while inserting subtle exploitable defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Kirk Wolf wrote: > Sorry, I agree that the entirety of what you wrote was more balanced. I reacted (poorly) to this part: "Same with open source: using random code from an unknown author would have been unthinkable; now it's common." >I don't think that this is common. Mostly projects use popular open source projects. Most of these have a history, many contributors, test suites, etc. Sure, that was a bit hyperbolic, though by "unknown" I do mean that-typically they're not known quantities like employees (theoretically*) are. Hans Reiser, anyone? >What was shocking about the LOG4J vulnerability was that is was one of these. Indeed. Glad we could agree we aren't really disagreeing! ...phsiii *Scott Tyree, anyone? Yeah, he was at Sterling and then CA when I was there. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Many people are worried, which is why sandboxed application environments are becoming so popular. On Wed, Jan 26, 2022, at 2:35 PM, Tom Brennan wrote: > Those are things we don't like to talk about :) And even less talked > about: What's to stop a trusted ISV or even IBM from being hacked or > having a rogue employee that does the same? > > On 1/26/2022 11:41 AM, Gibney, Dave wrote: > > If I was a long term bad actor, or perhaps a nation/state, I might consider > > evaluating open source for useful/popular components. Then, contribute to > > their development, spread, and usefulness, while inserting subtle > > exploitable defects. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Those are things we don't like to talk about :) And even less talked about: What's to stop a trusted ISV or even IBM from being hacked or having a rogue employee that does the same? On 1/26/2022 11:41 AM, Gibney, Dave wrote: If I was a long term bad actor, or perhaps a nation/state, I might consider evaluating open source for useful/popular components. Then, contribute to their development, spread, and usefulness, while inserting subtle exploitable defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
In a different sort of way, it is a real tribute to the usability of Log4j. Seems like all popular software/hardware suffers from vulnerability eventually. And a reminder not to be too trusting of software. Rob On Wed, Jan 26, 2022 at 2:41 PM Gibney, Dave < 03b5261cfd78-dmarc-requ...@listserv.ua.edu> wrote: > If I was a long term bad actor, or perhaps a nation/state, I might > consider evaluating open source for useful/popular components. Then, > contribute to their development, spread, and usefulness, while inserting > subtle exploitable defects. > > > -Original Message- > > From: IBM Mainframe Discussion List On > > Behalf Of Kirk Wolf > > Sent: Wednesday, January 26, 2022 11:25 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: More of LOG4J > > > > Phil, > > > > Sorry, I agree that the entirety of what you wrote was more balanced. I > > reacted (poorly) to this part: > > > > "Same with open source: using random code from an unknown author > > would have been unthinkable; now it's common." > > > > I don't think that this is common. Mostly projects use popular open > source > > projects. Most of these have a history, many contributors, test suites, > etc. > > What was shocking about the LOG4J vulnerability was that is was one of > > these. > > > > -- Kirk Wolf > > > > On Wed, Jan 26, 2022, at 12:34 PM, Phil Smith III wrote: > > > Kirk Wolf wrote: > > > > > > >Is that really what you think is going on? > > > >The economics of open source are about *reuse*. The overwhelming > > majority > > > of software these days is built with it for that reason. Good > developers > > > are very careful about what open source that they use.Good > companies > > > have policies and processes for approving any open source used > internally. > > > What's the alternative, write everything from scratch? Surely there > will > > > be no vulnerabilities there :-) There are complex trade-offs here > that > > > haven't been touched as yet on ibm-main. > > > > > > > > > > > > I guess I didn't make myself clear, because what you wrote is > precisely how > > > I think. Not sure what you took from what I wrote that was > different-not > > > being pissy, just noting that we seem to be in violent agreement! > > > > > > > > > > > > Yes, in days of yore, you'd write it all from scratch. And I was > trying to > > > say that that was NOT necessarily more secure: it was a different > > > environment, so things didn't matter as much. There weren't a million > > > monkeys banging on the door with typewriters. > > > > > > > > > > > > > What's shocking about the LOG4J vulnerability is that it has been a > > > quality component used by thousands of projects for so long (20 years?, > > not > > > sure exactly). People armed with no understanding of the > vulnerability or > > > even Java immediately began contacting all of their software vendors, > even > > > products that clearly don't even use java. This only made the problem > > > worse. > > > > > > > > > > > > Yes. I think I've noted before that the ""given enough eyeballs, all > bugs > > > are shallow" line, while not intended as a justification for blind use > of > > > open source, seems to have been used as such. The log4j debacle should > > (but > > > won't) convince folks that it should not be. > > > > > > > > > > > > And what may be a repeat, but something I wrote elsewhere and perhaps > > here: > > > > > > It's also worth noting that a feature conceptually very, very similar > to the > > > log4j thing existed almost 40 years ago, in PROFS. DCF included a .sy > > > command that would execute a system command. So, as a friend realized, > > you > > > could send someone a document that did something nasty, like erase all > > their > > > files or log them off (or send the CEO a message saying "You're a > "), > > > simply by reading it. IBM took this as a SEV1 and fixed it; decades > later, > > > we've spent the last while dealing with essentially the same dumb > feechur. > > > > > > > > > > > > So over how many years, how many people saw this feature and didn't say > > >
Re: More of LOG4J
If I was a long term bad actor, or perhaps a nation/state, I might consider evaluating open source for useful/popular components. Then, contribute to their development, spread, and usefulness, while inserting subtle exploitable defects. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Kirk Wolf > Sent: Wednesday, January 26, 2022 11:25 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: More of LOG4J > > Phil, > > Sorry, I agree that the entirety of what you wrote was more balanced. I > reacted (poorly) to this part: > > "Same with open source: using random code from an unknown author > would have been unthinkable; now it's common." > > I don't think that this is common. Mostly projects use popular open source > projects. Most of these have a history, many contributors, test suites, etc. > What was shocking about the LOG4J vulnerability was that is was one of > these. > > -- Kirk Wolf > > On Wed, Jan 26, 2022, at 12:34 PM, Phil Smith III wrote: > > Kirk Wolf wrote: > > > > >Is that really what you think is going on? > > >The economics of open source are about *reuse*. The overwhelming > majority > > of software these days is built with it for that reason. Good developers > > are very careful about what open source that they use.Good companies > > have policies and processes for approving any open source used internally. > > What's the alternative, write everything from scratch? Surely there will > > be no vulnerabilities there :-) There are complex trade-offs here that > > haven't been touched as yet on ibm-main. > > > > > > > > I guess I didn't make myself clear, because what you wrote is precisely how > > I think. Not sure what you took from what I wrote that was different-not > > being pissy, just noting that we seem to be in violent agreement! > > > > > > > > Yes, in days of yore, you'd write it all from scratch. And I was trying to > > say that that was NOT necessarily more secure: it was a different > > environment, so things didn't matter as much. There weren't a million > > monkeys banging on the door with typewriters. > > > > > > > > > What's shocking about the LOG4J vulnerability is that it has been a > > quality component used by thousands of projects for so long (20 years?, > not > > sure exactly). People armed with no understanding of the vulnerability or > > even Java immediately began contacting all of their software vendors, even > > products that clearly don't even use java. This only made the problem > > worse. > > > > > > > > Yes. I think I've noted before that the ""given enough eyeballs, all bugs > > are shallow" line, while not intended as a justification for blind use of > > open source, seems to have been used as such. The log4j debacle should > (but > > won't) convince folks that it should not be. > > > > > > > > And what may be a repeat, but something I wrote elsewhere and perhaps > here: > > > > It's also worth noting that a feature conceptually very, very similar to the > > log4j thing existed almost 40 years ago, in PROFS. DCF included a .sy > > command that would execute a system command. So, as a friend realized, > you > > could send someone a document that did something nasty, like erase all > their > > files or log them off (or send the CEO a message saying "You're a "), > > simply by reading it. IBM took this as a SEV1 and fixed it; decades later, > > we've spent the last while dealing with essentially the same dumb feechur. > > > > > > > > So over how many years, how many people saw this feature and didn't say > > "Hey, you could do Very Bad Things with that"??! Amazing. > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Kirk Wolf > Dovetailed Technologies > https://urldefense.com/v3/__http://dovetail.com__;!!JmPEgBY0HMszNaDT > !4QAd_Gz4WlKwY3Xu-zffi26-SQxI_MDJSMh- > eemXy6IZm39SDMCzfDOJiuzfqQ$ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
I was told about LOG4J V2 (2.1.x for example) from other people that ran the scanner on 2.5 systems. It is a nightmare to vendors and clients looking for potential security issues. FRom other hand, open source is here to stay. In short, mainframe modernization has its price. ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * On Wed, Jan 26, 2022 at 9:25 PM Kirk Wolf wrote: > Phil, > > Sorry, I agree that the entirety of what you wrote was more balanced. I > reacted (poorly) to this part: > > "Same with open source: using random code from an unknown author would > have been unthinkable; now it's common." > > I don't think that this is common. Mostly projects use popular open > source projects. Most of these have a history, many contributors, test > suites, etc.What was shocking about the LOG4J vulnerability was that is > was one of these. > > -- Kirk Wolf > > On Wed, Jan 26, 2022, at 12:34 PM, Phil Smith III wrote: > > Kirk Wolf wrote: > > > > >Is that really what you think is going on? > > >The economics of open source are about *reuse*. The overwhelming > majority > > of software these days is built with it for that reason. Good > developers > > are very careful about what open source that they use.Good companies > > have policies and processes for approving any open source used > internally. > > What's the alternative, write everything from scratch? Surely there > will > > be no vulnerabilities there :-) There are complex trade-offs here that > > haven't been touched as yet on ibm-main. > > > > > > > > I guess I didn't make myself clear, because what you wrote is precisely > how > > I think. Not sure what you took from what I wrote that was different-not > > being pissy, just noting that we seem to be in violent agreement! > > > > > > > > Yes, in days of yore, you'd write it all from scratch. And I was trying > to > > say that that was NOT necessarily more secure: it was a different > > environment, so things didn't matter as much. There weren't a million > > monkeys banging on the door with typewriters. > > > > > > > > > What's shocking about the LOG4J vulnerability is that it has been a > > quality component used by thousands of projects for so long (20 years?, > not > > sure exactly). People armed with no understanding of the vulnerability > or > > even Java immediately began contacting all of their software vendors, > even > > products that clearly don't even use java. This only made the problem > > worse. > > > > > > > > Yes. I think I've noted before that the ""given enough eyeballs, all bugs > > are shallow" line, while not intended as a justification for blind use of > > open source, seems to have been used as such. The log4j debacle should > (but > > won't) convince folks that it should not be. > > > > > > > > And what may be a repeat, but something I wrote elsewhere and perhaps > here: > > > > It's also worth noting that a feature conceptually very, very similar to > the > > log4j thing existed almost 40 years ago, in PROFS. DCF included a .sy > > command that would execute a system command. So, as a friend realized, > you > > could send someone a document that did something nasty, like erase all > their > > files or log them off (or send the CEO a message saying "You're a "), > > simply by reading it. IBM took this as a SEV1 and fixed it; decades > later, > > we've spent the last while dealing with essentially the same dumb > feechur. > > > > > > > > So over how many years, how many people saw this feature and didn't say > > "Hey, you could do Very Bad Things with that"??! Amazing. > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Phil, Sorry, I agree that the entirety of what you wrote was more balanced. I reacted (poorly) to this part: "Same with open source: using random code from an unknown author would have been unthinkable; now it's common." I don't think that this is common. Mostly projects use popular open source projects. Most of these have a history, many contributors, test suites, etc. What was shocking about the LOG4J vulnerability was that is was one of these. -- Kirk Wolf On Wed, Jan 26, 2022, at 12:34 PM, Phil Smith III wrote: > Kirk Wolf wrote: > > >Is that really what you think is going on? > >The economics of open source are about *reuse*. The overwhelming majority > of software these days is built with it for that reason. Good developers > are very careful about what open source that they use.Good companies > have policies and processes for approving any open source used internally. > What's the alternative, write everything from scratch? Surely there will > be no vulnerabilities there :-) There are complex trade-offs here that > haven't been touched as yet on ibm-main. > > > > I guess I didn't make myself clear, because what you wrote is precisely how > I think. Not sure what you took from what I wrote that was different-not > being pissy, just noting that we seem to be in violent agreement! > > > > Yes, in days of yore, you'd write it all from scratch. And I was trying to > say that that was NOT necessarily more secure: it was a different > environment, so things didn't matter as much. There weren't a million > monkeys banging on the door with typewriters. > > > > > What's shocking about the LOG4J vulnerability is that it has been a > quality component used by thousands of projects for so long (20 years?, not > sure exactly). People armed with no understanding of the vulnerability or > even Java immediately began contacting all of their software vendors, even > products that clearly don't even use java. This only made the problem > worse. > > > > Yes. I think I've noted before that the ""given enough eyeballs, all bugs > are shallow" line, while not intended as a justification for blind use of > open source, seems to have been used as such. The log4j debacle should (but > won't) convince folks that it should not be. > > > > And what may be a repeat, but something I wrote elsewhere and perhaps here: > > It's also worth noting that a feature conceptually very, very similar to the > log4j thing existed almost 40 years ago, in PROFS. DCF included a .sy > command that would execute a system command. So, as a friend realized, you > could send someone a document that did something nasty, like erase all their > files or log them off (or send the CEO a message saying "You're a "), > simply by reading it. IBM took this as a SEV1 and fixed it; decades later, > we've spent the last while dealing with essentially the same dumb feechur. > > > > So over how many years, how many people saw this feature and didn't say > "Hey, you could do Very Bad Things with that"??! Amazing. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Kirk Wolf wrote: >Is that really what you think is going on? >The economics of open source are about *reuse*. The overwhelming majority of software these days is built with it for that reason. Good developers are very careful about what open source that they use.Good companies have policies and processes for approving any open source used internally. What's the alternative, write everything from scratch? Surely there will be no vulnerabilities there :-) There are complex trade-offs here that haven't been touched as yet on ibm-main. I guess I didn't make myself clear, because what you wrote is precisely how I think. Not sure what you took from what I wrote that was different-not being pissy, just noting that we seem to be in violent agreement! Yes, in days of yore, you'd write it all from scratch. And I was trying to say that that was NOT necessarily more secure: it was a different environment, so things didn't matter as much. There weren't a million monkeys banging on the door with typewriters. > What's shocking about the LOG4J vulnerability is that it has been a quality component used by thousands of projects for so long (20 years?, not sure exactly). People armed with no understanding of the vulnerability or even Java immediately began contacting all of their software vendors, even products that clearly don't even use java. This only made the problem worse. Yes. I think I've noted before that the ""given enough eyeballs, all bugs are shallow" line, while not intended as a justification for blind use of open source, seems to have been used as such. The log4j debacle should (but won't) convince folks that it should not be. And what may be a repeat, but something I wrote elsewhere and perhaps here: It's also worth noting that a feature conceptually very, very similar to the log4j thing existed almost 40 years ago, in PROFS. DCF included a .sy command that would execute a system command. So, as a friend realized, you could send someone a document that did something nasty, like erase all their files or log them off (or send the CEO a message saying "You're a "), simply by reading it. IBM took this as a SEV1 and fixed it; decades later, we've spent the last while dealing with essentially the same dumb feechur. So over how many years, how many people saw this feature and didn't say "Hey, you could do Very Bad Things with that"??! Amazing. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On Tue, Jan 25, 2022, at 4:33 PM, Phil Smith III wrote: > > > Forty years ago, vendors barely spoke to each other; now we OEM and embed > each other's products. Same with open source: using random code from an > unknown author would have been unthinkable; now it's common. Is that really what you think is going on? The economics of open source are about *reuse*. The overwhelming majority of software these days is built with it for that reason. Good developers are very careful about what open source that they use.Good companies have policies and processes for approving any open source used internally. What's the alternative, write everything from scratch? Surely there will be no vulnerabilities there :-) There are complex trade-offs here that haven't been touched as yet on ibm-main. What's shocking about the LOG4J vulnerability is that it has been a quality component used by thousands of projects for so long (20 years?, not sure exactly). People armed with no understanding of the vulnerability or even Java immediately began contacting all of their software vendors, even products that clearly don't even use java. This only made the problem worse. Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
> Let's say that an organization wanted to prohibit open source. How would you go about it? As others have noted, this is a bigger lift than you might think. The open source revolution means that we're all dependent on it now, whether we like it or not. Your PC, phone, and car all depend on it-and so does z/OS, at least indirectly (think DNS, among other things). Forty years ago, vendors barely spoke to each other; now we OEM and embed each other's products. Same with open source: using random code from an unknown author would have been unthinkable; now it's common. This change has meant that we have systems that do things that no individual or company would have attempted (and would certainly not have succeeded at), because hey, there's a library to do that XML parsing or whatever, so we can short-circuit that whole part of the effort, yay! The downside, of course, is things like the log4j vulnerabilities. But I'd also ask how secure that fortress MVS system really was 30 years ago: were those programs all that secure? Had they been subjected to rigorous security analysis? Or was it just that it had very few users, who were connected via 3270s, and were employees who (mostly, hopefully) didn't try to find and exploit holes? If you live deep in a cave, you probably don't need to worry about burglars. I find myself very conflicted when I think about this, for all of these reasons. It's clear that the tipping point is long past, anyway. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 19/1/22 12:41 am, Kirk Wolf wrote: Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: Let's say that an organization wanted to prohibit open source. How would you go about it? Good question. First off, you won't be able to run Java. The OpenJ9 JVM and OMR JIT projects are open source and hosted on Github. Then you would have to get rid of WebSphere which is built using open source libraries. I could go on and on and on. Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
> Since I would guess that a majority of ibm-mainers would agree that > open source is confusing and dangerous, here's a question: Why? Have there been polls? Is that based on feedback from your customers? > Let's say that an organization wanted to prohibit open source. How would you > go about it? I'm not sure that it is possible on z; certainly not on z/OS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Kirk Wolf [k...@dovetail.com] Sent: Tuesday, January 18, 2022 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies http://secure-web.cisco.com/18Y18C1GjfUVpT_GNSsVukfmHVcqlHciPs9HKvLRsyUaKHPDtCnbiuO4rlCj7f2uFrCktsyQPqDGPU_HGZgF6AG1G5FlyKceDb9CoRQWJqPYFPj7GuqomGMzX0Bsuyvj-nfaXSeUpCtrzZ-5WrEVS3osnkp5IMjdFjQElWfHmjEVxt5ehnIrPHqEdBwcrHJXTL1gXOOaylnWF7JRjdOi-aOK7_Ek_JmjIZQjKoIxnKRqkGKvpWayLJmXIQjqJgDluPP0BHmAnX4QAZRSQ2XHiuS6EE34-sqVQArB4StaWkf_TEseRm698gk6i5IXXk9v1MiWUZ-Aocu_BfSdKUxVQoQ9mwgo5Qs-u5HRumaWxzsHT4bkeAM5ZRDxmicZZMI3adeyEbC1b_AGpnCp0m0TBCMOk6kBq4mQ50Q0m8u8EU0z9NfJzFnXZgatkgthli65e/http%3A%2F%2Fdovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Definitely not open source; some material on the CBT tape was object code only, although the bulk of it was always open source. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of PINION, RICHARD W. [rpin...@firsthorizon.com] Sent: Tuesday, January 18, 2022 12:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Would one consider the CBT Tape to be open source? I've used CBT programs in many places I've worked at. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Tuesday, January 18, 2022 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J [External Email. Exercise caution when clicking links or opening attachments.] Your guess is not universal. I for one embrace open source as the future for the z ecosystem. How to successfully manage that "new" environment for potentially dangerous dependencies is certainly an issue, but not an unsolvable one. Certainly I think IBM itself needs to assist to help solve such issues to maintain the z RAS level. My guess is that one cannot prohibit open source, it is far too prevalent and necessary for many if not most organizations actively using z/OS to run their business (e.g., the Apache / Tomcat web server software delivered as part of z/OS is also open source - Would you prohibit that too?). IMHO it is foolish to attempt to prohibit what you don't like or understand. Seek first to understand it and then how to manage the risks. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Tuesday, January 18, 2022 11:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
It very much depends on what software you are talking about. There was software from IBM with ghastly support. There was chargeable software from CA with appalling packaging. There was free software with excellent support. Even within a single developer it can vary widely from program to program. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Clark Morris [03b2c618bdfc-dmarc-requ...@listserv.ua.edu] Sent: Tuesday, January 18, 2022 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf wrote: > Since I would guess that a majority of ibm-mainers would agree that > open source is confusing and dangerous, here's a question: As someone who installed and modified JES2 exits from the CBT tape, modified HASP with British Rail and other contributions from the Michigan mods tapes and used another mods tape for an IEBCOPY replacement as well as being someone who contributed back to the Michigan Mods 1979 tape, the JES3 tape and the CBTTAPE, I would not call open source confusing and dangerous. Anything that is put on a system has to be maintained either in house or by some trusted party be it a vendor or an open source project. The user has to understand the supplier's notification and update process and be able to use it in their environment. There have been both open source fiascos and vendor related fiascos. Clark Morris > > > > Let's say that an organization wanted to prohibit open source. How > would you go about it? > > Kirk Wolf > Dovetailed Technologies > http://secure-web.cisco.com/1NqXtEGbELDj8GTt1o7CjZSi9c6HQpwwh3HDzNgz4ccaqyvMVE7GOxk0HV52bhVq-zmiaO67GGcctOV63GXkfa0cV7lmMYb4l8gJiVt4SdJnL2Q0M8nzomnJ1Us9ybORF4tmaegym4PQ5uQ2TlykRITm7_1mljjrwyJIv6Fz7vlSAXTC5idmBUe6T5BySSQ2Lyq8SP1H1GH4j4BSsRzZSEuEQuAvDVO_I7qh9JzlnRgX3yYvgXdvON7AKrzTfumSq_fG0Gl-Q1WI2scr9foQOa8xKL21MJqPRBL2Zcpn5HgvAQoXfpqkEBaN1TBQ4rvrHkJS0iinyPjzE6Bh03oPTnnuTiKlTvy5Enta0sQokuL0hFJvoUIzOoV7T9l84fEiZdxGgeKrtMD3ocyZ1_1eIyh0uhLigxVSAQbuKP8QwaTED7l0ZgghO_1MALPOirKyg/http%3A%2F%2Fdovetail.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On Tue, 18 Jan 2022 10:41:41 -0600, Kirk Wolf wrote: >Since I would guess that a majority of ibm-mainers would agree that open >source is confusing and dangerous, here's a question: > >Let's say that an organization wanted to prohibit open source. How would you >go about it? > >Kirk Wolf >Dovetailed Technologies >http://dovetail.com > We have all kinds of open source, including all the ports IBM has made available. It all depends on "who supports, when broken". We have nothing in Prod environment that isn't supported by someone (a vendor). Rocket Git client we pay for support through IBM, so that we can continue opening tickets through IBM portal. Other stuff like PDS, TASID, we have but we dont make available to general public. We have Dovetail's Wiki/Tomcat port for our own technical information repository, but even that is not used in any production business application capacity. A general user could download "stuff" i guess, but in the end, if my team didnt install it, then they are on their own, including answering to all the various review groups (audit, risk, infosec, etc). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Kirk, No way! This is under the title of mainframe modernisation. There are so many services that are based on open source as well as many vendor products. Open source is part of our life. Now we have to deal (and live) with it. What I am saying is that there are thousands of java jar files in USS and you don't know your risks. Just for the record, on my 2.3 system there are about 14,000 different jar files. We were able to analyze all of them and propagate it with NVD. Will run tomorrow on 2.4. I expect to see the same issues. ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Tue, Jan 18, 2022 at 6:42 PM Kirk Wolf wrote: > Since I would guess that a majority of ibm-mainers would agree that open > source is confusing and dangerous, here's a question: > > Let's say that an organization wanted to prohibit open source. How would > you go about it? > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
A lot of the discussion comes down to management of risk. 1. If we have a problem will we be able to get it fixed. 1. Check the forums and see how the product is treated 2. Are there people in the community who help out with questions 2. If we find we cannot use this product at any time 1. do we have a fall back plan? 2. What would be the cost of alternatives 3. With our existing "in house" software 1. What happens if one or more people who support it ( who know and love it), if they leave 2. Do we need to train up other people in this software. 3. Should we allocate some resource to help support the "open source" software we want to use eg 1person day a week. Most customers have different levels of risk, isolation of data, areas of responsibility and access. "Open source" is just one more factor. Colin On Tue, 18 Jan 2022 at 17:21, Clark Morris < 03b2c618bdfc-dmarc-requ...@listserv.ua.edu> wrote: > On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf wrote: > > Since I would guess that a majority of ibm-mainers would agree that > > open source is confusing and dangerous, here's a question: > As someone who installed and modified JES2 exits from the CBT tape, > modified HASP with British Rail and other contributions from the > Michigan mods tapes and used another mods tape for an IEBCOPY > replacement as well as being someone who contributed back to the > Michigan Mods 1979 tape, the JES3 tape and the CBTTAPE, I would not > call open source confusing and dangerous. Anything that is put on a > system has to be maintained either in house or by some trusted party > be it a vendor or an open source project. The user has to understand > the supplier's notification and update process and be able to use it > in their environment. There have been both open source fiascos and > vendor related fiascos. > > > Clark Morris > > > > > > > > Let's say that an organization wanted to prohibit open source. How > > would you go about it? > > > > Kirk Wolf > > Dovetailed Technologies > > http://dovetail.com > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
I'm not in that majority, but if getting rid of all things open-source became a mandate, I'd communicate to management what Stuart Holland used to tell me: First shut down things like SSH, anything that uses OpenSSL, USS programs, etc. It would be a mess. And like someone else here mentioned, there are CBT programs that many people have become to rely on, whether they realize it or not. On 1/18/2022 8:41 AM, Kirk Wolf wrote: Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf wrote: Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: As someone who installed and modified JES2 exits from the CBT tape, modified HASP with British Rail and other contributions from the Michigan mods tapes and used another mods tape for an IEBCOPY replacement as well as being someone who contributed back to the Michigan Mods 1979 tape, the JES3 tape and the CBTTAPE, I would not call open source confusing and dangerous. Anything that is put on a system has to be maintained either in house or by some trusted party be it a vendor or an open source project. The user has to understand the supplier's notification and update process and be able to use it in their environment. There have been both open source fiascos and vendor related fiascos. Clark Morris Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Would one consider the CBT Tape to be open source? I've used CBT programs in many places I've worked at. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Farley, Peter x23353 Sent: Tuesday, January 18, 2022 12:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J [External Email. Exercise caution when clicking links or opening attachments.] Your guess is not universal. I for one embrace open source as the future for the z ecosystem. How to successfully manage that "new" environment for potentially dangerous dependencies is certainly an issue, but not an unsolvable one. Certainly I think IBM itself needs to assist to help solve such issues to maintain the z RAS level. My guess is that one cannot prohibit open source, it is far too prevalent and necessary for many if not most organizations actively using z/OS to run their business (e.g., the Apache / Tomcat web server software delivered as part of z/OS is also open source - Would you prohibit that too?). IMHO it is foolish to attempt to prohibit what you don't like or understand. Seek first to understand it and then how to manage the risks. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Tuesday, January 18, 2022 11:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Confidentiality notice: This e-mail message, including any attachments, may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution, or copying of this e-mail message is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete this e-mail message from your computer. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Your guess is not universal. I for one embrace open source as the future for the z ecosystem. How to successfully manage that "new" environment for potentially dangerous dependencies is certainly an issue, but not an unsolvable one. Certainly I think IBM itself needs to assist to help solve such issues to maintain the z RAS level. My guess is that one cannot prohibit open source, it is far too prevalent and necessary for many if not most organizations actively using z/OS to run their business (e.g., the Apache / Tomcat web server software delivered as part of z/OS is also open source - Would you prohibit that too?). IMHO it is foolish to attempt to prohibit what you don't like or understand. Seek first to understand it and then how to manage the risks. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Kirk Wolf Sent: Tuesday, January 18, 2022 11:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
True, but David claims it is... *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Tue, Jan 18, 2022 at 3:52 PM Seymour J Metz wrote: > > all RSU levels are the same > > No. The HOLDDATA change multiple times between levels. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf > of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu] > Sent: Tuesday, January 18, 2022 2:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: More of LOG4J > > Thanks David, > > >1. Even if you are right about the version numbers, we still have 5 >different versions here. >2. Your claim about the sub-version is interesting. So Z/OS 2.4, just >fir example, all RSU levels are the same. I don't think so, and so do > the >NVD administrators. Read the range of the affected versions. it includes >all three levels. >3. I am sure your company does a great job with versioning. >4. The major issue with open source is that there is no formal life >cycle. Usually it is a vendor product that you need to completely > upgrade >instead of installing a PTF. See your offering such as BASH. It is >downloaded and installed. no service exists. Do you expect the user to >check every day if there is a new version? > > ITschak > > *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere > Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux > and IBM I **| * > > *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* > *Skype**: ItschakMugzach **|* *Web**: > http://secure-web.cisco.com/18jw22Iixgzti-EBXxg6vWn0F3OY5r5Gp8oO1oKVHF5_kUxYP1KB7fHFTQdXVgRIeqX1IuucbHKPxPh8qqPDIldAePAQO89Ts1FThaNo1aodm8nKlD6m8R4wK0QI6pUXAo4hOsFR815-StTt-LTTZ735ZXz_RuNKLZtfxB8QQkfnB-8g344vQzERl9qrJDSQsY90UFWKSPDnUa226Pjj1nnz32kG9-AvqTg5hQItx21pE7AUvWL1XppaTzIHS9tR0O6BXhjnPGf1R1fEJPuF7Zn1dSfoGN-qoYaUD4DCjy5bsttJT1aN9gLyUg-EhqewCDPIxtOMDjzIUmfVNpBNZjQPOCKAd5d6y42XB8tpi8FC9MAnBdaY_t315WjDsQtj7B_IBDRX60triI3xvhNq1cPstw0g1DWw2pgFBvmqIx0Or1TEUc7xrwv9zv-x0dPXR/http%3A%2F%2Fwww.Securiteam.co.il > **|* > > > > > > On Tue, Jan 18, 2022 at 4:52 AM David Crayford > wrote: > > > On 17/1/22 10:34 pm, ITschak Mugzach wrote: > > > Hi, > > > > > > We took the time to dive into the wider issue of open source and z/os. > > USS > > > is a scary jungle! > > > > Only to the ignorant. > > > > > > > > > > Without many details on the how, we discovered that on our z/os 2.3 > there > > > are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5, > 1.7.0, > > > 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8.4, 1.9.0, 1.9.2, > > 1.9.3 > > > ,1.9.4, 1.9.6 ,1.9.7, 1.9.8 used by 1000 plus jar files and sharing 4 > > CVEs. > > > > I take it you don't understand the concept of semantic versioning. Those > > are not all different versions, the last digit is the patch. We do this > > in our (mainframe) products too. > > In fact, we go further and add the Git commit hash to the version > > message so we can track the version the customer is running down to a > > line of code. > > > > Apache Ant is a build system and not part of a runtime. I don't share > > your concerns. > > > > > > > > > > Nice divers... and as others may say "What you don't know doesn't hurt > > you". > > > > > > ITschak > > > > > > ITschak Mugzach > > > *|** IronSphere Platform* *|* *Information Security Continuous > Monitoring > > > for z/OS, x/Linux & IBM I **| z/VM coming soon * > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
> all RSU levels are the same No. The HOLDDATA change multiple times between levels. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Itschak Mugzach [0305158ad67d-dmarc-requ...@listserv.ua.edu] Sent: Tuesday, January 18, 2022 2:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: More of LOG4J Thanks David, 1. Even if you are right about the version numbers, we still have 5 different versions here. 2. Your claim about the sub-version is interesting. So Z/OS 2.4, just fir example, all RSU levels are the same. I don't think so, and so do the NVD administrators. Read the range of the affected versions. it includes all three levels. 3. I am sure your company does a great job with versioning. 4. The major issue with open source is that there is no formal life cycle. Usually it is a vendor product that you need to completely upgrade instead of installing a PTF. See your offering such as BASH. It is downloaded and installed. no service exists. Do you expect the user to check every day if there is a new version? ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: http://secure-web.cisco.com/18jw22Iixgzti-EBXxg6vWn0F3OY5r5Gp8oO1oKVHF5_kUxYP1KB7fHFTQdXVgRIeqX1IuucbHKPxPh8qqPDIldAePAQO89Ts1FThaNo1aodm8nKlD6m8R4wK0QI6pUXAo4hOsFR815-StTt-LTTZ735ZXz_RuNKLZtfxB8QQkfnB-8g344vQzERl9qrJDSQsY90UFWKSPDnUa226Pjj1nnz32kG9-AvqTg5hQItx21pE7AUvWL1XppaTzIHS9tR0O6BXhjnPGf1R1fEJPuF7Zn1dSfoGN-qoYaUD4DCjy5bsttJT1aN9gLyUg-EhqewCDPIxtOMDjzIUmfVNpBNZjQPOCKAd5d6y42XB8tpi8FC9MAnBdaY_t315WjDsQtj7B_IBDRX60triI3xvhNq1cPstw0g1DWw2pgFBvmqIx0Or1TEUc7xrwv9zv-x0dPXR/http%3A%2F%2Fwww.Securiteam.co.il **|* On Tue, Jan 18, 2022 at 4:52 AM David Crayford wrote: > On 17/1/22 10:34 pm, ITschak Mugzach wrote: > > Hi, > > > > We took the time to dive into the wider issue of open source and z/os. > USS > > is a scary jungle! > > Only to the ignorant. > > > > > > Without many details on the how, we discovered that on our z/os 2.3 there > > are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5, 1.7.0, > > 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8.4, 1.9.0, 1.9.2, > 1.9.3 > > ,1.9.4, 1.9.6 ,1.9.7, 1.9.8 used by 1000 plus jar files and sharing 4 > CVEs. > > I take it you don't understand the concept of semantic versioning. Those > are not all different versions, the last digit is the patch. We do this > in our (mainframe) products too. > In fact, we go further and add the Git commit hash to the version > message so we can track the version the customer is running down to a > line of code. > > Apache Ant is a build system and not part of a runtime. I don't share > your concerns. > > > > > > Nice divers... and as others may say "What you don't know doesn't hurt > you". > > > > ITschak > > > > ITschak Mugzach > > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > > for z/OS, x/Linux & IBM I **| z/VM coming soon * > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Blessed are the innocent *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Tue, Jan 18, 2022 at 2:25 PM Raphaël Jacquot wrote: > Le 18/01/2022 à 09:09, Itschak Mugzach a écrit : > > Raphael, > > > > That's exactly my point. How do you maintain the life cycle of open > source? > > each project publishes updates, according to either > * fixed calendar > * feature based calendar > * vulnerability fixes > > > How can you explain that so many vendor products include old open source > > versions? > > You have multiple ways of handling things: > > * Those that use a set version of each library they use, includes > >* Publishing software as a docker image > > this is possibly the less evil way of doing things, as long as > the vendor actually updates the docker image regularly, whenever > a vulnerability is found > >* Fork a local copy of each library they use > > those need extra work when vulnerability fixes are announced. > > this way of doing things leads to having a number of versions of > the libraries in the system (gets confusing) > this also leads to old (vulnerable) versions being included. > said vendors should be bashed for doing things the wrong way. > > * those that use the libraries that are present in the system, whose >code properly adapts to what is available on the machine at the time > >those allow for proper system upgrades, providing proper automatic >systemwide vulnerability fixes. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Le 18/01/2022 à 09:09, Itschak Mugzach a écrit : Raphael, That's exactly my point. How do you maintain the life cycle of open source? each project publishes updates, according to either * fixed calendar * feature based calendar * vulnerability fixes How can you explain that so many vendor products include old open source versions? You have multiple ways of handling things: * Those that use a set version of each library they use, includes * Publishing software as a docker image this is possibly the less evil way of doing things, as long as the vendor actually updates the docker image regularly, whenever a vulnerability is found * Fork a local copy of each library they use those need extra work when vulnerability fixes are announced. this way of doing things leads to having a number of versions of the libraries in the system (gets confusing) this also leads to old (vulnerable) versions being included. said vendors should be bashed for doing things the wrong way. * those that use the libraries that are present in the system, whose code properly adapts to what is available on the machine at the time those allow for proper system upgrades, providing proper automatic systemwide vulnerability fixes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Raphael, That's exactly my point. How do you maintain the life cycle of open source? How can you explain that so many vendor products include old open source versions? ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Tue, Jan 18, 2022 at 10:05 AM Raphaël Jacquot wrote: > Le 18/01/2022 à 08:28, Itschak Mugzach a écrit : > > See your offering such as BASH. It is > > downloaded and installed. no service exists. Do you expect the user > to > > check every day if there is a new version? > > no, that would be the job of the site administrator > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Le 18/01/2022 à 08:28, Itschak Mugzach a écrit : See your offering such as BASH. It is downloaded and installed. no service exists. Do you expect the user to check every day if there is a new version? no, that would be the job of the site administrator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Thanks David, 1. Even if you are right about the version numbers, we still have 5 different versions here. 2. Your claim about the sub-version is interesting. So Z/OS 2.4, just fir example, all RSU levels are the same. I don't think so, and so do the NVD administrators. Read the range of the affected versions. it includes all three levels. 3. I am sure your company does a great job with versioning. 4. The major issue with open source is that there is no formal life cycle. Usually it is a vendor product that you need to completely upgrade instead of installing a PTF. See your offering such as BASH. It is downloaded and installed. no service exists. Do you expect the user to check every day if there is a new version? ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: i_mugz...@securiteam.co.il **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* On Tue, Jan 18, 2022 at 4:52 AM David Crayford wrote: > On 17/1/22 10:34 pm, ITschak Mugzach wrote: > > Hi, > > > > We took the time to dive into the wider issue of open source and z/os. > USS > > is a scary jungle! > > Only to the ignorant. > > > > > > Without many details on the how, we discovered that on our z/os 2.3 there > > are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5, 1.7.0, > > 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8.4, 1.9.0, 1.9.2, > 1.9.3 > > ,1.9.4, 1.9.6 ,1.9.7, 1.9.8 used by 1000 plus jar files and sharing 4 > CVEs. > > I take it you don't understand the concept of semantic versioning. Those > are not all different versions, the last digit is the patch. We do this > in our (mainframe) products too. > In fact, we go further and add the Git commit hash to the version > message so we can track the version the customer is running down to a > line of code. > > Apache Ant is a build system and not part of a runtime. I don't share > your concerns. > > > > > > Nice divers... and as others may say "What you don't know doesn't hurt > you". > > > > ITschak > > > > ITschak Mugzach > > *|** IronSphere Platform* *|* *Information Security Continuous Monitoring > > for z/OS, x/Linux & IBM I **| z/VM coming soon * > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
On 17/1/22 10:34 pm, ITschak Mugzach wrote: Hi, We took the time to dive into the wider issue of open source and z/os. USS is a scary jungle! Only to the ignorant. Without many details on the how, we discovered that on our z/os 2.3 there are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5, 1.7.0, 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8.4, 1.9.0, 1.9.2, 1.9.3 ,1.9.4, 1.9.6 ,1.9.7, 1.9.8 used by 1000 plus jar files and sharing 4 CVEs. I take it you don't understand the concept of semantic versioning. Those are not all different versions, the last digit is the patch. We do this in our (mainframe) products too. In fact, we go further and add the Git commit hash to the version message so we can track the version the customer is running down to a line of code. Apache Ant is a build system and not part of a runtime. I don't share your concerns. Nice divers... and as others may say "What you don't know doesn't hurt you". ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More of LOG4J
Reason to stay away from it as much as possible -Original Message- From: IBM Mainframe Discussion List On Behalf Of ITschak Mugzach Sent: Monday, January 17, 2022 8:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: More of LOG4J ** EXTERNAL EMAIL - USE CAUTION ** Hi, We took the time to dive into the wider issue of open source and z/os. USS is a scary jungle! Without many details on the how, we discovered that on our z/os 2.3 there are 19 (!) different versions of Apache Ant: 1.5.3, 1.6.2, 1.6.5, 1.7.0, 1.7.1, 1.8.0, 1.8.1, 1.8.2, 1.8.2, 1.8.2, 1.8.3 ,1.8.4, 1.9.0, 1.9.2, 1.9.3 ,1.9.4, 1.9.6 ,1.9.7, 1.9.8 used by 1000 plus jar files and sharing 4 CVEs. Nice divers... and as others may say "What you don't know doesn't hurt you". ITschak ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Continuous Monitoring for z/OS, x/Linux & IBM I **| z/VM coming soon * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
