bioformats
bioformats copied to clipboard
OME-TIFF reader: getCanonicalPath causes containment regression in OMERO context
See https://forum.image.sc/t/no-access-to-some-images-in-omero-securityviolation-metadata-companion-ome-accesses-data-outside-managed-repository/69453
The issue can be reproduced either using the public sample shared in the image.sc thread of any companion fileset like the official OME-TIFF sample athttps://downloads.openmicroscopy.org/images/OME-TIFF/2016-06/companion/.
The source of the regression was most likely #3694 which was required to fix another workflow with companion OME-TIFF filesets using relative paths in the BinaryOnly
element. More specifically, https://github.com/ome/bioformats/pull/3694/commits/bd13a7cfdc2ad7064740de23eef9061d279ff1a5 uses getCanonicalPath
to resolve any usage ./
or ../
. A downside of this is that it also resolves symlinks
Using the offical sample symlinked under /tmp/companion
and running showinf
either on a consitutive TIFF or the companion file, the dataset reading is identical but the list of used files will either point to the symlinked directory or to the resolved link:
build@0716968db45c:/bio-formats-build/bioformats/tools$ ./showinf /tmp/companion/multifile-Z1.ome.tiff -nopix
Checking file format [OME-TIFF]
Initializing reader
OMETiffReader initializing /tmp/companion/multifile-Z1.ome.tiff
SamplesPerPixel mismatch: OME=-1, TIFF=1
Reading IFDs
Populating metadata
Reading IFDs
Populating metadata
Initialization took 0.167s
Reading core metadata
filename = /uod/idr/repos/curated/ome-tiff/public/2016-06/companion/multifile.companion.ome
Used files:
/uod/idr/repos/curated/ome-tiff/public/2016-06/companion/multifile.companion.ome
/uod/idr/repos/curated/ome-tiff/public/2016-06/companion/multifile-Z1.ome.tiff
/uod/idr/repos/curated/ome-tiff/public/2016-06/companion/multifile-Z2.ome.tiff
/uod/idr/repos/curated/ome-tiff/public/2016-06/companion/multifile-Z3.ome.tiff
/uod/idr/repos/curated/ome-tiff/public/2016-06/companion/multifile-Z4.ome.tiff
/uod/idr/repos/curated/ome-tiff/public/2016-06/companion/multifile-Z5.ome.tiff
Series count = 1
Reading IFDs
Populating metadata
Series #0 :
Image count = 5
RGB = false (1)
Interleaved = false
Indexed = false (false color)
Width = 18
Height = 24
SizeZ = 5
SizeT = 1
SizeC = 1
Tile size = 18 x 24
Thumbnail size = 18 x 24
Endianness = intel (little)
Dimension order = XYCTZ (certain)
Pixel type = uint8
Valid bits per pixel = 8
Metadata complete = true
Thumbnail series = false
-----
Plane #0 <=> Z 0, C 0, T 0
Plane #2 <=> Z 2, C 0, T 0
Plane #4 <=> Z 4, C 0, T 0
Reading global metadata
Reading metadata
build@0716968db45c:/bio-formats-build/bioformats/tools$ ./showinf /tmp/companion/multifile.companion.ome -nopix
Checking file format [OME-TIFF]
Initializing reader
OMETiffReader initializing /tmp/companion/multifile.companion.ome
SamplesPerPixel mismatch: OME=-1, TIFF=1
Reading IFDs
Populating metadata
Reading IFDs
Populating metadata
Initialization took 0.191s
Reading core metadata
filename = /tmp/companion/multifile.companion.ome
Used files:
/tmp/companion/multifile.companion.ome
/tmp/companion/multifile-Z1.ome.tiff
/tmp/companion/multifile-Z2.ome.tiff
/tmp/companion/multifile-Z3.ome.tiff
/tmp/companion/multifile-Z4.ome.tiff
/tmp/companion/multifile-Z5.ome.tiff
Series count = 1
Reading IFDs
Populating metadata
Series #0 :
Image count = 5
RGB = false (1)
Interleaved = false
Indexed = false (false color)
Width = 18
Height = 24
SizeZ = 5
SizeT = 1
SizeC = 1
Tile size = 18 x 24
Thumbnail size = 18 x 24
Endianness = intel (little)
Dimension order = XYCTZ (certain)
Pixel type = uint8
Valid bits per pixel = 8
Metadata complete = true
Thumbnail series = false
-----
Plane #0 <=> Z 0, C 0, T 0
Plane #2 <=> Z 2, C 0, T 0
Plane #4 <=> Z 4, C 0, T 0
Reading global metadata
Reading metadata
From a strict Bio-Formats perspective, the data can faithfully be read using either entry point. The regression happens at the OMERO level as the resolution of the symlinks might conflict with the containment checks introduced in https://www.openmicroscopy.org/security/advisories/2019-SV1/. This can happen e.g. when the data is in-place imported or when the data directory is itself a symlink as in the image.sc thread.
From the testing, the impact of this regression is limited to companion OME-TIFF filesets imported using a server prior to OMERO.server 5.6.4 byt using one of the contituent OME-TIFF file (rather than the companion file) after the OMERO.server is upgrade. Mitigations at the OMERO level might allow to restore access to this data with the currently released OMERO.server 5.6.5 but overall it feels like the OME-TIFF reader should also be patched to use a different API than getCanonicalPath
.
This issue has been mentioned on Image.sc Forum. There might be relevant details there:
https://forum.image.sc/t/no-access-to-some-images-in-omero-securityviolation-metadata-companion-ome-accesses-data-outside-managed-repository/69453/10