invalid next size (fast)

Question

invalid next size (fast)

rocketraman opened this issue 4 years ago · 10 comments

[root@edison ~]# zuluCrypt-cli -O -d /dev/sdg1
Enter passphrase: 
SUCCESS: plain volume opened successfully
free(): invalid next size (fast)
Aborted (core dumped)

When I use the zuluCrypt GUI it mounts the volume correctly, but I'm trying to create a script that opens the volume but does not mount it, as I would like to run some block level checks before mounting (like blkid and ntfsresize -fi).

The command above leaves a devicemapper value (dmsetup ls) shows the zuluCrypt dm. However, it doesn't seem to be usable.

# dmsetup ls --target=crypt
zuluCrypt-0-NAAN-sdg1-4214101330        (253, 11)

# losetup -f
/dev/loop18

# losetup /dev/loop18 /dev/mapper/zuluCrypt-0-NAAN-sdg1-4214101330

# blkid /dev/loop18
/dev/loop18: PTTYPE="atari"

which is odd -- it should show an NTFS volume.

Everything works fine if I do zuluCrypt-cli --test.

Answer 1 · 2020-06-07T09:52:01.000Z

What version of zuluCrypt are you using?

Answer 2 · 2020-06-07T14:18:26.000Z

# rpm -q --info zulucrypt
Name        : zulucrypt
Version     : 5.7.0
Release     : 1.fc31
Architecture: x86_64

Answer 3 · 2020-06-08T07:50:49.000Z

i can not reproduce the problem here

[root@twiga ink]# zuluCrypt-cli -v
zuluCrypt-cli: invalid option -- 'v'
run zuluCrypt-cli --help for help
Version  : 5.7.0
Copyright: 2011-2019 Francis Banyikwa,mhogomchungu@gmail.com
License  : GPLv2+
[root@twiga ink]# zuluCrypt-cli -O -d /dev/sdb1
Enter passphrase: 
SUCCESS: plain volume opened successfully
[root@twiga ink]# zuluCrypt-cli -q -d /dev/sdb1
SUCCESS: volume closed successfully 
[root@twiga ink]#

Will try to install fedora 31 and troubleshoot the problem.

Answer 4 · 2020-06-08T15:35:57.000Z

Is there any debugging information I can provide that may assist? The output of strace?

Answer 5 · 2020-06-08T17:37:39.000Z

The error message seems to be inconsistent, but at least on an NTFS volumes it doesn't seem to work at all when the volume is opened this way. I just tried it again now, and did not get any errors at open and close time, however, it still doesn't work properly -- blkid returns no data, and ntfs-3g is unable to mount the volume:

[root@edison ~]# zuluCrypt-cli -O -d /dev/sdg1
Enter passphrase: 
SUCCESS: plain volume opened successfully
[root@edison ~]# blkid /dev/mapper/zuluCrypt-0-NAAN-sdg1-4214101330 
[root@edison ~]# ntfs-3g /dev/mapper/zuluCrypt-0-NAAN-sdg1-4214101330 /mnt/usb -o noatime
NTFS signature is missing.
Failed to mount '/dev/mapper/zuluCrypt-0-NAAN-sdg1-4214101330': Invalid argument
The device '/dev/mapper/zuluCrypt-0-NAAN-sdg1-4214101330' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
[root@edison ~]# zuluCrypt-cli -q -d /dev/sdg1
SUCCESS: volume closed successfully

When I mount the same disk using the GUI tool, I am able to execute blkid normally, and it does mount properly.

$ sudo blkid /dev/mapper/zuluCrypt-1000-NAAN-sdg1-4214101330
/dev/mapper/zuluCrypt-1000-NAAN-sdg1-4214101330: LABEL="BOX-2" UUID="D4C03D11C03CFAF6" TYPE="ntfs" PTTYPE="atari"

Answer 6 · 2020-06-09T03:07:07.000Z

is "/dev/sdg1" using PLAIN dm-crypt type?

In zuluCrypt, click menu->zc->show debug window and then then try to unlock the volume from there and look at the debug window and post its contents.

The problem is either:

You are using a wrong password.
PLAIN dm-crypt mapper is created with wrong options.
You are trying to open the volume as a PLAIN dm-crypt volume but it is not.

Answer 7 · 2020-06-09T03:23:07.000Z

Try with below command

zuluCrypt-cli -O -d /dev/sdg1 -t plain

Answer 8 · 2020-06-09T05:36:37.000Z

is "/dev/sdg1" using PLAIN dm-crypt type?

