Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Rather interesting article on "hacking the mainframe" using ftp
256 views
Skip to first unread message
John McKown
May 18, 2013, 4:17:30 PM5/18/13
to
http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
basically the person must be able to ftp into a UNIX subdirectory and
to submit a job. They upload a program called "netcat" into a data set
starting with their RACF id. They then submit a job which copies the
data set into the /tmp subdirectory with a "random" name, chmod the
name to be executable, then executes does starts the netcat in the
"background" (asynchronous to the batch job) and piping to/from the
z/OS UNIX shell. The "hacker" simply connects to the port that netcat
is listening on, and presto, they have a shell on their desktop.
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
basically the person must be able to ftp into a UNIX subdirectory and
to submit a job. They upload a program called "netcat" into a data set
starting with their RACF id. They then submit a job which copies the
data set into the /tmp subdirectory with a "random" name, chmod the
name to be executable, then executes does starts the netcat in the
"background" (asynchronous to the batch job) and piping to/from the
z/OS UNIX shell. The "hacker" simply connects to the port that netcat
is listening on, and presto, they have a shell on their desktop.
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Comstock
May 18, 2013, 4:39:37 PM5/18/13
to
On 5/18/2013 2:17 PM, John McKown wrote:
> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
> basically the person must be able to ftp into a UNIX subdirectory and
> to submit a job. They upload a program called "netcat" into a data set
> starting with their RACF id. They then submit a job which copies the
> data set into the /tmp subdirectory with a "random" name, chmod the
> name to be executable, then executes does starts the netcat in the
> "background" (asynchronous to the batch job) and piping to/from the
> z/OS UNIX shell. The "hacker" simply connects to the port that netcat
> is listening on, and presto, they have a shell on their desktop.
>
>
>
_But_ the key is that the 'hacker' must already have a
> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
> basically the person must be able to ftp into a UNIX subdirectory and
> to submit a job. They upload a program called "netcat" into a data set
> starting with their RACF id. They then submit a job which copies the
> data set into the /tmp subdirectory with a "random" name, chmod the
> name to be executable, then executes does starts the netcat in the
> "background" (asynchronous to the batch job) and piping to/from the
> z/OS UNIX shell. The "hacker" simply connects to the port that netcat
> is listening on, and presto, they have a shell on their desktop.
>
>
>
RACF id; the old conudrum: you have to trust somebody
or else no work gets done; having a RACF id implies
at least some level of trust. So: an inside job when
you come down to it. And insiders, especially 'trusted'
insiders can always hack any system they're trusted on,
with enough time and cleverness.
It's the hacker from outside that is the concern.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
Ed Jaffe
May 18, 2013, 5:16:50 PM5/18/13
to
On 5/18/2013 1:17 PM, John McKown wrote:
> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
> basically the person must be able to ftp into a UNIX subdirectory and
> to submit a job. They upload a program called "netcat" into a data set
> starting with their RACF id. They then submit a job which copies the
> data set into the /tmp subdirectory with a "random" name, chmod the
> name to be executable, then executes does starts the netcat in the
> "background" (asynchronous to the batch job) and piping to/from the
> z/OS UNIX shell. The "hacker" simply connects to the port that netcat
> is listening on, and presto, they have a shell on their desktop.
netcat can be used to provide this kind of "back door" for any platform
> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
> basically the person must be able to ftp into a UNIX subdirectory and
> to submit a job. They upload a program called "netcat" into a data set
> starting with their RACF id. They then submit a job which copies the
> data set into the /tmp subdirectory with a "random" name, chmod the
> name to be executable, then executes does starts the netcat in the
> "background" (asynchronous to the batch job) and piping to/from the
> z/OS UNIX shell. The "hacker" simply connects to the port that netcat
> is listening on, and presto, they have a shell on their desktop.
that runs TCP/IP. Even without netcat, a user can share his/her
resources with others (sans password) by writing a simple "home grown"
program (even in REXX!) that listens for and services requests directed
to a given TCP/IP port.
The real question is whether there is an easy way to lock down this kind
of (mostly harmless "hacking") without disrupting normal exploitation of
TCP/IP by programs that wish to do so.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/
John McKown
May 18, 2013, 6:15:42 PM5/18/13
to
OK, this is more like an authorized system user doing something beyond what
they are really supposed to. The real crack would be unauthorized use of a
valid id & password/passphrase/cert.
I still thought it was interesting.
they are really supposed to. The real crack would be unauthorized use of a
valid id & password/passphrase/cert.
I still thought it was interesting.
Mike Schwab
May 18, 2013, 6:29:53 PM5/18/13
to
On Sat, May 18, 2013 at 5:15 PM, John McKown
<john.arch...@gmail.com> wrote:
> OK, this is more like an authorized system user doing something beyond what
> they are really supposed to. The real crack would be unauthorized use of a
> valid id & password/passphrase/cert.
>
> I still thought it was interesting.
>
I know of one case. A keylogger was installed on a PC with a 3270
<john.arch...@gmail.com> wrote:
> OK, this is more like an authorized system user doing something beyond what
> they are really supposed to. The real crack would be unauthorized use of a
> valid id & password/passphrase/cert.
>
> I still thought it was interesting.
>
emulator. The captured the userid and password and was able to ftp
away a mainframe file of few hundred hospital patients.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Schumacher, Otto
May 18, 2013, 7:25:20 PM5/18/13
to
If you think about it the hacking was on the PC. I use of a exposed userid from the PC is the error.
Regards
Otto H Schumacher
Transaction and Database Systems - CICS Specialist
U. S. Mainframe
HP Enterprise Services
Telephone +1 864 987 1417
Mobile +1 864 569 5338
Email otto.sc...@hp.com
Regards
Otto H Schumacher
Transaction and Database Systems - CICS Specialist
U. S. Mainframe
HP Enterprise Services
Telephone +1 864 987 1417
Mobile +1 864 569 5338
Email otto.sc...@hp.com
Mike Schwab
May 18, 2013, 8:38:58 PM5/18/13
to
Switch from Windows to ?
On Sat, May 18, 2013 at 6:23 PM, Schumacher, Otto
<otto.sc...@hp.com> wrote:
> If you think about it the hacking was on the PC. I use of a exposed userid from the PC is the error.
>
> Regards
> Otto H Schumacher
>
On Sat, May 18, 2013 at 6:23 PM, Schumacher, Otto
<otto.sc...@hp.com> wrote:
> If you think about it the hacking was on the PC. I use of a exposed userid from the PC is the error.
>
> Regards
> Otto H Schumacher
>
Shane Ginnane
May 18, 2013, 9:37:14 PM5/18/13
to
Probably wouldn't matter. Governments as well as companies are paying third parties for intercept software. They have even boasted of using firefox.exe as a means of entry.
See https://citizenlab.org/2013/04/for-their-eyes-only-2/
Immoral they may be, but they aren't stupid.
Shane ...
On Sat, 18 May 2013 19:38:50 -0500, Mike Schwab wrote:
>Switch from Windows to ?
>
>On Sat, May 18, 2013 at 6:23 PM, Schumacher, Otto
><otto.sc...@hp.com> wrote:
>> If you think about it the hacking was on the PC. I use of a exposed userid from the PC is the error.
See https://citizenlab.org/2013/04/for-their-eyes-only-2/
Immoral they may be, but they aren't stupid.
Shane ...
On Sat, 18 May 2013 19:38:50 -0500, Mike Schwab wrote:
>Switch from Windows to ?
>
>On Sat, May 18, 2013 at 6:23 PM, Schumacher, Otto
><otto.sc...@hp.com> wrote:
>> If you think about it the hacking was on the PC. I use of a exposed userid from the PC is the error.
Paul Gilmartin
May 19, 2013, 12:17:10 AM5/19/13
to
On Sat, 18 May 2013 15:17:22 -0500, John McKown wrote:
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
>basically the person must be able to ftp into a UNIX subdirectory and
>to submit a job. They upload a program called "netcat" into a data set
>starting with their RACF id. They then submit a job which copies the
>data set into the /tmp subdirectory with a "random" name, chmod the
>name to be executable, then executes does starts the netcat in the
>"background" (asynchronous to the batch job) and piping to/from the
>z/OS UNIX shell. The "hacker" simply connects to the port that netcat
>is listening on, and presto, they have a shell on their desktop.
>
And the batch job may be submitted via FTP; the hacker needn't have
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
>basically the person must be able to ftp into a UNIX subdirectory and
>to submit a job. They upload a program called "netcat" into a data set
>starting with their RACF id. They then submit a job which copies the
>data set into the /tmp subdirectory with a "random" name, chmod the
>name to be executable, then executes does starts the netcat in the
>"background" (asynchronous to the batch job) and piping to/from the
>z/OS UNIX shell. The "hacker" simply connects to the port that netcat
>is listening on, and presto, they have a shell on their desktop.
>
a TSO session. And it's pretty obvious that FTP submit doesn't use
TSO SUBMIT internally, so it's fairly likely that the TSO exits won't
be entered.
I was surprised when the z/OS FTP server gained the ability to deal
with named pipes -- that feels risky. I wonder who required it.
Named pipes on client -- not so bad.
Years ago in one of these fora I suggested that xterm might be used
as this article suggests netcat. That would put the server (X11) on the
desktop and the client on the z -- no need to listen on a port.
-- gil
Kirk Wolf
May 19, 2013, 10:50:42 AM5/19/13
to
I guess you could call it hacking. Or just using a wide-open system :-)
The user would need:
- network access to the FTP and listen port
- firewalls could prevent
- the TCP stack could limit (TERMINAL, SERVAUTH, etc)
- access to FTP and ability to upload an executable file
- an FTP exit could be used to prevent either
- permission to submit a job
SAF and/or a FTP exit could limit this
- job would need permission to listen on a port
- user could be prevented from running a shell
"default program" in OMVS segment
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Sat, May 18, 2013 at 3:17 PM, John McKown
<john.arch...@gmail.com>wrote:
>
The user would need:
- network access to the FTP and listen port
- firewalls could prevent
- the TCP stack could limit (TERMINAL, SERVAUTH, etc)
- access to FTP and ability to upload an executable file
- an FTP exit could be used to prevent either
- permission to submit a job
SAF and/or a FTP exit could limit this
- job would need permission to listen on a port
- user could be prevented from running a shell
"default program" in OMVS segment
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
On Sat, May 18, 2013 at 3:17 PM, John McKown
<john.arch...@gmail.com>wrote:
>
Walt Farrell
May 19, 2013, 11:40:17 AM5/19/13
to
On Sat, 18 May 2013 15:17:22 -0500, John McKown <john.arch...@GMAIL.COM> wrote:
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
>basically the person must be able to ftp into a UNIX subdirectory and
>to submit a job. They upload a program called "netcat" into a data set
>starting with their RACF id. They then submit a job which copies the
>data set into the /tmp subdirectory with a "random" name, chmod the
>name to be executable, then executes does starts the netcat in the
>"background" (asynchronous to the batch job) and piping to/from the
>z/OS UNIX shell. The "hacker" simply connects to the port that netcat
>is listening on, and presto, they have a shell on their desktop.
True, but they anything they can do using that shell they could have done directly within the batch job that they submitted. If the administrators did not want them running batch jobs, they could have prevented that quite easily.
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
>basically the person must be able to ftp into a UNIX subdirectory and
>to submit a job. They upload a program called "netcat" into a data set
>starting with their RACF id. They then submit a job which copies the
>data set into the /tmp subdirectory with a "random" name, chmod the
>name to be executable, then executes does starts the netcat in the
>"background" (asynchronous to the batch job) and piping to/from the
>z/OS UNIX shell. The "hacker" simply connects to the port that netcat
>is listening on, and presto, they have a shell on their desktop.
--
Walt
Bill Godfrey
May 19, 2013, 1:57:12 PM5/19/13
to
In the Python script that a link in that site points to, I see that one line, 525, is over 202000 bytes long, assigning a string literal about that long to a variable. I couldn't help but reflect that some text editors and viewers would have trouble with that line. Python does allow string literals to be split and continued on separate lines.
Bill
On Sat, 18 May 2013 15:17:22 -0500, John McKown wrote:
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
>basically the person must be able to ftp into a UNIX subdirectory and
>to submit a job. They upload a program called "netcat" into a data set
>starting with their RACF id. They then submit a job which copies the
>data set into the /tmp subdirectory with a "random" name, chmod the
>name to be executable, then executes does starts the netcat in the
>"background" (asynchronous to the batch job) and piping to/from the
>z/OS UNIX shell. The "hacker" simply connects to the port that netcat
>is listening on, and presto, they have a shell on their desktop.
>
>
Bill
On Sat, 18 May 2013 15:17:22 -0500, John McKown wrote:
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>
>basically the person must be able to ftp into a UNIX subdirectory and
>to submit a job. They upload a program called "netcat" into a data set
>starting with their RACF id. They then submit a job which copies the
>data set into the /tmp subdirectory with a "random" name, chmod the
>name to be executable, then executes does starts the netcat in the
>"background" (asynchronous to the batch job) and piping to/from the
>z/OS UNIX shell. The "hacker" simply connects to the port that netcat
>is listening on, and presto, they have a shell on their desktop.
>
>
Scott Ford
May 19, 2013, 6:21:46 PM5/19/13
to
I agree you need a RACF ID and password an of course a list of permits. Which as was pointed that batch submission can be prevented by the permits no being there. Secondly, I find an article of this type irresponsible.
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
Scott ford
www.identityforge.com
from my IPAD
'Infinite wisdom through infinite means'
Timothy Sipples
May 19, 2013, 11:51:52 PM5/19/13
to
>Switch from Windows to ?
Linux (e.g. Android) and iOS are increasingly popular choices.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: sip...@sg.ibm.com
Paul Gilmartin
May 20, 2013, 1:50:51 AM5/20/13
to
On Sun, 19 May 2013 18:21:38 -0400, Scott Ford wrote:
>I agree you need a RACF ID and password an of course a list of permits. Which as was pointed that batch submission can be prevented by the permits no being there. Secondly, I find an article of this type irresponsible.
>
"irresponsible" because it contains misinformation or incomplete information,
>I agree you need a RACF ID and password an of course a list of permits. Which as was pointed that batch submission can be prevented by the permits no being there. Secondly, I find an article of this type irresponsible.
>
or because it contains information you feel only you are entitled to know?
-- gil
Shmuel Metz , Seymour J.
May 20, 2013, 11:24:47 AM5/20/13
to
In
<CAAJSdjhPY1=ZVqhNrwbvdusC-ycLio...@mail.gmail.com>,
on 05/18/2013
at 03:17 PM, John McKown <john.arch...@GMAIL.COM> said:
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
Control the resources, not the tools.
>basically the person must be able to ftp into a UNIX subdirectory
>and to submit a job. They upload a program called "netcat" into a
>data set starting with their RACF id. They then submit a job which
>copies the data set into the /tmp subdirectory with a "random" name,
>chmod the name to be executable, then executes does starts the
>netcat in the "background" (asynchronous to the batch job) and
>piping to/from the z/OS UNIX shell. The "hacker" simply connects to
>the port that netcat is listening on, and presto, they have a shell
>on their desktop.
There are easier ways to get a shell on your desktop if you're allowed
to submit jobs. Where is the security breach?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
<CAAJSdjhPY1=ZVqhNrwbvdusC-ycLio...@mail.gmail.com>,
on 05/18/2013
at 03:17 PM, John McKown <john.arch...@GMAIL.COM> said:
>http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
Control the resources, not the tools.
>basically the person must be able to ftp into a UNIX subdirectory
>and to submit a job. They upload a program called "netcat" into a
>data set starting with their RACF id. They then submit a job which
>copies the data set into the /tmp subdirectory with a "random" name,
>chmod the name to be executable, then executes does starts the
>netcat in the "background" (asynchronous to the batch job) and
>piping to/from the z/OS UNIX shell. The "hacker" simply connects to
>the port that netcat is listening on, and presto, they have a shell
>on their desktop.
to submit jobs. Where is the security breach?
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Costin Enache
May 20, 2013, 3:07:17 PM5/20/13
to
Embarrassing that some actually consider that a security flaw. Except for
the title, that article does not mention any security flaws or any other
problems related to the host. The article describes some evident
functionality - how to solve a technical challenge by FTP + JCL. To consider
this a backdoor is plainly silly. Why worry? The security guys will come
with that stuff printed out and ask if we are affected or not by this
vulnerability :)
My 50c
Costin
Behalf Of John McKown
Sent: 18 May 2013 22:17
To: IBM-...@LISTSERV.UA.EDU
Subject: Rather interesting article on "hacking the mainframe" using ftp
http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-p
the title, that article does not mention any security flaws or any other
problems related to the host. The article describes some evident
functionality - how to solve a technical challenge by FTP + JCL. To consider
this a backdoor is plainly silly. Why worry? The security guys will come
with that stuff printed out and ask if we are affected or not by this
vulnerability :)
My 50c
Costin
Behalf Of John McKown
Sent: 18 May 2013 22:17
To: IBM-...@LISTSERV.UA.EDU
Subject: Rather interesting article on "hacking the mainframe" using ftp
http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-p
John McKown
May 20, 2013, 4:06:57 PM5/20/13
to
Perhaps this article is using the original meaning of "hacking", as
used now mainly by Linux people, and not "cracking" which is the
"proper" word for doing something against the law or company policy. I
usually call it doing something "cleverly off the wall".
used now mainly by Linux people, and not "cracking" which is the
"proper" word for doing something against the law or company policy. I
usually call it doing something "cleverly off the wall".
Tom Longfellow
May 20, 2013, 10:39:56 PM5/20/13
to
> "irresponsible" because it contains misinformation or incomplete
> information, or because it contains information you feel only you are
> entitled to know?
>
if they have exposed data that should not have been, or received services
that they should not have had. Nothing was hacked or cracked here, but
it seems to be the intent that they in some way 'pulled a fast one'
Can we substitute 'inaccurate' for 'irresponsible'? As in they
inaccurately think they have accomplished something they they think they
were not supposed to be allowed to do.
Actually, I kind of lost interested when they were patting themselves on
the back for decoding the mysteries of JCL. The condescension was a
little too arrogant for my taste.
With that in mind, if anyone actually does find a 'crack' that exploits
FTP, I want to hear it. If it is kept secret, it can never be proved,
disproved or corrected.
One presentation I saw online from some 'ethical' (and inept) hackers
tossed off an arrogant comment that basically they do not even test FTP
becuase it is such a well known security flaw. Of course, they did not
bother to explain the flaw. It was pretty much an arrogant dismissal of
any system ignorant enough to have an FTP server running. I feel sorry
for the people who paid for their services.
Thomas Kern
May 21, 2013, 12:03:10 AM5/21/13
to
On 05/20/2013 11:21 AM, Shmuel Metz (Seymour J.) wrote:
> In
> <CAAJSdjhPY1=ZVqhNrwbvdusC-ycLio...@mail.gmail.com>,
> on 05/18/2013
> at 03:17 PM, John McKown <john.arch...@GMAIL.COM> said:
>
>> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
> Control the resources, not the tools.
>
> In
> <CAAJSdjhPY1=ZVqhNrwbvdusC-ycLio...@mail.gmail.com>,
> on 05/18/2013
> at 03:17 PM, John McKown <john.arch...@GMAIL.COM> said:
>
>> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
> Control the resources, not the tools.
>
> There are easier ways to get a shell on your desktop if you're allowed
> to submit jobs. Where is the security breach?
The security breach is in HR for hiring someone who would do this to
> to submit jobs. Where is the security breach?
their own system, their own company, their own country.
/Tom Kern
Paul Gilmartin
May 21, 2013, 12:43:24 AM5/21/13
to
On Tue, 21 May 2013 00:03:00 -0400, Thomas Kern wrote:
>On 05/20/2013 11:21 AM, Shmuel Metz (Seymour J.) wrote:
>On 05/20/2013 11:21 AM, Shmuel Metz (Seymour J.) wrote:
>> at 03:17 PM, John McKown said:
>>
>>> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>>
>> Control the resources, not the tools.
>>
>> There are easier ways to get a shell on your desktop if you're allowed
>> to submit jobs. Where is the security breach?
>
>The security breach is in HR for hiring someone who would do this to
>their own system, their own company, their own country.
>
What "breach"!? A poorly informed hack writer in a posting to a blog (the
>>
>>> http://mainframed767.tumblr.com/post/50574743147/big-iron-back-door-maintp-part-two
>>
>> Control the resources, not the tools.
>>
>> There are easier ways to get a shell on your desktop if you're allowed
>> to submit jobs. Where is the security breach?
>
>The security breach is in HR for hiring someone who would do this to
>their own system, their own company, their own country.
>
paradigm of responsibly peer-reviewed media) carelessly referred to a
routine (but fairly uncommon) procedure as a "hack". Through the magic
of rumor, mostly in these lists, this has escalated to a threat to national
security. Give us a freaking break!
(I truly hope I'm overlooking some intended sarcasm.)
-- gil
Scott Ford
May 21, 2013, 1:03:41 AM5/21/13
to
Gil,
First of all, been around a block a few thousand times..it's irresponsible from the standpoint of publishing how to do it. I wouldn't do this or even consider doing it ...but that's me
First of all, been around a block a few thousand times..it's irresponsible from the standpoint of publishing how to do it. I wouldn't do this or even consider doing it ...but that's me
Paul Gilmartin
May 21, 2013, 9:23:01 AM5/21/13
to
On Tue, 21 May 2013 01:03:33 -0400, Scott Ford wrote:
>
>First of all, been around a block a few thousand times..it's irresponsible from the standpoint of publishing how to do it. I wouldn't do this or even consider doing it ...but that's me
>
WTF!? If there were a real threat it would be discussed by now in
>
>First of all, been around a block a few thousand times..it's irresponsible from the standpoint of publishing how to do it. I wouldn't do this or even consider doing it ...but that's me
>
responsible channels such as US-CERT or DoHS or IBM integrity
APARs. Has there been any such notification? (Of course, IBM
wouldn't discuss it -- you'd have to open an SR and be told, "Known
issue; please don't tell any one else.")
Walt Farrell has said here in this thread that the technique doesn't
enable a programmer to do anything he couldn't do directly in the
batch job. I trust his expertise; nor do I believe he's throwing up a
smoke screen (though I suspect him of doing so on a different
topic three years ago).
An analogous situation: Two weeks ago it was discussed here that
when system administrators rely on the IKJEFF10 exit to enforce
rules about batch jobs, it's ineffective; IKJEFF10 is not entered
for jobs submitted via SYSOUT=(,INTRDR) and perhaps other
channels. I consider this a due caution to system administrators
that they should not be depending on a flawed technique. Do you,
in contrast, deem it "irresponsible from the standpoint of publishing
how to do it"?
And, e.g., even IBM's very open discussion of APAR OA30897 (GIYF)
contains enough information that it it is implicitly "publishing how
to do it". I consider IBM's action in this matter highly responsible.
>Scott ford
>www.identityforge.com
>
Please don't forge my identity.
John Gilmore
May 21, 2013, 9:55:06 AM5/21/13
to
Here, as is not always my wont, I find myself in strong agreement with
Paul Gilmartin.
Security via obscurity---Let's not talk about this; it may go away;
and we certainly don't want anyone else to know about it---is a
delusionary notion in all but the very short term. (There is a case
to be made for not talking about some newly discovered security
exposure over an interval of a very few days to 1) give oneself time
to protect against it and 2) in order not actively to encourage
copycats.)
A good fix for such an exposure should be robust; if it is not it it
must be replaced; and the only way make this determination is to
observe, perhaps even encourage further assaults.
Fond wishes provide no protection. When Charles Darwin published On
the Origin of Species in 1859, the bishop of Worcester's wife was
greatly distressed. "Let us hope it is not true," she is said to have
remarked, "But if it is, let us pray that it does not become generally
known!"
John Gilmore, Ashland, MA 01721 - USA
Paul Gilmartin.
Security via obscurity---Let's not talk about this; it may go away;
and we certainly don't want anyone else to know about it---is a
delusionary notion in all but the very short term. (There is a case
to be made for not talking about some newly discovered security
exposure over an interval of a very few days to 1) give oneself time
to protect against it and 2) in order not actively to encourage
copycats.)
A good fix for such an exposure should be robust; if it is not it it
must be replaced; and the only way make this determination is to
observe, perhaps even encourage further assaults.
Fond wishes provide no protection. When Charles Darwin published On
the Origin of Species in 1859, the bishop of Worcester's wife was
greatly distressed. "Let us hope it is not true," she is said to have
remarked, "But if it is, let us pray that it does not become generally
known!"
John Gilmore, Ashland, MA 01721 - USA
John Eells
May 21, 2013, 9:56:15 AM5/21/13
to
Paul Gilmartin wrote:
> On Tue, 21 May 2013 01:03:33 -0400, Scott Ford wrote:
>>
>> First of all, been around a block a few thousand times..it's irresponsible from the standpoint of publishing how to do it. I wouldn't do this or even consider doing it ...but that's me
>>
> WTF!? If there were a real threat it would be discussed by now in
> responsible channels such as US-CERT or DoHS or IBM integrity
> APARs. Has there been any such notification? (Of course, IBM
> wouldn't discuss it -- you'd have to open an SR and be told, "Known
> issue; please don't tell any one else.")
As a rule, we do not publish information about security exposures in
> On Tue, 21 May 2013 01:03:33 -0400, Scott Ford wrote:
>>
>> First of all, been around a block a few thousand times..it's irresponsible from the standpoint of publishing how to do it. I wouldn't do this or even consider doing it ...but that's me
>>
> WTF!? If there were a real threat it would be discussed by now in
> responsible channels such as US-CERT or DoHS or IBM integrity
> APARs. Has there been any such notification? (Of course, IBM
> wouldn't discuss it -- you'd have to open an SR and be told, "Known
> issue; please don't tell any one else.")
APAR closing texts visible outside IBM or in the PTF cover letters for
integrity APARs that is taken from them.
It's my understanding that we do not share z/OS security exposure
information with CERT, so unless there is some common component involved
(e.g., a broken standard) they probably don't have the information about
how to exploit them available to publish in the first place. Also, note
that CERT is part of DoHS.
<snip>
> An analogous situation: Two weeks ago it was discussed here that
> when system administrators rely on the IKJEFF10 exit to enforce
> rules about batch jobs, it's ineffective; IKJEFF10 is not entered
> for jobs submitted via SYSOUT=(,INTRDR) and perhaps other
> channels. I consider this a due caution to system administrators
> that they should not be depending on a flawed technique. Do you,
> in contrast, deem it "irresponsible from the standpoint of publishing
> how to do it"?
much by definition it does not restrict things that might enter the
system outside TSO/E, including INTRDR and NJE. That's just how the
system works.
> And, e.g., even IBM's very open discussion of APAR OA30897 (GIYF)
> contains enough information that it it is implicitly "publishing how
> to do it". I consider IBM's action in this matter highly responsible.
in closing the hole. (It's the only such case I can recall ever seeing,
not that that means much with the state of my memory.) We didn't
exactly publish a "how to" book, nor did we identify any potentially
vulnerable programs so far as I know.
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com
Scott Ford
May 21, 2013, 9:57:44 AM5/21/13
to
Gil,
You have your opinion and I have mine. Lets leave it at that.
You have your opinion and I have mine. Lets leave it at that.
John Gilmore
May 21, 2013, 10:07:02 AM5/21/13
to
John Gilmore, Ashland, MA 01721 - USA
t.
Scott Ford
May 21, 2013, 11:05:53 AM5/21/13
to
John and Gil,
I am not trying to argue with anyone or take this personally .......
I am not trying to argue with anyone or take this personally .......
Kirk Wolf
May 21, 2013, 11:19:11 AM5/21/13
to
I don't consider the article useless.
The take away should be: if you don't lock down your FTP(only) users so
that they can't submit jobs then they might do things that you didn't
expect. Also, you should secure your system so that arbitrary jobs cannot
bind to TCP ports.
The take away should be: if you don't lock down your FTP(only) users so
that they can't submit jobs then they might do things that you didn't
expect. Also, you should secure your system so that arbitrary jobs cannot
bind to TCP ports.
Scott Ford
May 21, 2013, 11:23:27 AM5/21/13
to
Kirk,
Agreed ...firewalls can be breached too
Agreed ...firewalls can be breached too
John Gilmore
May 21, 2013, 11:31:00 AM5/21/13
to
Kirk,
You have found graces, if not perhaps saving ones. My objection to
this piece was not so much to its content, which was banal, as it was
to its title, which was misleading and, I suspect, meretricious too.
John Gilmore, Ashland, MA 01721 - USA
You have found graces, if not perhaps saving ones. My objection to
this piece was not so much to its content, which was banal, as it was
to its title, which was misleading and, I suspect, meretricious too.
John Gilmore, Ashland, MA 01721 - USA
John McKown
May 21, 2013, 11:36:35 AM5/21/13
to
The new mantra: Marketing, Marketing, Marketing has replaced the old
Location, Location, Location.
"hacking" in the title will get more hits than a title such as "A way
to use FTP to get a UNIX shell prompt on z/OS"
Location, Location, Location.
"hacking" in the title will get more hits than a title such as "A way
to use FTP to get a UNIX shell prompt on z/OS"
--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?
Maranatha! <><
John McKown
Shmuel Metz , Seymour J.
May 22, 2013, 5:13:11 AM5/22/13
to
In
<CAE1XxDF4yMWddo66fC7iuiom...@mail.gmail.com>,
on 05/21/2013
seemed obvious to me, but I'm not aware of any exploits in the wild.
>(There is a case to be made for not talking about some newly
>discovered security exposure over an interval of a very few days\
>to 1) give oneself time to protect against it and 2) in order not
>actively to encourage copycats.)
Adequate QA on the fix will take more than a few days. Once IBM makes
a gix available, it will take more than a few days for most shops to
install it.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
<CAE1XxDF4yMWddo66fC7iuiom...@mail.gmail.com>,
on 05/21/2013
at 09:54 AM, John Gilmore <jwgl...@GMAIL.COM> said:
>Security via obscurity---Let's not talk about this; it may go away;
>and we certainly don't want anyone else to know about it---is a
>delusionary notion in all but the very short term.
I once reported a security hole that had been around for decades. It
>Security via obscurity---Let's not talk about this; it may go away;
>and we certainly don't want anyone else to know about it---is a
>delusionary notion in all but the very short term.
seemed obvious to me, but I'm not aware of any exploits in the wild.
>(There is a case to be made for not talking about some newly
>discovered security exposure over an interval of a very few days\
>to 1) give oneself time to protect against it and 2) in order not
>actively to encourage copycats.)
a gix available, it will take more than a few days for most shops to
install it.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
Gerhard Postpischil
May 22, 2013, 7:32:02 AM5/22/13
to
On 5/22/2013 4:54 AM, Shmuel Metz (Seymour J.) wrote:
> Adequate QA on the fix will take more than a few days. Once IBM makes
> a gix available, it will take more than a few days for most shops to
> install it.
If this is the hole I think it is, then IBM "fixed" it incorrectly, and
> Adequate QA on the fix will take more than a few days. Once IBM makes
> a gix available, it will take more than a few days for most shops to
> install it.
it had to be reported a second time.
And in the early days IBM was sloppy - the PASSWORD SVC had an
undocumented function that never checked a passed address; at a minimum
that would allow anyone to crash the system.
Gerhard Postpischil
Bradford, Vermont
Paul Gilmartin
May 22, 2013, 8:48:46 AM5/22/13
to
On Wed, 22 May 2013 07:31:35 -0400, Gerhard Postpischil wrote:
>On 5/22/2013 4:54 AM, Shmuel Metz (Seymour J.) wrote:
>> Adequate QA on the fix will take more than a few days. Once IBM makes
>> a gix available, it will take more than a few days for most shops to
>> install it.
>
One must balance the perceived risk of a flawed fix against the
>On 5/22/2013 4:54 AM, Shmuel Metz (Seymour J.) wrote:
>> Adequate QA on the fix will take more than a few days. Once IBM makes
>> a gix available, it will take more than a few days for most shops to
>> install it.
>
threat. If the flaw is being actively exploited, the latter is quite
high.
>If this is the hole I think it is, then IBM "fixed" it incorrectly, and
>it had to be reported a second time.
>
>And in the early days IBM was sloppy - the PASSWORD SVC had an
>undocumented function that never checked a passed address; at a minimum
>that would allow anyone to crash the system.
>
password facility verified the password by CLC against the passed
address. By shifting the probe password across a page boundary
and intercepting page faults, on some models he was able to
extract a password in about a thousand probes. Unencrypted
passwords; no authority revocation on failure count. And TSO
LOGON accepted unmasked passwords.
-- gil
0 new messages