On Jul 29 2015, Sam Hartman <hartm...@debian.org> wrote:
> Hi.
> I attempted the following:
>
> * Built with the patch applied on a jessie chroot
> * installed s3ql
>
> * On a wheezy system mkfs.s3ql, mount and add some data. unmount.
>
> * On my patched jessie system run s3qladm upgrade
>
> So far so good.
>
> Then run fsck.s3ql.
> It looks like it has trouble with the old metadata:
> Backing up old metadata...
> Uncaught top-level exception:
> Traceback (most recent call last):
> File "/usr/lib/s3ql/s3ql/backends/s3c.py", line 710, in _extractmeta
> return safe_unpickle(b64decode(buf), encoding='latin1')
> File "/usr/lib/s3ql/s3ql/backends/common.py", line 629, in
> safe_unpickle
> encoding=encoding, errors=errors)
> File "/usr/lib/s3ql/s3ql/backends/common.py", line 613, in
> safe_unpickle_fh
> raise pickle.UnpicklingError('opcode %s is unsafe' %
> opcode.name)
> _pickle.UnpicklingError: opcode NEWOBJ is unsafe
>
> During handling of the above exception, another
> exception occurred:
>
> Traceback (most recent call last):
> File "/usr/bin/fsck.s3ql", line 9, in <module>
> load_entry_point('s3ql==2.11.1',
> 'console_scripts', 'fsck.s3ql')()
> File "/usr/lib/s3ql/s3ql/fsck.py", line 1224, in
> main
> cycle_metadata(backend)
> File "/usr/lib/s3ql/s3ql/metadata.py", line
> 121, in cycle_metadata
> cycle_fn("s3ql_metadata_bak_%d" % i,
> "s3ql_metadata_bak_%d" % (i + 1))
> File "/usr/lib/s3ql/s3ql/backends/comprenc.py",
> line 290, in copy
> self._copy_or_rename(src, dest, rename=False,
> metadata=metadata)
> File "/usr/lib/s3ql/s3ql/backends/comprenc.py",
> line 299, in _copy_or_rename
> meta_raw = self.backend.lookup(src)
> File "/usr/lib/s3ql/s3ql/backends/common.py",
> line 46, in wrapped
Ok, this is very suspicious:
1. There should be no s3ql_metadata_bak_* object. "s3qladm upgrade"
renames them all to prevent a *different* problem than the one you
have above. Did you run fsck.s3ql right after s3qladm, or did you
mount or fsck the file system before that? If not, is it possible
that the changes had not yet propagated?
2. The above problem should not happen in the first place. There should
never be a NEWOBJ operation in the pickle stream. Actually, if
someone would try to exploit CVE-2014-0485 by sending you a malicious
storage object, this is exactly the error you would get.
Do you have any confidential metadata? I may have to look at the actual
pickle to figure out what's happening here.
> It may be as simple as ignoring unsafe pickles in old metadata.
Certaintly not, that would open a remote code execution vulnerability.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
