freebsd bug veracrypt not able to create a basic file container volume

[justanotherscript]

Expected behavior

Changes between 1.26.7 and1.26.14 not all but to describe the error (25 August 2024) : FreeBSD: Fix privilege escalation prompts not showing up (GH #1349) Support automatic detection and mounting of ext2/3/4, exFAT, NTFS filesystems (GH #1350) Use correct Disk Utility location when "check filesystem" is ran (GH #1273)

Observed behavior

privilege escalation prompts are appearing for example when trying to create a a basic file container volume but after typing in the correct sudo password "Not enough data available" appears as error.

Steps to reproduce

creating a new veracrypt basic/ standard file container volume

Screenshots

Your Environment

Please tell us more about your environment

VeraCrypt version: veracrypt-1.26.15 (freebsd package)

Operating system and version: FreeBSD-14.1-RELEASE

System type: 64-bit amd64

[tarastella]

I wonder if I am experiencing the same issue from a different angle. I'm running under FreeBSD 14.1 with veracrypt 1.26.15 installed from ports.

If I run veracrypt as a user, both GUI or text interface, and I try to mount a volume (with the correct volume and sudo passwords), I receive the message: "Error: Not enough data available".

As an example, the command line is: veracrypt --text --load-preferences --mount /home/user/volume.dsk /home/user/Documents/volume/ '--pim=0' '--keyfiles=' '--protect-hidden=no' '--slot=1'

If I run the above command with sudo, that works perfectly, ex: sudo veracrypt --text --load-preferences --mount /home/user/volume.dsk /home/user/Documents/volume/ '--pim=0' '--keyfiles=' '--protect-hidden=no' '--slot=1'

veracrypt, under the hood, invoke sudo to process the actual mount command.

I used truss and the command that fails seems to be: sudo -S -p /usr/local/bin/veracrypt --core-service

truss trace here

With the following problem: effective uid is not 0, is /usr/local/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

I use ZFS, but the filesystem has setuid attribute activated by default

$ zfs get setuid zroot/usr
NAME       PROPERTY  VALUE   SOURCE
zroot/usr  setuid    on      default

And that is also confirmed by the fact I can run sudo in other contexts without problems. Thanks a million!

@justanotherscript can you check with truss if you have the same problem please?

P.S. Not sure mine is actually a veracrypt bug, but I can't understand what I am doing wrong.

[justanotherscript]

@tarastella thanks for the idea i tried the same as described above this time with the veracrypt gui port. And there the exact error is being shown except this time it doesnt even ask me for a sudo password like before, but just shows me the error "Not enough data available". Just to make it clear before you answered I installed veracrypt with "pkg install veracrypt" and now I also tried it with "cd /usr/ports/security/veracrypt/ && make install clean". I will also provide as above the screenshots of the behavior of the port package.

[justanotherscript]

I know FreeBSD might not be the biggest priority, but maybe you can take a look at it when you get a chance. Thank you in advance @idrassi

[tarastella]

Out of curiosity @justanotherscript, can you run through the process with sudo (if you haven't already)? Open a terminal, do "sudo veracrypt", and check if you have the same error message. Thanks

[justanotherscript]

When I ran the package the whole time as root the error doesn't occurs (but the thing here that the package seems to be a more recent version than the ports version at least in this case ). In the most recent version the error should have been fixed to escalate the privileges without the need to start it from beginning with sudo.

The screenshots are from the prebuild binary package:

![error_not_appearing_run_as_root](https://github.com/user-attachment

s/assets/85b41816-f6c6-48d7-9281-1a6a576d5b0e)

[tarastella]

As we're in the realm of curiosity, and to understand if my issue is the same as yours, can you please run this command as a user please?

truss -s 1024 -f -o vera.out veracrypt

and reproduce the error. Then attach here the vera.out. I wonder if you have the same problem when veracrypt under the hood calls sudo. Thanks

[justanotherscript]


[justanotherscript]

https://file.io/wvpMae9yr7ng

[tarastella]

Hey @justanotherscript! Thanks for sharing.

I have limited capabilities when it comes to programming, but looking at your trace, I have the feeling we share the same privilege elevation issue:

 1105: write(2,"effective uid is not 0, is /usr/local/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?",139) = 139 (0x8b)
 1106: read(0,": effective uid is not 0, is /usr/local/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?",32768) = 141 (0x8d)

I've also tried to read the source code of Veracrypt, and, with my limited knowledge, I am not totally sure that this is purely related to Veracrypt itself. It seems that the sudo suid bit is somehow ignored. In my case, I'm sure that the suid bit is working, and the filesystem has suid allowed.

I've also tried to post a message in the FreeBSD forum, but nothing so far. Honestly, I have no other means to triage this any further.

[edit] I forgot to mention that I might have tracked it down to this call of line 416: https://github.com/veracrypt/VeraCrypt/blob/3bb5184645d1279ff4b6aa14a0832f058bafa45b/src/Core/Unix/CoreService.cpp#L286

const char *args[] = { "sudo", "-S", "-p", "", appPath.c_str(), TC_CORE_SERVICE_CMDLINE_OPTION, nullptr };

[tarastella]

I might need to apologise. I found out in this post: https://superuser.com/questions/1578875/why-does-sudo-fail-with-strace

that strace is calling a variant of exec() that does not honour the suid for security reasons. I've done some experiments with truss, and it might follow the same pattern.

So, what I wrote so far, i.e., receiving the message "effective uid is not 0" from the elevation of VeraCrypt might be due to me using truss itself, and it might be unrelated to the actual issue that returns "Not enough data."

I tried to help, but I might have steered the conversation in the wrong direction. I still stand by the issue I described in my first comment.

At this point, I'm happy to follow any direction to help troubleshoot this.

[justanotherscript]

Don't worry too much you have already helped a lot and tried to find the cause. When the time comes, core developers will certainly address the issue. In any case, thank you for your time and effort.

[bugtracker2019]

Hello u 2 lonely FreeBSD-users ;)

dunno, if you're still using Veracrypt and if this is relevant to your issue: (Linux) Mint users had a problem concerning their sudo-configuration (NOPASSWD rules) as mentioned in #1473, which is fixed now (1.26.20). Maybe this can help?

[tarastella]

Hey @bugtracker2019 , thanks for sharing this and thinking about us lonely users :) I still use VeraCrypt daily, even if FreeBSD is not my daily driver. Ironically, I'm using Mint as my daily driver. Unfortunately, I don't have any NOPASSWD rules in my FreeBSD's sudoers file, and it still core dumps if I try. I'm still using the workaround of prefixing "sudo" before my veracrypt command, ex: "sudo veracrypt --text ....." Thanks anyway!

