Security problem: Default permissions on ExFat volumes

DEVONthink
1

While doing some tests for indexing a database, I noticed a massive security problem:

At least on ExFat file systems, the permissions for new files look like this:

tja@mini:~$ mount | grep USBA
/dev/disk7s1 on /Volumes/USBA (exfat, local, nodev, nosuid, noowners)

tja@mini:/Volumes/USBA$ touch TESTFILE
tja@mini:/Volumes/USBA$ ls TESTFILE
-rwxrwxrwx  1 tja  staff  0 Dec 23 17:37 TESTFILE

tja@mini:/Volumes/USBA$ umask
0022

From the command line, all permissions are set, despite the umask!

And now the problem:

DEVONthink just executes any file that has executable rights (“x”) set!
Here, the file has the name “NEW”:

Example, this is a text file with the line “i am new” … nothing else.

But a double-click on this file will open a shell that executes the content:

Last login: Thu Dec 23 17:27:35 on ttys002

The default interactive shell is now zsh.

To update your account to use zsh, please run `chsh -s /bin/zsh`.

For more details, please visit https://support.apple.com/kb/HT208050.

/Volumes/SDCARD/TESTDIR/test_a/NEW ; exit;

(base) tja@mini:~$ /Volumes/SDCARD/TESTDIR/test_a/NEW ; exit;

/Volumes/SDCARD/TESTDIR/test_a/NEW: line 1: i: command not found

logout

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.

[Process completed]

That means, that at any time, a double-click on an item may run arbitrary commands!
This is sure not what is expected here!

The default option for a file should maybe be an edtior or preview, but sure not the execution!

Are there already any options to prevent this behavior, @BLUEFROG ?
If not, I would strongly ask for something that prevents this!

1 Like
2

The DT log shows events with “Unknown Format”, but still the content will be executed by a shell - and anything that either IS a shell script or could be mistaken for a shell script, will be executed!

For example, a text file with “reboot is what we need”, will just reboot the Mac.

I did not try, and it may not work for this command, as it is in /sbin/reboot which may not be part of the default PATH variable …
Also, exactly this command may need “root”, but both facts do not change the point.

3

Out of interest, why are you using an ExFAT volume?

2 Likes
4

You’re aware that ExFAT does not even know about file system permissions (obviously, given its heritage)?

Maybe reading macos - chmod'ing file on exFAT - Super User helps.

Simply use a modern filesystem, not this outdated stuff. If you insist on ExFAT, you have to live with its shortcomings.

2 Likes
5

It is the only filesystem that I can use.
It need it to be available on Windows, macOS and probably even Linux.
Also, I need files larger than 4GB.
And then the list is down to ExFat.

6

I can only use ExFat, see above.

Not ExaFat is the problem here, but the fact that DT thinks that it should just execute “executable” files on an ExFat file system - where just everything is executable.

This is not a sane and secure behavior.

I have no idea why this is fed to a shell. Is this a Mac default? Or something that DT does?
In any way, it should be prevented as it is a massive security hole.

7

You could set the noexec flag in the mint options.
I still don’t see why DT is to blame: even the shell will execute executable files. So when you have a malignant text file on an exfat drive with execute permission for everybody, you have a problem somewhere else: eventually someone will run the thing.
And this is not more of a security risk than running Scripts from inside DT or Script Editor or Numbers - do shell script is your enemy. And these scripts do not even need their exec bit set.

2 Likes
8

If i had the same concern as @tja appears to have I can only think that the only effective control measure would be to disconnect all disks. :wink:

9

I don’t know, who is to blame.

But DT should surely not just “execute” everything, jusg because it is executable.

A double click on a DT items should display the item - either internally or with an appropriate App, which should be configurable.

I cannot really understand any other behavior.

10

Without weighing in on whether or not there is a security hole, yes, that is the behaviour I would expect. I can’t test what you are describing in this thread, but it’s not completely impossible that DT is actually doing just that - namely using an app which has been associated with said files on your specific device. I would value @cgrunenberg input here. @tja what happens when you open (“double click”) the item from Finder?

2 Likes
11

Agree 10,000%.

Almost certainly this is the issue.

If you do not want .txt files to be executed with a double-click, then configure DT3 as such. Solved.

2 Likes
12

I will test this in the Finder.
But whatever the Finder is doing, it would be better to handle this more delicate in DT :wink:

13

That’s not the point.
First, those files had no name extension.
Second, it cannot be the goal that all users need to do that for every imaginable name extension.
This is a question of sane defaults :wink:

14

What can be more sane than having DT3 respond to a double-click exactly how macOS would respond in Finder or Terminal? No need to change default apps at all in most cases.

Maybe there is an issue/exception for files with no extension at all; if so, a smart rule can likely fix that and automatically add .txt as the extension.

15

As I wrote, that’s totally fine for files that belong to an App, that will then be started.

But it’s not a sane default for other files, just based on executable rights.
Should be easy to understand.

And yes, this may be a default from macOS.
Still, DT should have a way to prevent this.

16

And that’s exactly what we have here. If I create an executable file without extension, it belongs to Terminal. This is a system wide setting, and it is yours. If you do not like it, change it. If you don’t, double clicking it in the Finder will open the file with the default application, which is Terminal, and Terminal (or rather the shell) will run it.

If you set the DT preference to “open on double click”, DT will do exactly as your system wide preferences tell it to do: open the file with its default application.

If you find your own default not sane, you should definitely do something about it.

Yes, it should. Albeit, apparently it is not.

You have a way to prevent that: Mount your volume with the noexec flag. I’ve already mentioned that. In addition, you may want to dissociate executable text files from Terminal.

To summarize: All this has nothing to do with DT which behaves as designed and configured. It is a problem with a broken filesystem that is badly mounted and an insecure (read “MASSIVE security problem”) global setting on your machine.

7 Likes
17

correct assessment.

18

Oh man.

Not sure what to reply anymore.

TBH, I just expected a reply from DEVON Technologies similar to “Oh man, that’s bad. Thanks … we are going to check how we can fix the default to be more secure for all users.” … notifying @BLUEFROG for that last time.

As this is obviosly not happening, I just stop writing here.

From my perspective, it’s just unbelieble.

19

From the blog:

We are spending the holidays with our families and friends, away from our keyboards and as the pandemic allows. We do check our email and support tickets but we might reply slower than usual. We’ll all be back for you on January 10th, 2022.

A couple of things: I think that if you assume you have found a massive security risk it may be better to contact the company in question directly rather than publicly (think “responsible disclosure”). My own interpretation of what you have reported is that the risk is not as intense as you make it out to be, or is specific to the setup and behaviour rather than DT; in that regard I second @chrillek’s assessment. On the other hand, I am no security expert and am a believer in the Swiss cheese model of risk. The major questions here for me are, is there an advantage to DT ever ”running” an executable record (I am aware that strictly speaking DT is not running the executable) - i.e., are there users who use DT as a launchpad? If not, are there any negative consequences associated with DT not ever running executables when opened from the UI by the user? Again, if there are no advantages (i.e., nobody uses it) and no disadvantages (i.e., nothing gets broken) then deactivating execution would reduce potential risk without causing harm and would therefore be desirable.

I assume DEVONtech will provide their interpretation after the holidays. I would not interpret the situation as an emergency requiring interim action by DT, especially as local mitigation is feasible.

2 Likes
20

@tja - I am puzzled

Just set system preferences so that .txt files and files with no extension open with Preview or some text editor.

And set DT3 so that a double-click does not execute files in an external application

Security issue solved

Non-issue

2 Likes