Re: [openssl-users] openssl shared libs
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Salz, Rich > Sent: Thursday, June 23, 2016 06:14 > To: openssl-users@openssl.org > Cc: Dominik Straßer > Subject: Re: [openssl-users] openssl shared libs > Mirko Fit (mirko@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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl shared libs
Look at Intel SGX, available since Skylake CPU. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Salz, Rich Sent: Thursday, June 23, 2016 08:17 To: openssl-users@openssl.org Reply To: openssl-users@openssl.org Cc: Dominik Straßer Subject: Re: [openssl-users] openssl shared libs > 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 agains debugger > attacks and stuff. > So the only question is if the shared openssl library makes the tool more > vulnerable? You cannot prevent someone from changing what the software that runs on their computer. You can only make it harder. Shared libraries are easier for a user to replace; static libraries are harder. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users smime.p7s Description: S/MIME cryptographic signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl shared libs
> 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 agains debugger > attacks and stuff. > So the only question is if the shared openssl library makes the tool more > vulnerable? You cannot prevent someone from changing what the software that runs on their computer. You can only make it harder. Shared libraries are easier for a user to replace; static libraries are harder. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl shared libs
Here's my scenario in detail: We have 3 parties: (V) Vendor of intellectual property (U) User of intellectual property (may not see the IP, but use it with some tools and see the output) (T) Tool provider (may decipher the IP and use it, but not show it to (U)) According to IEEE-1735 we do the following: The (V) creates a session key and encrypts it's intellectual property using AES-256. Then he encrypts the session key using RSA-4096 and the public key of (T). So (T) should be able to decipher the session key and thus the IP. Now (T) burns his private key into his tool to his customer (U) to use all IP that some vendor (V) encrypted for the use with (T)'s tools. The critical scenario is the following: Assume (U) is the bad guy, who is interested in the intellectual property. He could replace the openssl shared libs to intercept the call to |AES_set_encrypt_key(..)| and steal the session key. With this key he and everyone he shares the key with can decipher the IP of (V). 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 agains debugger attacks and stuff. So the only question is if the shared openssl library makes the tool more vulnerable? Thanks in advance, Mirko Am 20.06.2016 um 18:04 schrieb Michael Wojcik: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Mirko Fit Sent: Monday, June 20, 2016 09:36 To: openssl-users@openssl.org Subject: Re: [openssl-users] openssl shared libs I meant the easy way of replacing a shared lib (no need to be root): > LD_LIBRARY_PATH=/path/to/modified/shared/lib:$LD_LIBRARY_PATH > my_tool What's the attack tree look like for this case, under your threat model? Here you're talking about users running "my_tool" and subverting their own security. They already could run my_tool under a debugger and intercept keys and so on. And what "passwords" (per your initial email) are being handled by my_tool that the user doesn't know about? Are they hard-coded in the my_tool binary? That said, there *are* possible attacks here. For example, an attacker might use social engineering to get a user to run my_tool with subverted shared libraries; essentially that's a side-loading attack. But it needn't be the OpenSSL libraries, because once the application is running malicious code, all bets are off. (Subverting OpenSSL would be convenient for stealing TLS credentials, but it's not necessary.) Or an attacker might gain access to a user account and set LD_LIBRARY_PATH, LD_PRELOAD, etc in the user's environment and wait for the user to run my_tool. But these considerations don't suffice to create a coherent security policy. You need a threat model so that you can evaluate the economics. What are the vulnerabilities under your model created by dynamic loading, and what do they cost? What are the vulnerabilities created by static linking (Ken Goldman rightly mentions the difficulty of picking up security updates, for example), and what do they cost? If you don't have the resources to create a proper threat model and produce usable cost estimates, then you have to use heuristics. And the heuristic most widely followed in this case is "link the OpenSSL shared objects". -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl shared libs
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Mirko Fit > Sent: Monday, June 20, 2016 09:36 > To: openssl-users@openssl.org > Subject: Re: [openssl-users] openssl shared libs > > I meant the easy way of replacing a shared lib (no need to be root): > > LD_LIBRARY_PATH=/path/to/modified/shared/lib:$LD_LIBRARY_PATH > > my_tool What's the attack tree look like for this case, under your threat model? Here you're talking about users running "my_tool" and subverting their own security. They already could run my_tool under a debugger and intercept keys and so on. And what "passwords" (per your initial email) are being handled by my_tool that the user doesn't know about? Are they hard-coded in the my_tool binary? That said, there *are* possible attacks here. For example, an attacker might use social engineering to get a user to run my_tool with subverted shared libraries; essentially that's a side-loading attack. But it needn't be the OpenSSL libraries, because once the application is running malicious code, all bets are off. (Subverting OpenSSL would be convenient for stealing TLS credentials, but it's not necessary.) Or an attacker might gain access to a user account and set LD_LIBRARY_PATH, LD_PRELOAD, etc in the user's environment and wait for the user to run my_tool. But these considerations don't suffice to create a coherent security policy. You need a threat model so that you can evaluate the economics. What are the vulnerabilities under your model created by dynamic loading, and what do they cost? What are the vulnerabilities created by static linking (Ken Goldman rightly mentions the difficulty of picking up security updates, for example), and what do they cost? If you don't have the resources to create a proper threat model and produce usable cost estimates, then you have to use heuristics. And the heuristic most widely followed in this case is "link the OpenSSL shared objects". -- Michael Wojcik Technology Specialist, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl shared libs
I meant the easy way of replacing a shared lib (no need to be root): > LD_LIBRARY_PATH=/path/to/modified/shared/lib:$LD_LIBRARY_PATH > my_tool Am 20.06.2016 um 17:25 schrieb Ken Goldman: Just one opinion: If your attacker can replace the libraries, they have root access. They can hook into the keyboard, replace your application, etc. If they have root access, you've already lost. OTOH, static link means that your application won't automatically get security updates. On 6/20/2016 11:05 AM, Mirko Fit wrote: I've got some questions on the shared build of openssl. Is it safe to use the shared libraries libssl.so and libcrypto.so? Couldn't the shared libs be replaced by manipulated ones that intercept my calls and steal the passwords? I was wondering why every linux distrubutions comes with these shared libs if the scenario I described was possible. Thanks, Mirko -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl shared libs
Just one opinion: If your attacker can replace the libraries, they have root access. They can hook into the keyboard, replace your application, etc. If they have root access, you've already lost. OTOH, static link means that your application won't automatically get security updates. On 6/20/2016 11:05 AM, Mirko Fit wrote: I've got some questions on the shared build of openssl. Is it safe to use the shared libraries libssl.so and libcrypto.so? Couldn't the shared libs be replaced by manipulated ones that intercept my calls and steal the passwords? I was wondering why every linux distrubutions comes with these shared libs if the scenario I described was possible. Thanks, Mirko -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
