Ah. This is a bit of a quandary. But, there are a couple of options for you.
1) Do not use ld to link to libcrypto or libssl. Instead, use the ldopen() family of functions to open and bind those files yourself at runtime. 2) Use the package manager available on the system to identify what the best "system" version of openssl is, in conjunction with number 1. 3) Do not use openssl, instead use libnss (from Mozilla) or tinyssl (which is small enough to statically link) or one of the other SSL libraries out there. Again, be aware that different operating systems (MacOSX versus Linux is the one I'm most familiar with) use different names for dynamic libraries and the appropriate environment variables. Now, since it's not only OpenSSL that you must worry about if you're looking at failure of the dynamic loader security system, you have to approach this problem yourself at some point regardless. Here's some points: 1) A script executed on most UNIXes will, even if marked setuid, not be run setuid. This means that under most cases you cannot rely on the LD_LIBRARY_PATH getting stripped by running a script (except in the case of perl, which hacked in support for setuid scripts). 2) A setuid binary will not load LD_LIBRARY_PATH or its equivalents. I don't know if this applies to binaries that are setuid the current effective user ID. 3) LD_PRELOAD is, in a lot of ways, even more dangerous than LD_LIBRARY_PATH. A possible means of handling this situation would be a small setuid loader binary that would examine the current environment and construct a new one with only the appropriate variables, then execve(2) the actual binary. Since you're dealing with plug-ins, you're going to have to look at dlopen() and friends anyway. I would suggest researching all of these issues before you decide on a strategy. Each has weaknesses, each has strengths. -Kyle H On Fri, Apr 18, 2008 at 8:46 PM, Li, Yvonne <[EMAIL PROTECTED]> wrote: > You have lots of good points. Thank you again. > > I work for AOL, developing cross platform SDK for instant messaging that > supports plugins. Plugins can be malicious. And AOL is responsible for > protecting users' identity and privacy. Considering our user base, a > trojan is more likely to target our users than to protect them. > > What do the majority applications do on Unix if static linking with > openssl isn't suitable? > > > Thanks. > > Yvonne > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz > > Sent: Friday, April 18, 2008 6:29 PM > To: openssl-users@openssl.org > Subject: RE: Openssl loading > > > > > > Thanks for your response. Shipping my own version of openssl is ruled > > out. So I have to trust the system installed one. Think at least on > > some Unix systems, LD_LIBRARY_PATH is searched first. > > Right, this is beause: > > 1) A library cannot do any harm the user could not do directly. So > there's no point in preventing him from replacing system libraries. > > 2) The user may need to replace a system library for a given application > for various reasons, including if the system library has a bug that > other programs rely on. > > > I worry Trojan horses > > hidden there. I am advised to zeroing-out this env variable before > > loading openssl. > > I would not advise this. At least as likely as a trojan is that the > system-installed one has a problem and the user has installed a fixed > OpenSSL build. The trojan can just as easily intercept your programs > file operations to redirect the attempt to link to the system-installed > OpenSSL to be to a user-provided one. > > > What else I can do? > > Consider very carefully whether protecting the user from himself is > worth preventing him from protecting himself. > > It's very hard to give you advice without having any understanding of > what your threat model is. For example, if your program is designed to > protect banking transactions, that's a very different threat model from > if your program is designed to protect its own licensing. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
