2019-05-17, 17:00–17:40, Main Hall
Do you have an old proprietary piece of software, which uses weak crypto, and you can’t throw it away? Is it based on OpenSSL (very likely due to OpenSSL popularity and permissive license)? If yes, you’re in luck: you can fix your system without the need to have the source code or to mess with low-level assembly nightmare.
The world is continuously evolving and sometimes we may find ourselves in the position, when things become outdated. Cryptography is no different: while everyone should use strong crypto, in time strong crypto becomes weak due to advancements in the cryptoanalysis research as well as constant improvements of the cost and availability of compute resources.
When strong crypto becomes weak all software using it needs to be updated. But sometimes it’s hard, as often there are cases where a particular piece of software is either unmaintained or proprietary and the software vendor is not cooperative enough to do the change. And on top of that, this piece of software cannot be easily replaced for a number of reasons.
While there is no perfect solution for every case, if your old/proprietary/unmaintained software is based on OpenSSL, there may be a way to fix it. OpenSSL has a pluggable extensible architecture called “engines”, which allows you to add or replace cryptographic algorithm implementations without recompiling the whole thing. Unfortunately, however, the ability to use this functionality has to be supported by the linked application - that is, the application itself needs to have some additional code to hotswap OpenSSL engines, but most applications do not have this code.
Luckily to fix such applications we can utilize dynamic linker code preloading, a feature supported by most modern operating systems. This talks walks through a hypothetical scenario, where one needs to fix weak crypto in a proprietary tool based on OpenSSL.