Very Computer

Hi, all!

z/OS V1R2.0 C/C++ User's Guide, APPENDIX1.C89.3 Options states:

<<<
In order to run an application which is link-edited with a definition side-deck,
the DLL must be made available (the definition side-deck created along with the
DLL is not needed at execution time). When the DLL resides in the HFS, it must
be in either the working directory or in a directory named on the LIBPATH
environment variable. Otherwise it must be a member of a data set in the search
order used for MVS programs.

A test indeed shows that when LIBPATH is not set, the working directory is
searched. (It is *not* searched if LIBPATH is *set*, what isn't clear from
the above. Also note that USS executables don't have a compiled-in LIBPATH.)

Searching the working directory for DLLs must be considered a security hole
even while in an environment *without* LIBPATH defined the to-be-attacked
commands will not work in the normal case, so that it is unlikely that they
are in use at all. Anyway, putting some trojan horse DLLs into /tmp and
waiting for the administrator to misspell some command looking for DLLs
has a chance to succeed.

Regards,
Hartmut

There is no security vulnerability here. All security relevant
functions such as setuid(), authenticating a user, creating a thread
with a different userid, etc. require the address space to be program
controlled. If you replace a module from a controlled library or a
program controlled HFS file with one from the current working
directory, you will lose the controlled environment and the program
will fail.
--
Ulrich Boche
IBM eServer Sales Technical Support (z/OS + e-Business Security)

Quote:> There is no security vulnerability here. All security relevant
> functions such as setuid(), authenticating a user, creating a thread
> with a different userid, etc. require the address space to be program
> controlled. If you replace a module from a controlled library or a
> program controlled HFS file with one from the current working
> directory, you will lose the controlled environment and the program
> will fail.

I don't need the security relevant functions you mention to do harm. I
would, for instance, launch an X-Windows terminal with a shell running
under the user ID of the attacked program (process) but popping up on
*my* display. Or fork a daemon process to which I can connect later to
work under the user ID of the attacked program (process). Or simply open
a socket to which I can connect while the program is running to
communicate with my trojan DLL to execute more functions in the other
user's process, that is, to invoke any system function he can, under
his credentials.

Did I get something wrong here?

Best Regards,
Hartmut