mirrors/tar-split
1
0
Fork 1
mirror of https://github.com/vbatts/tar-split.git synced 2024-11-15 12:58:38 +00:00
Code Releases Activity
tar-split/tar/asm
History
Aleksa Sarai 3d9db48dbe
tar: asm: store padding in chunks to avoid memory exhaustion 
Previously, we would read the entire padding in a given archive into
memory in order to store it in the packer. This would cause memory
exhaustion if a malicious archive was crafted with very large amounts of
padding. Since a given SegmentType is reconstructed losslessly, we can
simply chunk up any padding into large segments to avoid this problem.
Use a reasonable default of 1MiB to avoid changing the tar-split.json of
existing archives that are not malformed.

Fixes: CVE-2017-14992
Signed-off-by: Aleksa Sarai <asarai@suse.de>
2017-11-08 02:34:56 +11:00
..
testdata tar/asm: failing test for lack of EOF nils 2016-09-26 13:39:03 -07:00
assemble.go Optimize tar stream generation 2015-12-01 14:08:53 -08:00
assemble_test.go tar/asm: failing test for lack of EOF nils 2016-09-26 13:39:03 -07:00
disassemble.go tar: asm: store padding in chunks to avoid memory exhaustion 2017-11-08 02:34:56 +11:00
doc.go *: golint and docs 2015-03-09 14:11:11 -04:00
README.md tar/asm: another thought on clobbered files 2015-02-25 16:53:31 -05:00

README.md

asm

This library for assembly and disassembly of tar archives, facilitated by github.com/vbatts/tar-split/tar/storage.

Concerns

For completely safe assembly/disassembly, there will need to be a Content Addressable Storage (CAS) directory, that maps to a checksum in the storage.Entity of storage.FileType.

This is due to the fact that tar archives can allow multiple records for the same path, but the last one effectively wins. Even if the prior records had a different payload.

In this way, when assembling an archive from relative paths, if the archive has multiple entries for the same path, then all payloads read in from a relative path would be identical.

Thoughts

Have a look-aside directory or storage. This way when a clobbering record is encountered from the tar stream, then the payload of the prior/existing file is stored to the CAS. This way the clobbering record's file payload can be extracted, but we'll have preserved the payload needed to reassemble a precise tar archive.

clobbered/path/to/file.[0-N]

alternatively

We could just not support tar streams that have clobbering file paths. Appending records to the archive is not incredibly common, and doesn't happen by default for most implementations. Not supporting them wouldn't be a security concern either, as if it did occur, we would reassemble an archive that doesn't validate signature/checksum, so it shouldn't be trusted anyway.

Otherwise, this will allow us to defer support for appended files as a FUTURE FEATURE.