<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 21, 2020 at 8:08 PM Bill Frantz <<a href="mailto:frantz@pwpconsult.com">frantz@pwpconsult.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/21/20 at 1:29 PM, <a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a> (Phillip <br>
Hallam-Baker) wrote:<br>
<br>
>The risk here is that someone crafts a malicious file path and sticks it<br>
>into an archive so that the files end up overwriting the system files.<br>
<br>
The decoder should not have write access to any <br>
files/directories/etc. that the user doesn't also have write <br>
access to. It is nearly impossible to make software that does <br>
its own management of these kinds of things without introducing <br>
security holes. A worked example is Postfix.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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. </div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What I ended up doing was </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Removed symbolic links and multiple links to the same file from the specification.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Default directory for unpacking single files is the directory in which the tool runs.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* 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</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* 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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">.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).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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'. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div></div></div>