> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Mirko Fit > Sent: Monday, June 20, 2016 09:36 > To: openssl-users at 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
