Flaw in driver allows privilege escalation. Feedback wanted

[t-d-k]

I have noticed the FreeOTFE driver allows any app with permissions to read and write to an arbitrary position on a hardware device.

This is a security risk because it allows any program to bypass windows permissions, e.g. A user app could read from files it doesn't have permission to, or could overwrite executables that run with admin rights with malware (this may be stopped by 'Windows File Protection').

This does not directly affect the security of your containers, it means malware running on your system can gain escalated privileges. It can indirectly affect the security, e.g .malware could replace the LibreCrypt executable.

So far there are no reports of any malware doing this - LC isn't popular, so benefits from security-by-obscurity at the moment.

Analysis

The driver provides functions that allow any caller to read or write from anywhere on any hardware device.
The main reason for these functions is to allow containers to be created without admin rights. The Windows API already has calls to read and write directly to a device, but obviously these need administrator rights.

Solution

The right thing to do long term is to move the logic that creates volumes into the driver from the GUI. This would mean volumes could still be created without admin rights but arbitrary apps couldn't overwrite with arbitrary data.
The driver would have to have logic to make sure the data being accessed was inside the volume opened/created. Malicious apps could still trash your disk, by creating a volume on it.
Making this change could take a while, because I would need to write a test harness for the driver code before making major changes. It will probably be impossible to do this with formats that don't store the volume size in the header - e.g. FreeOTE and dm-crypt. Meanwhile this weakness should be fixed.

The reason for reporting this issue is to get feedback from the community on the best way to fix it in the medium term.
There are 3 options:

1. Leave as is.

Any PC with LC installed will be vulnerable to privilege escalation by any malware on it.

2. Remove the call that allows arbitrary writing from the driver, but leave the call that allows reading.

Reading and writing to file-based volumes will use the standard windows calls, which do not need admin rights. Reading is used in opening volumes, so this should remain in the driver.

This will mean that to create partition/whole disk containers of any type you will need to run LC as administrator, but you will still be able to open all containers as normal, both file and disc based. You will be able to create file-based containers without administrator rights. Malware will be able to read any data on any disc but not write to it.

3. Remove both the read and write functions from driver.

Malware will not be able to read or write except as windows permissions allow (i.e. there will be no additional weakness). Creating and opening file based volumes will be as now, but you will need will admin rights to both create and open partition based volumes.

LC explorer is not affected by this issue or any fix.

Even these 'medium term' fixes will take time, so for now be especially careful not to run untrusted programs on a machine with the LC driver installed.

[AgentOak]

Option 1 is not a solution. It is just giving up and letting the problem stick around.

I'd say go for an option 2.5. That is, remove the write call. Creating LUKS-encrypted partitions on Linux also requires superuser privileges, so most users are already used to it.

Additionally, restrict the read call in a way that the driver will refuse to perform it unless the device on which read was requested is a LibreCrypt-supported encrypted container. Checking if the first bytes of the device are a known header would suffice, no?
That'd be a start, but even to encrypted devices arbitrary read access is still a problem because the device might have previously contained an unencrypted filesystem. If you didn't fill the device with zeroes at some point inbetween, an attacker would be able to recover files.
Would limiting the range in which the read call will allow performing read operations to the first, say, 4MB of the device be an option?

[t-d-k]

LUKS and FreeOTFE containers have a distinctive header, but plain dm-crypt ones do not.
If a container partition is reused, then formatting should overwrite any header.

Yes, restricting reading to the first bytes would greatly reduce the risk, and would be OK for outer containers, but hidden containers can start anywhere inside another container.
So I could add a check that the hidden container is inside another container, that means an extra call to pass the details of the outer container in.
This would still only work if the container stores the size in the header, i.e. not dm-crypt
For FreeOTFE volumes the outer container has a size, but it's encrypted.

So this change would mean:

• You couldn't have hidden containers inside plain dm-crypt containers
• You couldn't open hidden containers inside FreeOTFE ones, unless the outer container was mounted
• It would still likely be done in 2 stages, first removing the write call, then changing the read call

[LordSandwurm]

Hallo,
solution 1 and 2 are no options. The third is the only way. Limiting the driver to read only the first MB of ther Drive is in my opinion not a good idea. You cant be shure ther is no sensitiv data behind the header. This remindes me to the heard bleed atack of ssl. Mounting Partition with Admin rights shoud be ok. Nobody shoud mount Partition on computer where he has no admin rights. So he can still use files based containers.

[AgentOak]

Nobody shoud mount Partition on computer where he has no admin rights.

Why not? Unprivileged users can also insert a usb drive and access the partitions on it. Why shouldn't they be able to do the same with an encrypted drive?

[Magissia]

The driver should check if the user is allowed to read or write on that place before doing so.
If a user doesn't have the permission to format a drive, that user should not be able to make an encrypted volume on that drive, but they could still make an encrypted containers if they have filesystem write permission.

Option 3 seems to be the most appropriate one, but may ends in being not enough for approaching perfect security.