No, its a TrueCrypt volume. Looks like adding -t tcrypt works!

In zuluCrypt, click menu->zc->show debug window and then then try to unlock the volume from there and look at the debug window and post its contents.

Here are the contents of the debug window. Interestingly, it doesn't have any -t tcrypt parameter. I've looked at this output before and if that parameter had been there, I would have seen it and not had this issue.

***************************
/usr/bin/pkexec /usr/bin/zuluPolkit /tmp/zuluCrypt-1000/zuluCrypt.polkit.socket fork
***************************
***************************
/usr/bin/zuluCrypt-cli -L
***************************
***************************
/usr/bin/zuluCrypt-cli -AZ
***************************
***************************
/usr/bin/zuluCrypt-cli -S
***************************
***************************
/usr/bin/zuluCrypt-cli -o -d "/dev/sdg1" -m "sdg1" -e rw -f "/tmp/zuluCrypt-1000/1064940559" -K 1000
***************************
***************************
/usr/bin/zuluCrypt-cli -L
***************************
***************************
xdg-open "/run/media/private/raman/sdg1"
***************************
***************************
/usr/bin/zuluCrypt-cli -q -d "/dev/sdg1" -K 1000
***************************
***************************
/usr/bin/zuluCrypt-cli -L
***************************

The problem is either:

You are trying to open the volume as a PLAIN dm-crypt volume but it is not.

Yup, looks like this was the problem. Can you explain why the debug window when the volume is opened via the GUI doesn't show the -t tcrypt parameter? Does that "/tmp/zuluCrypt-1000/1064940559" file contain something relevant?

Answer 9 · 2020-06-09T06:51:34.000Z

PLAIN dm-crypt,TrueCrypt and VeraCrypt types have no signature and you can't tell them apart when looking at a volume.
If a volume has no signature and a user did not specify the type, zuluCrypt-cli will attempt to unlock it as if it is PLAIN dm-crypt and if that fails, it attempts to unlock it as a TrueCrypt volume and then exits with an error if that fails too. It doesn't automatically try as a VeraCrypt volumes because these volumes takes waaaaaaaay too long to try. You would have seen "-t vcrypt" if you selected the volume as a VeraCrypt volume in zuluCrypt-gui.
The only way to test if a volume was PLAIN dm-crypt and was opened with correct password and correct crypto options is to check for something recognizable in the encryption mapper and zuluCrypt-cli tests it by trying to mount the file system on the encryption mapper if a volume was unlocked with "-o" option and it leaves the checking to the user if they unlock the volume using "-O" option.
Trying to unlock a VeraCrypt volume requires a user to pass "-t vcrypt" option because zuluCrypt doesn't want to guess it for reason given above, these volumes take too long to fail when they are guessed wrong.
Without the "-t" option, unlocking a volume with an unrecognizable signature using "-O" will always succeed no matter what password was used and what crypto options were used and the volume will be unlocked as a PLAIN dm-crypt. The only way to know you got it wrong is by checking for something recognizable in the encryption mapper(these mappers show up in /dev/mapper).
"/tmp/zuluCrypt-1000/1064940559" is a path to a socket file. zuluCrypt-cli requires root's privileges to run and is run from root's account but zuluCrypt-gui runs from a normal user account.
When zuluCrypt-gui starts, it checks if it can run zuluCrypt-cli from a normal account and if it can't, it starts zulupolkit using pkexec and this part is what causes the polkit prompt you see when starting zuluCrypt. zulupolkit runs privileged.
When you unlock a volume through zuluCrypt-gui, it sends the command to zuluPolkit through another socket file with a path of "/tmp/zuluCrypt-1000/zuluCrypt.polkit.socket" and zuluPolkit runs zuluCrypt-cli and zuluCrypt-cli reads the password from zuluCrypt-gui through the ""/tmp/zuluCrypt-1000/1064940559"" socket path.
Since zuluCrypt-cli is invoked by a privileged process zuluPolkit, it has no idea it is doing the work on whose behalf and zuluCrypt-gui also sets "-K 1000" to tell zuluCrypt-cli the work is for a user with a user ID of 1000.

Answer 10 · 2020-06-09T13:15:40.000Z

Thank you for the detailed explanation. I guess the only nitpicks I would have are

the documentation does not include the information for -o and -O given above in 1-5, and
the fact that the segfault was randomly occurring made me think (quite reasonably IMO) that there was an issue with the tool.

In any case, as it is now working, I'll go and and close this issue. Thanks again!