[openssl-dev] Changing/deleted ordinals for exported function in the Windows DLLs

[Richard Levitte]

In message <CAH8yC8kKb=7SvEs687HL-mw7cbSe+oNw9=eLd5JwX0tBxtBW4Q at mail.gmail.com> on Sun, 27 Mar 2016 06:09:39 -0400, Jeffrey Walton <noloader at gmail.com> said:

noloader> It looks like ordinals are changing and/or being removed for functions
noloader> exported by the Windows DLL. Its causing pain points for users in the
noloader> field, and it appears to be trending. Confer:
noloader> 
noloader>  * WAMP OpenSSL ordinal 372 error, http://stackoverflow.com/q/36238887
noloader>  * The Ordinal 112 could not be located in dynamic link library…,
noloader> http://stackoverflow.com/q/36163468

I sure hope noone is using OpenSSL 1.1.0 in production.  The .num
files were recreated entirely just before beta1.

So, if we assume that this is about 1.0.2, this is what I can grep:

    : ; egrep '\s(112|372)\s' util/*.num 
    util/libeay.num:BN_MONT_CTX_free                        112	EXIST::FUNCTION:
    util/libeay.num:PEM_SealInit                            372	EXIST::FUNCTION:RSA
    util/ssleay.num:SSLv23_server_method                    112	EXIST::FUNCTION:RSA
    util/ssleay.num:SSL_CONF_cmd_argv                       372	EXIST::FUNCTION:

You notice the ":RSA" at the end?  That means that if the library was
created with the 'no-rsa' config option, those locations will be empty
in the transfer table.  I can't say for sure that's the case, but it's
a possible lead to follow.

Either way, it does seem to me that someone didn't keep the OpenSSL
libraries in check, somehow.

Btw, when it comes to OpenSSL 1.1.0, the DLLs have embedded version
numbers in the file name.

noloader> I think ordinals were meant to speed up loading of shared resources in
noloader> the 16-bit Windows days. They fell out of favor circa Windows 95.
noloader> According to Jeffrey Richter and in his book Programming Applications
noloader> for Microsoft Windows, page 701 (http://www.amazon.com/dp/1572319968):
noloader> 
noloader>     The second form [of the function GetProcAddress]  ...
noloader>     [and the] pszSymbolName parameter indicates the
noloader>     ordinal number of the symbol whose address you
noloader>     want...
noloader> 
noloader>     Again, let me reiterate that Microsoft strongly
noloader>     discourages the use of ordinals.
noloader> 
noloader> Richter then goes on to discuss getting the wrong function address
noloader> because ordinals have changed.
noloader> 
noloader> It seems like the changes should have been caught in the engineering
noloader> process during QA or testing. Perhaps an explicit step should be added
noloader> to avoid the problems in the future?

Possbly.  Either way, it's a bit late in the game to make that change.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/