> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Salz, Rich > Sent: Thursday, June 23, 2016 06:14 > To: openssl-users at openssl.org > Cc: Dominik Stra?er > Subject: Re: [openssl-users] openssl shared libs > Mirko Fit (mirko.fit at onespin.com) wrote: > > Now my company is (T) and we don't want to leak (V)'s session key. > > You may assume that our binary is protected state of the art against debugger attacks and stuff. I may assume that, but I'm pretty dubious about it. Still, let's leave that aside for these purposes. > > So the only question is if the shared openssl library makes the tool more vulnerable? That's an imprecise question. A better formulation is, "under my threat model, does static linking significantly increase the cost to an attacker, and significantly more than it increases the cost to me, and is the increase in my cost worth it, considering the value of the assets being protected?". Static and dynamic linking both make your tool "more vulnerable", for different reasons. Using OpenSSL makes your tool "more vulnerable"; not using OpenSSL makes it "more vulnerable". Anything you do makes it "more vulnerable" under some branch of the attack tree. Rich responded: > You cannot prevent someone from changing what the software that runs on > their computer. You can only make it harder. Yes, but that's axiomatically true. *All* security measures are about raising costs asymmetrically; if they're successful, they increase the cost for the attacker more than they do the cost for the defender. That's what defines a security measure. Per my previous note in this stream, "cost" has to be measured and evaluated (relative to the value of the protected assets) under a threat model to be meaningful. But the point you make here is particularly relevant in a case like this, because there's a limit to how high you can raise the attacker's cost, when you're looking at attacks against software running on equipment under the attacker's control - particularly when that equipment is a general-purpose computer (and quite possibly a VM), and not on, say, tamper-resistant hardware. (Let's just run in a VM with a hacked hypervisor that heuristically detects AES decryption and steals the decrypted data. Or better, detects RSA and steals the private key.) > Shared libraries are easier for a user to replace; static libraries are harder. Yes. So in Mirko's particular case, his threat model *does* include attackers who are hostile users, which is not the most common case for OpenSSL. Here dynamically llinking libcrypto does provide an attack branch that's relatively low-cost for the attacker. Also, if he's using libcrypto only for AES encryption (not clear from his description), many critical OpenSSL updates won't apply to him, which means some of the costs associated with static linking won't apply to him. So for this relatively uncommon case, there appears to be an economic advantage in static linking. And this gets back to the question in Mirko's original email. Most applications dynamically link OpenSSL because they have a rather different use case and thus a rather different threat model. It's not very useful to ask "why does everyone else do X?" when X doesn't apply to your situation. Except, of course, that you may learn why X doesn't apply to your situation. -- Michael Wojcik Technology Specialist, Micro Focus
