On 3/2/2012 11:53 AM, David Cole wrote:
The real question is whether an unintended third party can use
the code to become authorized.
Yes. That absolutely is the "real question".
And absolutely, that is what Bill Fairchild's post asserts.
So that absolutely is why I am concerned.
While I shar
>>> This runs afoul of IBM's practice of "security through obscurity"
>>
>> That's not a practice or policy of which I am aware. Quite the
opposite.
>>
>You have a short memory, or perhaps you weren't a
>participant.
Possibly both.
If you were referring to "we're not going to explain what the int
amed
it to, "Program FLIH backdoor - This is a criminal breach of security!" Making
noise is one thing; making speculative accusations of criminal wrongdoing is
quite another. That's the stuff of lawsuits. Innocent until proven guilty is the
American way; not the other way 'ro
At 3/2/2012 10:25 AM, Edward Jaffe wrote:
On 3/2/2012 1:29 AM, David Cole wrote:
If the PFLIH hook is (as it has been described earlier in these
threads) a mechanism by which a non-authorized process can become
authorized, then its very existence is a "substantive offense" in
and of itself. It i
At 3/2/2012 10:25 AM, Edward Jaffe wrote:
On 3/2/2012 1:29 AM, David Cole
wrote:
If the PFLIH hook is (as it has
been described earlier in these threads) a mechanism by which a
non-authorized process can become authorized, then its very existence is
a "substantive offense" in and of itself. It is
Sorry about that.
The rest of the my previous post was:
. . . requires a time that is long in relationship to a human life
when used by a hacker who has access to a computer that operates at
the frequency of hard cosmic rays.
Obscurity is second best, but it is not always ill-advised.
John Gil
I am not sure that 'security through obscurity' is always a bad thing.
It is a rubric; and, as my culture hero Justice Holmes said, "We must
think things and not words".
Immediately to the point here, I know how to intercept inputs to the
z/OS FLIH, but I see no good reason to post code for doing
On Mar 2, 2012, at 05:38, Peter Relson wrote:
>> This runs afoul of IBM's practice of "security through obscurity"
>
> That's not a practice or policy of which I am aware. Quite the opposite.
>
You have a short memory, or perhaps you weren't a
participant.
On Tue, 13 Apr 2010 09:43:46 -0500, Walt
Creating intercepts for existing MVS functions as provided by IBM has
historically provided many new innovations and products. In my opinion
z/OS is a much better platform for having them. However, these
intercepts need to be designed and implemented in such a way as they do
not violate the IBM st
On 3/2/2012 1:29 AM, David Cole wrote:
If the PFLIH hook is (as it has been described earlier in these
threads) a mechanism by which a non-authorized process can become
authorized, then its very existence is a "substantive offense" in and
of itself. It is not just "a template", it doesn't just sh
>> That's not a practice or policy of which I am aware. Quite the opposite.
Does that mean that Poughkeepsie and Islandia are already
talking?
--
Martin
Pi_cap_CPU - all you ever need around MWLC/SCRT/CMT in z/VSE
more at http://www.picapcpu.de
>This runs afoul of IBM's practice of "security through obscurity"
That's not a practice or policy of which I am aware. Quite the opposite.
Peter Relson
z/OS Core Technology Design
John Gilmore wrote:
even though, as I believe, the the offender's code itself commits no
substantive offense it it is, I think, guilty of the admittedly much
subtler offense of providing a template for others, who are bent on
mischief, to use.
If the PFLIH hook is (as it has been described earl
Ed,
Let me quote to you what Bill Fairchild posted earlier on this thread:
At 2/23/2012 05:42 PM, Bill Fairchild wrote:
I found a similar (and maybe the same) vendor hook in 1996,
disassembled the code, and discovered that one of its purposes was
to put an unauthorized caller into various prote
Ed,
reading this for the fourth time:
>>I suspect the code was written long before the existence of PC routines. The
approach is clever for sure, but that in itself does not guarantee there is an
exposure.
Am I dense or did you leave out an extra "non" (or "not")
--
Martin
Pi_cap_CPU - all you
On 3/1/2012 9:23 AM, Binyamin Dissen wrote:
I would suggest by the fact that they do it in a tricky way and not in a
forthright way that there is an exposure. Otherwise why not simply use a PC?
There is no need to do this (at least since DAS) in the FLIH.
I suspect the code was written long bef
On Thu, 1 Mar 2012 08:52:45 -0800 Edward Jaffe
wrote:
:>On 3/1/2012 6:52 AM, David Cole wrote:
:>> This is not just despicable, under today's law, it is actually criminal! Any
:>> vendor who does this could be (and should be) jailed in criminal courts and
:>> sued out of existence in civil court
On 3/1/2012 6:52 AM, David Cole wrote:
This is not just despicable, under today's law, it is actually criminal! Any
vendor who does this could be (and should be) jailed in criminal courts and
sued out of existence in civil courts.
I do not know who is doing this, but I believe utmost pressure m
On Mar 1, 2012, at 07:52, David Cole wrote:
>
> It outrages me that a customer's trust would be so egregiously violated. I
> believe that it is the duty of those who do know who this vendor is to name
> it immediately.
>
This runs afoul of IBM's practice of "security through
obscurity", with whic
[Cross-posted from ASSEMBLER-LIST]
John Gilmore wrote:
For an ISV to leave such devices
in distributed code, in effect to compromise the integrity of its
customers' systems is very different; it is, at best,
despicable.
This is not just despicable, under today's law, it is actually criminal!
Any
20 matches
Mail list logo
