On Sat April 19 2008 05:02, Kyle Hamilton wrote: > 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. >
Static linkage is the only practical approach to this threat model - You wouldn't want your private key or plaintext leaving the memory assigned to the process (such as being written to swap or the filesystem) for fear of penetration - with the same logic - you don't want the crypto functions to exist outside of your task's memory assignment - translation: staticly link. This model also means you do need to use a paired-key encryption and/or signing on everything you dlopen/dlload - public key goes with your application, private key that creates and/or signs the plug-ins stays in your safe at the office. Now your remaining attack vector is run-time access to the memory assigned to the process - - something for which protection against has few _cross-platform_ solutions. In this situation, you have to draw the line on the various hand-springs at the point where you could offer (and win with) the defense in a liability suit of: "employed due diligence within the practical limits of the state of the art". There is no "absolute security" anywhere in the world - don't waste your time trying to invent it - decide (or have your legal department decide) what is "good enough". Mike > 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] > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
