[Cryptography] Cryptographic archive format

Jerry Leichter leichter at lrw.com
Mon Dec 21 17:26:05 EST 2020


> So I have been compiling a list of dangerous file paths.
> 
> ~<anything>
> /<anything>
> \<anything>
> a:<anything>
> <anything>/../<anything>
> ../<anything>
> <anything>/..
> 
> Any I am missing? The plan here is to ban these for the format itself so these are prohibited on Windows and Linux and OSX.
Ah, blacklists.  Always an issue.

Concerning your list as it is so far:

- ~ isn't a feature of the file system, it's a shell expansion.  You don't need to worry about it on any system I know of - as long as you are sure you never put one of the filenames in the archive on a shell command line.  But then again, if you allow that you've opened the doors of hell anyway.
- Forbidding leading / and \ - as well as, not A:<anything> but likely
<anything>:<anything> - just says "relative paths only".
- Yes, you need to forbid upward traversals - i.e., the ".." rules.
- You should probably forbid following soft links when restoring.  There are ways to trick people into creating a soft link to a sensitive directory, and then (perhaps much) later getting them to open an archive that uses that link.
- But ... I can do a lot of mischief by simply overwriting .login or .bash or many other such files.  Only works when unarchiving in the login directory - but (a) that's likely pretty common; (b) there may be similar "hazardous" files that appear elsewhere, though they are less common.
- Consider forbidding the creation files marked executable.  Many people include "." in their PATH - and even if they don't there are likely some common places where executables live (e.g., in ~/bin).

I'm sure with some thought one can find other attacks - especially when you want to support a variety of OS's each with their own quirks.  This is why blacklists are always so problematic.

Jon Callas's suggestion of always forcing the creation of a subdirectory and then unarchiving into it simplifies things considerably.  Perhaps less convenient, but safer.  And if you make it a chroot jail, the OS will enforce the inability to escape and you don't need to worry about .. in paths or all kinds of other stuff.  But I don't know what the analogue would be in Windows.

                                                        -- Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20201221/763d6bc2/attachment.htm>


More information about the cryptography mailing list