[justanotherscript]

[justanotherscript]

After pressing "Format" button after the error explained before

[justanotherscript]

Other people with debian seem to have the problem: https://sourceforge.net/p/veracrypt/tickets/491/

[bugtracker2019]

Hi there,

the error mentioned in sourceforge is different though. It says VeraCrypt::File::Write:384 and is affecting the format-option use the full available space of the disk.

Back to this issue: as I tested Veracrypt 1.26.15 & FreeBSD 14.2 some days ago, I came across the same problem you two have. Oddly though when I choosed FAT as a filesystem, the creation process worked flawlessly. But opening that container resulted in the above mentioned behaviour. Tried to build the newest version from source but couldn't get it done (missing dependencies and a lack of enthusiasm to dig deeper^^). So if you're able to build from source, I encourage you to do so. When you do, maybe it's worth to take a look at the Makefile and check, if patch-src_Makefile is still necessary.

[tarastella]

Hey @bugtracker2019!

I finally got out of bed/sofa for a nasty flu, and I have tried to overcome the same lack of enthusiasm I hit recently. Long story short, even with 1.26.20 compiled from sources on FreeBSD 14.2 I have the same behaviour.

FYI, just as we're talking between friends, you need to install wx30-gtk3-3.0.5.1 and then use /usr/local/bin/wxgtk3u-3.0-config --libs and /usr/local/bin/wxgtk3u-3.0-config --cxxflags to get the flags that are needed in the Makefile. Also, the Makefile patch does not seem necessary in my context. But this time, I enabled the debugging symbols.

My compile options were: gmake WX_CONFIG=/usr/local/bin/wxgtk3u-3.0-config DEBUGGER=1 DEBUG=1 WXSTATIC=1

Although I've no clue what I'm looking at, this is the standard "bt"

 0x000000000057163a in std::__1::vector<char, std::__1::allocator<char> >::operator[][abi:se180100](unsigned long) (
    this=0x82114c5c0, __n=0) at /usr/include/c++/v1/vector:1393
1393	  _LIBCPP_ASSERT_VALID_ELEMENT_ACCESS(__n < size(), "vector[] index out of bounds");

And this is the "bt full":

