> 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

Reply via email to