Security Issue Disclosure

[gg0h]

Hello,

I've found a bug with potential security implications, what is the best way I can disclose this to you privately.

[amol-]

The best way you can contribute is to share submit a PR with a test to showcase the issue and a potential fix, many security issues in beaker have been mitigated by changing configuration options in the past and users might be able to mitigate them while we review the proposed fix.

[gg0h]

Hey @amol- , the bug is here:

beaker/beaker/util.py

Lines 236 to 245 in 96283fe

	ident = os.path.basename(ident)
	tokens = []
	for d in range(1, depth):
	tokens.append(ident[0:d])
	dir = os.path.join(root, *tokens)
	verify_directory(dir)
	return os.path.join(dir, ident + extension)

when file based sessions are used this function is used to construct the file path of the pickled session object.

beaker/beaker/container.py

Line 646 in 913d195

self.file = util.encoded_path(root=self.file_dir,

beaker/beaker/container.py

Line 672 in 913d195

with open(self.file, 'rb') as fh:

The bug is that os.path.basename does not strip leading periods, so if the user sets a session cookie beginning with two leading periods, the token loop will construct a path that traverses up one directory, e.g.:

for a session like 59bcc3ad6775562f845953cf01624225 it will be stored in and read from
<session.data_dir>/container/5/59/59bcc3ad6775562f845953cf01624225.cache

so if you try to make it read a session like ..poc you get
<session.data_dir>/container/./../..poc.cache which normalises to <session.data_dir>/..poc.cache

In the (somewhat contrived) scenario that SESSION_OPTS session.data_dir is writable by application functionality, an attacker could write a malicious pickle object there and abuse this primitive to load it and get remote code execution on the server.

The patch should be fairly simple, I'll look at putting one in later today.

[gg0h]

On closer look, this seems to be the same issue described in #59

[gg0h]

I'll add some tests to the PR.