(gdb) bt full
#0  0x000000000057163a in std::__1::vector<char, std::__1::allocator<char> >::operator[][abi:se180100](unsigned long)
    (this=0x82114c5c0, __n=0) at /usr/include/c++/v1/vector:1393
#1  0x000000000066d71a in VeraCrypt::CoreService::StartElevated (request=...) at Unix/CoreService.cpp:505
        fd = 9
        forEachContainer = @0x82114c530: {_vptr$Container = 0x3b1898 <vtable for VeraCrypt::ForEach::ContainerForward<std::__1::list<int, std::__1::allocator<int> > >+16>, InnerContinue = false, InnerEndCondition = true}
        bytesRead = 0
        inPipe = std::unique_ptr<VeraCrypt::Pipe> = 0x30f168047910
        outPipe = std::unique_ptr<VeraCrypt::Pipe> = 0x30f168047920
        errPipe = {_vptr$Pipe = 0x3f80e8 <vtable for VeraCrypt::Pipe+16>, ReadFileDescriptor = 9, WriteFileDescriptor = -1}
        forkedPid = 18362
        adminPassword = std::vector of length 12 = {0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000', 0 '\000'}
        timeout = 6000
        buffer = std::vector of length 0
        errOutput = std::vector of length 0
        poller = {_vptr$Poller = 0x3d6b10 <vtable for VeraCrypt::Poller+16>, FileDescriptors = std::vector of length 2 = {7, 9}}
        status = 8
        waitRes = 555009440
        exitCode = 1
        sync = "\000\000"
#2  0x000000000066b02e in VeraCrypt::CoreService::ProcessRequests (inputFD=-1, outputFD=-1) at Unix/CoreService.cpp:123
        finally121 = {finally_arg = 0x30f16802f008}
        dismountFsRequest = 0x0
        getDeviceSectorSizeRequest = 0x1713ab3de574
        getDeviceSizeRequest = 0x82a6a1f10 <fork>
        mountRequest = 0x2e6527
        checkRequest = 0x8296f7acd
        dismountRequest = 0x0
        getHostDevicesRequest = 0x8296f74b9
        setFileOwnerRequest = 0x30f167c03008
        request = {__ptr_ = 0x30f16802f000, __cntrl_ = 0x30f1680c6e80}
        e = Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc3 in position 1: invalid continuation byte
@0x30f167c33c08: {<std::exception> = {_vptr$exception = 0xd550b87a}, <VeraCrypt::Serializable> = {_vptr$Serializable = 0x1}, Message = , Subject = ""}
        e = <error reading variable: Cannot access memory at address 0x8d00000092>
        inputStream = {__ptr_ = 0x30f1680c6d20, __cntrl_ = 0x30f1680c6d60}
        outputStream = {__ptr_ = 0x30f1680c6d80, __cntrl_ = 0x30f1680c6dc0}
        e = @0x30f167c33008: {_vptr$exception = 0xd550b87a}
#3  0x000000000066ee46 in VeraCrypt::CoreService::Start () at Unix/CoreService.cpp:388
        pid = 0
#4  0x0000000000573d67 in main (argc=1, argv=0x82114d318) at Unix/Main.cpp:65
        finally66 = {<No data fields>}
        sysPathStr = "/usr/sbin:/sbin:/usr/bin:/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/tara/bin"
        sysPath = 0x82114d727 "/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/tara/bin"
        finally70 = {<No data fields>}
        forceTextUI = false
        e = <error reading variable: Cannot access memory at address 0x0>
        e = Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0x8b in position 0: invalid start byte
Python Exception <class 'UnicodeDecodeError'>: 'utf-32-le' codec can't decode bytes in position 0-3: code point not in range(0x110000)
@0x82a6d0bc0: {<VeraCrypt::Exception> = {<std::exception> = {_vptr$exception = 0xec834853e5894855}, <VeraCrypt::Serializable> = {_vptr$Serializable = 0x744501d8b4828}, Message = , Subject = }, ErrorCode = 7349881669067260765}
        e = @0x82114d318: {_vptr$exception = 0x82114d690}

I am still trying to process the shock I felt when I read "Python Exception," which is super weird because I haven't seen any trace of Python in the code. And I am wondering why the UnicodeDecodeError! I am using LANG=C.UTF-8 and, for the sake of the test, I exported LANG=C, but I had the same problem, but with "'ascii' codec ....".

As I haven't found traces of python inside the code, I wonder if I can trust that core dump.