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 protect keys, supervisor
state, etc., based on the contents of a register. I alerted the
vendor that using a hook such as this was not the optimal way to get
into some authorized state. Literally anyone could have
disassembled the code enough to see how to exploit the hook and get
an unauthorized program into supervisor state and key 0. The vendor
made some changes shortly thereafter and claimed that the
enhancement was now much better.
[***===>] I didn't have time to disassemble the new version and
figure out how to hack into it, but a colleague of mine did and said
it was still relatively easy to subvert. [<===***]
This vendor has many products which are typically installed in a
system all at the same time, and many of their products make use of
this program FLIH hook to do authorized things.
That is the genesis of my very strong reaction to this thread.
Certainly hooking xFLIH or SVCs or whatever is not, in and of itself,
evil. However, then using said hook to grant "your" programs
authority is where it all goes very very south! As Fairchild's
colleague demonstrates, such backdoors generally can be subverted.
That fact that "we" do not "know" that the code is still subvertable
is no excuse for inaction. The threat, as described in this thread,
is significant. Doing nothing is just burying one's head in the sand.
Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.colesoft.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
At 3/1/2012 11:52 AM, 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 courts.
I do not know who is doing this, but I believe utmost pressure must
be brought
to bear upon that vendor so that it will commit every resource to
removing the
breach from its products.
Just to clear: intercepting the FLIH does not itself constitute an
exposure and,
as far as state changes go, the checking and requirements could be complete
enough to avoid any integrity problem. For example, the methodology could be
similar to that employed by IBM's IGX00011 "magic" SVC and its
intended caller.
Unless someone can prove there really is an exposure, which to my
knowledge has
not been done, I suggest that passing such judgment is premature.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/
