* Gordon Messmer:
> Why doesn't dlopen() solve the problem? As best I understand it,
> liblzma was able to steal one (or more) of the symbols from
> libcrypto.so.3 because it ran constructors at a point in time when the
> GOT was still writable. After loading shared objects is complete,
> that table is made read-only. If dlopen() is used after the program
> starts, then even if the library is loaded, it can't steal symbols in
> the table any more.
The rsa_pkcs1_ossl_meth variable that contains a function pointer to the
actual implementation resides in read-write memory:
static RSA_METHOD rsa_pkcs1_ossl_meth = {
"OpenSSL PKCS#1 RSA",
rsa_ossl_public_encrypt,
rsa_ossl_public_decrypt, /* signature verification */
rsa_ossl_private_encrypt, /* signing */
rsa_ossl_private_decrypt,
rsa_ossl_mod_exp,
BN_mod_exp_mont, /* XXX probably we should not use Montgomery
* if e == 3 */
rsa_ossl_init,
rsa_ossl_finish,
RSA_FLAG_FIPS_METHOD, /* flags */
NULL,
0, /* rsa_sign */
0, /* rsa_verify */
NULL, /* rsa_keygen */
NULL /* rsa_multi_prime_keygen */
};
The missing “const” keyword is probably an oversight, but I don't think
it matters because the variable is not used directly. All access
happens through deefault_RSA_meth:
static const RSA_METHOD *default_RSA_meth = &rsa_pkcs1_ossl_meth;
void RSA_set_default_method(const RSA_METHOD *meth)
{
default_RSA_meth = meth;
}
const RSA_METHOD *RSA_get_default_method(void)
{
return default_RSA_meth;
}
const RSA_METHOD *RSA_PKCS1_OpenSSL(void)
{
return &rsa_pkcs1_ossl_meth;
}
And that's clearly required to be read-write. RSA_set_default_method is
a documented interface, too. So I don't think GOT patching was required
to achieve the intended effect.
Furthermore, it's possible to undo the effect of RELRO with mprotect.
Using dlopen, liblzma would not have been loaded at run time, but it's
not clear if it had mattered because liblzma would still have been
loaded by RPM, both at build and install time.
Thanks,
Florian
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
