Re: odb security exit program -- MIDRANGE-L

----- Original Message -----
From: Walden H. Leverich <WaldenL@TechSoftInc.com>

> WHAT!! <wipes incredulous look from his face>
>
> IF the vendor is accessing the 400 via ODBC they must be going
through the
> exit points, no? Doesn't IBM call the exit points from within their
> server-side code? Now, I'll admit that if you loaded server-side
code for
> this vendor then they may use a non-odbc method for accessing data,
but IF
> it gets to the 400 via ODBC is must go through the exit, no??
>

I think that Jorge may have been alluding to the fact that few of the
commercially available ODBC drivers that you can buy (IBM's Client
Access ODBC driver being the most notable exception) actually use the
IBM SQL exit point (QIBM_QZDA_SQLn).  Most of the other ODBC drivers
will use the DRDA exit point which has a different format than the one
listed below (it's part of the DDM server).  Unfortunately the DRDA
exit point does not allow you to use the scanning technique that Jorge
outlined in his CL program, because DRDA doesn't show the detail of
the SQL statements - you'll have to use some other means of securing
DRDA ODBC statements (or shut it down completely).  Look to the
Distributed Data Management Guide for how the DRDA server works.

But, - and it's worth stressing - even the non-IBM ODBC drivers have
to go through an exit point.  It's just that the exit point is
different from the one that the traditional IBM ODBC drivers use.

And while I'm at, I should also mention that the CL program Jorge
shared is a nice start, but it needs a bit more work if you want to
really secure ODBC.  This CL program only looks for SQL  record
UDATEs, INSERTs, and DELETEs - which is just part of the ODBC threat.
You also have to secure other SQL capabilities such as DROP (Delete a
table), ALTER (change the columns in a table) CALL, (a program), etc.
etc.  This program also scans only the first 512 bytes (the
QIBM_QZDA_SQL1 exit point) of the SQL string.  To really secure ODBC
and JDBC you have to scan the full 32768 byte SQL string by attaching
your exit program to the QIBM_QZDA_SQL2 exit point.  Otherwise you'll
miss any UPDATE or DELETE statement that occurs later than position
508.

And finally, because ODBC and JDBC programs are often performance
sensitive, you'll probably also want to use something other than OPM
CL because the constant opening, closing, and QCLSCAN'ing of every SQL
statement is surely going to have a noticeable performance impact.
For light ODBC, you may not care, but our experience is that your exit
programs have to perform lightning fast,or they get uninstalled real
fast :)

That's my .02  :)

jte

--
John Earl                              johnearl@powertechgroup.com
The Powertech Group          www.powertechgroup.com
Kent, Washington, USA       +1 253-872-7788