BlockchainCommons / GordianSeedTool-iOS

Cryptographic Seed Manager for iOS
Other
36 stars 8 forks source link

macOS keeps copy of printed files #179

Open ChristopherA opened 1 year ago

ChristopherA commented 1 year ago

When printing seeds or SSKR with the macOS version of SeedTool, there is a security risk to users as apparently macOS keeps a copy of all completed printed files in:

/var/spool/cups/FILENAME /Users/USERNAME/Desktop/FILENAME.pdf

…and does not delete them.

see: https://bgr.com/tech/macos-saves-a-copy-of-every-print-you-have-ever-taken-heres-how-to-find-them/

Obviously the user could

sudo rm -r /var/spool/cups

but supposedly…

sudo service cups stop
sudo service cups start

…might be safer.

Don't know if there is anything an app can do to prevent this archive.

I don't know if there is an equivalent problem with iOS.

wolfmcnally commented 1 year ago

I investigated this and here's what I discovered so far.

I am running macOS 13.3.1 (a), which includes the latest security update. Anything I say here may not apply to earlier OS versions.

First of all, access to /var/spool/cups is prohibited to users by default. As an administrator I was able to add specific read/write permissions for myself to /var/spool/cups and its two subdirectories tmp/ and cache/.

cups/ contained about 50 files with the filename cxxxxxx where xx is increasing integers. These files are all small (approx. 2K) and opening them in an editor reveals that they contain print job metadata. They may include the name of the file that was printed. The lowest-numbered of these files c00042 was created on Feb 3, 2022, so it's over a year old.

However, none of these files contain any graphic information. They are not PDFs, but some unknown binary format.

Obviously a year is a long time to keep such files around, but they represent minimal risk.

I do print jobs several times a week, but couldn't find any files that would be large enough to contain image data.

So I did a fresh print job, and two new files appeared in cups/: c00163 and d00163-001. The latter of these was 564K in size, so I copied it to a personal directory and renamed it to d00163-001.pdf. Sure enough, it is the graphic of the print job I just performed. No files of interest appeared to change in cache/ or tmp/.

However, the fact that I do several print jobs a week and could find no other d files would seem to indicate that the system rather urgently mops these up. I did a system reboot and the file was still there, so I'm not sure how long it will take for it to be removed, but given my frequency of printing, I suspect it's less than a week.

My conclusion is that if the headline "MacOS keeps a copy of every print job you've ever done", if ever true, is true no longer. It definitely keeps files around longer than the print job itself, although in directories that are not accessible without administrator privileges, and it does clean up the sensitive ones fairly quickly. There is also no reason to think that these files are backed up by Time Machine, indexed by Spotlight, or synchronized to iCloud.

The truly paranoid might want to clean up such files themselves, or simply avoid printing as a means of backup.

But I think the risk is minimal for most users as long as they're running a fairly recent OS version.

wolfmcnally commented 1 year ago

Oh: I would not recommend deleting the entire cups/ directory, as it contains the two subdirectories tmp/ and cache/. In particular, cache/ appears to contain things like printer settings and while the name cache/ suggests they could all be recreated on demand, it looks like it also might be where persistent user preferences about printing to specific printers might be stored, and hence set back to defaults if this directory is deleted.

wolfmcnally commented 1 year ago

In terms of mitigating this from within the app, there's nothing we can do directly. All we can do is warn users about it when they go to print. iOS probably has a similar cups/ directory as well, and probably has similar policies around print job retention. But to do so would require jailbreaking the device to be able to access the files; akin to invoking admin privileges on macOS, but highly inconvenient or impossible without a working jailbreak exploit.