[MDEV-13696] Security flaw in MariaDB encryption Created: 2017-09-01  Updated: 2020-12-01

Status: Open
Project: MariaDB Server
Component/s: Encryption
Affects Version/s: 10.1, 10.2
Fix Version/s: 10.2

Type: Bug Priority: Major
Reporter: Sergei Glushchenko Assignee: Sergei Golubchik
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi,

I've been exploring implementation of MariaDB tablespace, binlog, etc
encryption and encryption plugins and I noticed pretty bad issue.

While encryption plugin may allow to choose or override cipher mode,
only file_key_management plugin does so (choice is CBC or CTR),
aws_key_management plugin leaves what is default. And default mode
appears to be CBC.

Here is where the issue comes. Both CBC and CTR taking IV to encrypt a
block. Their requirements for IV are different though. In particular, it
is essential for IV to be unpredictable in CBC. This however is not the
case with current implementation. IV always chosen with the same pattern
adding up space id, offset and LSN which are highly predictable.

Here is the link explaining why using predictable IV in CBC is
vulnerability
https://stackoverflow.com/questions/3008139/why-is-using-a-non-random-iv-with-cbc-mode-a-vulnerability

One of the possible ways to add randomness for IV is to encrypt it.

 Comments   
Comment by Sergei Golubchik [ 2017-09-15 ]

You're right that generally one should not use predictable IVs with CBC.

But I don't think it applies in our case, the first block of the plaintext — first 16 bytes on the page — are part of the page header and not under user control.

Having said that, I still don't see why AWS plugin couldn't support CTR. We'll do it (unless there's a good reason not to, that I'm not aware of), thanks.

Generated at Thu Feb 08 08:07:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.