Is OpenSSL_1_0_2-stable vulnerable to Windows Privilege Escalation via OPENSSLDIR?

[webaddicto]

I was reading this article:
CVE-2019-12572 PIA Windows Privilege Escalation: Malicious OpenSSL Engine

In shorts, the issue is in OPENSSLDIR that was set to /usr/local/ssl, and an attacker could place an openssl.cnf file in C:\usr\local\ssl (that is an user-writable folder) to then load a malicious DLL when the caller process calls the OpenSSL DLL. If the caller process has SYSTEM privileges, the DLL will run code with same privileges (that is definitely bad).

Using the CVE's author openssldir_check tool to check for vulnerable libeay32.dll files, I tested it with:
https://github.com/IndySockets/OpenSSL-Binaries

The above URL is recommended in the Embarcadero OpenSSL page:
https://docwiki.embarcadero.com/RADStudio/Sydney/en/OpenSSL

The libeay32.dll from openssl-1.0.2u-x64_86-win64.zip seem vulnerable:

openssldir_check v1.0 by 0xm1rch
SSLeay_version() returned OpenSSL 1.0.2u  20 Dec 2019
SSLeay_version() returned OPENSSLDIR: "/usr/local/ssl"

Instead I guess it should be like C:\Program Files\Common Files\SSL

I guess, an attacker could place a malicious openssl.conf file in C:\usr\local\ssl and load a malicious DLL.

Has someone verified if the libeay32.dll files from the IndySockets repo are vulnerable?

Thank you.

[rlebeau]

Has someone verified if the libeay32.dll files from the IndySockets repo are vulnerable?

I think you just did.

In any case, I did not compile the OpenSSL DLLs that are in Indy's repo, they were provided by someone else. I have no way to recompile them to change where OPENSSLDIR points to.

According to https://hackerone.com/reports/683318, OpenSSL 1.1.0 and 1.1.1 are also affected. But the severity of the issue has been considered low.

[webaddicto]

Since they are recommended also in the Embarcadero web page I hope someone can recompile them, many Windows applications may be using them without knowing of this possible issue.

I think this issue can have some bad severity, someone can use this vulnerability everywhere (e.g at the school/university PCs, Internet cafè, office, ...) if he has access to a computer, and can even be used as a second-stage attack to gain higher privileges once a system has been compromised with lower privileges.

I opened the discussion also here:
openssl/openssl#17151

If the binaries can't be recompiled, they can be hex-edited:

The result is this compared to untouched DLL (tested with the openssldir_check tool):

Uploaded here the hex-edited libeay32.dll files:

openssl-1.0.2u-libeay32-openssldir-test.zip

The hex-edited DLLs work fine.

But untested if OPENSSLDIR is correctly recognised as c:\windows\ssl

[webaddicto]

@rlebeau

Have performed additional testings, and the result is that the hex-edited libeay32.dll works fine and fixes the OPENSSLDIR vulnerability. I monitored the system with Process Monitor using a filter that checks the field Path for openssl.cfg:

Using the default OpenSSL 1.0.2u from Indy's OpenSSL-Binaries you can see it is vulnerable:

But with the libeay32.dll hex-edited version it is fixed:

To test it I just executed openssl.exe from command-prompt:

WARNING: can't open config file: c:\windows\ssl/openssl.cnf
OpenSSL>

So probably better to hex-edit all libeay32.dll files from Indy's OpenSSL-Binaries?

However, I created a simple Windows Service in Delphi that performs HTTP.Get() requests:

function Indy_DownloadURL(const sURL: String): BOOL;
var
  HTTP: TidHTTP;
  SSL: TIdSSLIOHandlerSocketOpenSSL;
  bException: BOOL;
  sData: String;
begin
  Result := False;
  bException := False;
  HTTP := nil;
  SSL := nil;
  HTTP := TIdHTTP.Create(nil);
  HTTP.HandleRedirects := True;
  HTTP.RedirectMaximum := 3;
  SSL := TIdSSLIOHandlerSocketOpenSSL.Create(nil);
  SSL.SSLOptions.SSLVersions := [sslvTLSv1_1, sslvTLSv1_2];
  HTTP.IOHandler := SSL;
  try
  try
  sData := HTTP.Get(sURL);
  SaveURLContentToFile(sData, RandomString(10)+'.txt');
  except
  bException := True;
  end;
  finally
  Result := (not (bException)) and (HTTP.ResponseCode = 200) and (sData <> '');
  FreeAndNil(HTTP);
  FreeAndNil(SSL);
  end;
end;

I tested it with both untouched and hex-edited libeay32.dll and I didn't see anything in Process Monitor.

Possible that with a simple HTTP.Get() use of Indy the openssl.cfg is not checked/loaded?

Because if that is the case, then no fix is needed.