openssl shared libs

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

openssl shared libs

Mirko Fit
Hi,

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
Reply | Threaded
Open this post in threaded view
|

Re: openssl shared libs

Ken Goldman-2
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
Reply | Threaded
Open this post in threaded view
|

Re: openssl shared libs

Mirko Fit
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
Reply | Threaded
Open this post in threaded view
|

Re: openssl shared libs

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Mirko Fit
> Sent: Monday, June 20, 2016 09:36
> To: [hidden email]
> 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
Reply | Threaded
Open this post in threaded view
|

Re: openssl shared libs

Mirko Fit
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 [[hidden email]] On Behalf
Of Mirko Fit
Sent: Monday, June 20, 2016 09:36
To: [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: openssl shared libs

Salz, Rich

> 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
Reply | Threaded
Open this post in threaded view
|

Re: openssl shared libs

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Mirko Fit
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: [hidden email]
Reply To: [hidden email]
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


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: openssl shared libs

Michael Wojcik
In reply to this post by Salz, Rich
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Salz, Rich
> Sent: Thursday, June 23, 2016 06:14
> To: [hidden email]
> Cc: Dominik Straßer
> Subject: Re: [openssl-users] openssl shared libs
>

Mirko Fit ([hidden email]) 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