[Cryptography] Cryptographic archive format

[Phillip Hallam-Baker]

On Mon, Dec 21, 2020 at 8:08 PM Bill Frantz <frantz at pwpconsult.com> wrote:

> On 12/21/20 at 1:29 PM, phill at hallambaker.com (Phillip
> Hallam-Baker) wrote:
>
> >The risk here is that someone crafts a malicious file path and sticks it
> >into an archive so that the files end up overwriting the system files.
>
> The decoder should not have write access to any
> files/directories/etc. that the user doesn't also have write
> access to. It is nearly impossible to make software that does
> its own management of these kinds of things without introducing
> security holes. A worked example is Postfix.
>

The problem is that users have write access to their .ssh directory. They
could also overwrite their .mesh directory which would allow an attacker to
take control of the device.

What I ended up doing was

* Removed symbolic links and multiple links to the same file from the
specification.

* Default directory for unpacking single files is the directory in which
the tool runs.

* Default directory for unpacking archives is a new directory with the same
name as the directory that was the source directory originally archived. So
fred.march containing the files mmm/one.txt, mmm/two.txt unpacks to a
directory mmm

* When unpacking an archive, the code first obtains the DirectoryInfo
structure for the target directory, extracts the full path of the directory
and adds a directory separator. Each time a file is unpacked, the FileInfo
structure for the intended file is obtained. The unpacker then checks that
the full path specified in the FileInfo structure starts with the directory
path.

My reading of the .Net APIs is that the DirectoryInfo and FileInfo
instances return canonical paths and so this check should be sufficient to
prevent the relative path attack.

It is possible to use the scheme as a software distribution format, which
is of course one of the main things you would want to do with a one way
sequence type scheme. A single signature on the last record in the sequence
authenticating the Merkle Tree apex provides authentication for the entire
tree. Existing software distributions can be patched by simply appending
extra frames to the end of the sequence.

What I would like to eventually get to is a scheme in which an application
can download updates without asking user permission. That makes no sense.
The user has already granted permission to use disk and network resources,
it should not be necessary to ask permission to start a download.
Downloading an update doesn't mean installing it.

Installing an update simply becomes a matter of restarting the application,
it can then take all file resources from the updated frames in the
container. If the user decides that the update is undesirable, they have
the option of rolling the version back in the same way.

The format is designed to support sparse archives. So lets say that an
archive has 120 frames written to it over the course of five years but only
80 of the frames are actually active. Some files have been deleted. Some
have been updated. We might well want to purge the container to save space.
Alternatively, the software provider might have a single archive for all
the various supported platforms an intelligent downloader would know that
the Mac version does not need the Windows specific components and vice
versa. Same goes for language variants.

Using this approach for libraries might finally address the dll-hell
problem which has been around since VMS shared libraries. The core problem
is that while APIs allow source code to be library version agnostic,
compiled code is not and never can be. Application A can only be expected
to run with the same library versions used in unit testing.

.NET has strong versioning and every runtime ships with every version of
every library that was ever supported on that platform. Which is fine until
someone tries to install an application that uses a newer version of a
library than the one installed. So more recent C# applications actually
ship as archives of all the linked libraries which are unpacked before it
runs. Which is actually not such a bad solution if you have plenty of disk.
But a much better solution would be to specify the authentication policy
for each archive and allow the O/S to synchronize archives that meet that
policy (i.e. a microsoft update to the foo library will be automatically
appended to the archive provided it is signed by MrSofty but it won't
overwrite the existing library or change any behavior of the machine except
for applications compiled against that specific version).


Finally, when downloading an update and installing it on a machine, it
might well make sense to unpack payloads and store them separately. This is
similar to what ended up happening with S/MIME 'detached signatures'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210101/b87919e5/attachment.htm>