Impact analysis: CVE-2021-37625

Background

Security issues happen, and one of them happened at Skytable last week. It began with my friend Martin writing a C# driver for Skytable. We were deep into discussing the implementation when he said that he wanted to include TLS as a part of the driver, which would obviously be an amazing thing to have.

So, we issued self-signed certificates and he started working on the TLS component for the driver (since I’m not a C# person in any way, I continued my work on the core codebase). About a while later he sent me a message and if I remember well, it said “Something really bad is happening when I try to send a TLS connection.”

I initially thought it was a Windows issue because he was using .NET on a Windows machine and we’ve had all kinds of funky issues in the past with Windows machines (especially the slow release of file locks which caused many crashes). I asked if he could reproduce it on his machine, and he could. I asked him to send over the source code which he did almost immediately.

Because I haven’t hit the ground with C# for a while, I had to set up the .NET framework on my machine and set up the breaking environment. So, the moment came – and I started the database server and then ran dotnet run – and I was wonderstruck to see the server just exiting gracefully, even without an error message!

So, this was definitely not a Windows issue – but we were doing something wrong! Now we got our hands deep into traces – to find out what exactly was happening. Looking at the first few logs, things weren’t immediately clear. So I added an extreme level of logging, even in the destructors and the start/end of function calls. This is when I discovered something funny happening – the connection loop terminated on its own! Shortly, I discovered the erroneous logic – a return that was to be ignored was being propagated resulting in erroneous control flow. So now, immediately realizing that this was a possible DoS attack vector – I quickly proceeded to treat it as per our security policy.

Impact analysis

Daniel asked me a good question – who exactly is affected by this vulnerability? Here’s the (longform) answer. Almost every application architecture has the following general layout:

Here, the clients can never have direct connection to the database servers, and this is always the correct thing to do: you never want to expose your database servers to the outside world. Even if your app and database are running on the same machine, you should always firewall your database port.

If this is your architecture, you will never be impacted by this vulnerability.

However, if your architecture involves directly exposing your database server to the world, which is generally not a need (but more of a mistake at times) – then you may be impacted by this vulnerability. At the time of discovery, the most easily exploitable method was to use the TLS component and make the client send no certificates. The other sophisticated attack was to build a specially crafted TCP packet that triggered the application layer backoff algorithm. For the purposes of brevity, we will not discuss them here.

Quick FAQ

1: So I won’t be impacted if my database servers are hidden from the outside world and only accessible to my application servers? Correct

2: Will using this exploit lead to leakage of personal data or confidential data from my database? No. This is only a DoS attack and does not involve any such exposure

Final notes

If you haven’t already, upgrade to the latest release which has this vulnerability patched (backport) or use this patch: CVE-2021-37625.patch. You can take a look at the official report on the CVE list. Finally, from our information collection and analysis, we conclude that this vulnerability has not been exploited in the wild and you can be sure that we take security issues with the highest level of priority.