> Does it really matter if an application vs z/OS has a trap door vulnerability?
Not if you don't care about security. If you care then you must investigate both. Please note that an unprivileged application can still have a dangerous back door that compromises, e.g., privacy, by giving a user authorized to access the application access more data than he is authorized to see. > In either case z/OS and the ESM's cannot function > properly when the TRAP DOOR vulnerability is exploited. It can if you don't install the broken application. > Shouldn't z/OS be able to protect itself from accidental and/or malicious > vulnerabilities? To quote Schiller, "Against stupidity the gods themselves contend in vain." The OS can prevent am unauthorized application from accessing unauthorized data or elevating its privileges; it cannot prevent the application from violating its own specifications. The OS also cannot protect against malicious modifications; it's a management responsibility to vet personnel and 3rd party providing OS changes and other privileged code. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Ray Overby <[email protected]> Sent: Thursday, May 30, 2019 7:28 AM To: [email protected] Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls In response to "An application with a trap door is an application vulnerability. If there is a trap door in z/OS itself then that's a platform vulnerability." Does it really matter if an application vs z/OS has a trap door vulnerability? In either case z/OS and the ESM's cannot function properly when the TRAP DOOR vulnerability is exploited. Shouldn't z/OS be able to protect itself from accidental and/or malicious vulnerabilities? Isn't that what a platform is supposed to do? Isn't that a requirement of a secure system? Every program in z/OS has certain rules of the road it must abide by. System level programs (PSW Key 0-7, Supervisor State, APF authorized) regardless of whether they are in z/OS or an application have additional rules they must adhere to (i.e. - they must not violate the integrity of z/OS). These rules of the road are the responsibility of and dictated by the platform. Integrity is a platform issue. One of the reason's the mainframe is the most secure-able platform is at least partially based on integrity. Integrity as implemented by the platform is why security is possible. Without platform integrity security is not possible. So all code (z/OS and application) that operates at a system level (i.e. - PSW Key 0-7, Supervisor state, APF authorized) must not violate the integrity rules. Failure of a single program regardless of whether it is part of z/OS or an application will allow a hacker to compromise that system and all data on it. In response to "I'd be willing to bet a substantial amount that the majority of penetrations in z/OS are application, configuration, personnel and process vulnerabilities rather than z/OS vulnerabilities." In terms of numbers of vulnerabilities there are fewer code based vulnerabilities (TRAP DOOR is one example of a code based vulnerabilities - there are others) vs configuration based vulnerabilities. I would point out that a hacker only needs a single TRAP DOOR vulnerability to compromise the platform regardless of how the platform is configured. So fewer code based vulnerabilities does not help. All code based vulnerabilities have to be removed from the system in order to secure the platform. On 5/29/2019 2:57 PM, Seymour J Metz wrote: >> A single TRAP DOOR code vulnerability pierces the veil of integrity and >> can be used >> to compromise the mainframe. Is this a platform weakness? > An application with a trap door is an application vulnerability. If there is > a trap door in z/OS itself then that's a platform vulnerability. I'd be > willing to bet a substantial amount that the majority of penetrations in z/OS > are application, configuration, personnel and process vulnerabilities rather > than z/OS vulnerabilities. > >> Would you say that the elimination of User Key Common storage is an >> example of a z/OS change to address a mainframe platform weakness > Partially. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > Ray Overby <[email protected]> > Sent: Wednesday, May 29, 2019 11:11 AM > To: [email protected] > Subject: Re: Fwd: Just how secure are mainframes? | Trevor Eddolls > > In response to "Mistakes, lack of time, lack of control, lack of skills. > Not a platform weakness." comment: The mainframe platform, z/OS, and > ESM's all rely on integrity to function. A single TRAP DOOR code > vulnerability pierces the veil of integrity and can be used to > compromise the mainframe. Is this a platform weakness? I think so. The > platform relies on all code it runs adhering to certain rules. z/OS > could be changed to better check and enforce those rules. > > Would you say that the elimination of User Key Common storage is an > example of a z/OS change to address a mainframe platform weakness? I > think so. > > An interesting observation. Thanks. > > On 5/29/2019 5:25 AM, R.S. wrote: >> That's classical FUD. >> Frightening people. >> "if an exploit", "if job reads you RACF db", "unintended consequences". >> What exactly hacking scenario can provide RACF db to the hacker? >> Yes, I saw APF libraries with UACC(ALTER), UID(0) as standard TSO user >> attribute, even UPDATE to RACF db. But it's problem of people. >> Mistakes, lack of time, lack of control, lack of skills. Not a >> platform weakness. >> >> It's typical that assurance/lock/gun salesmen tend to talk about >> risks, threats and dangers. They create a vision. >> My English is poor, but I can observe it for two of debaters here. >> It's visible. I don't like social engineering. >> > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
