get_file_by_name does not check owner

[Gavin Panella]

maasserver.api.get_file_by_name is used to define a couple of API operations: AnonFilesHandler.get_by_name and FilesHandler.get_by_name. However, it does not verify ownership of the file, thus allowing anyone to download any file. FileHandler.read is an example of what should be done.

get_file_by_key may be similarly vulnerable; filed as bug 1379826.

[Raphaël Badin (rvb)]

My first intention was to simply remove the get_by_name() API operation from the anonymous handler. This is what I've done in https://code.launchpad.net/~rvb/maas/fix-get-file-by-name/+merge/187754 and the package I created from it worked fine with juju-core because juju-core uses either authenticated calls or get_file_by_key() to access the files it needs.

Sadly, this is not the case with (py)juju which really needs the anonymous get_by_name() API operation. Note that it needs it to get from the MAAS server files related to charms and which contain a random element (the file names are something like 'mysql-charm-sdfkj56lkjsdflkj4td'). The random element is probably there to mitigate the security risk.

This is rather problematic because the same code has to accommodate both juju-core and (py)juju. We could land my branch above if we choose to abandon pyjuju compatibility.

[Gavin Panella (allenap)]

If we can't abandon PyJuju there might still be something we can do to reduce the problem. If there's a pattern for these filenames - e.g. ^\w+-charm-\w+$ - then perhaps we can permit anonymous access for just these files. It's still a hole, though a smaller one. We could additionally have a config option to permit this, which defaults to false.

[Julian Edwards (julian-edwards)]

Unfixed for a year, can't be critical.

[Christian Reis (kiko)]

Unless someone really depends on it, we should kill this and deprecate pyjuju support. Can someone check with Alexis, Mark Ramm and Ante to see if this is the case?

[Christian Reis (kiko)]

Just wrote to them; let's see what they say.

[Raphaël Badin (rvb)]

@Kiko: I've testing this in the lab and go juju deploys services all right. Can you please do some more testing on this?

(I'm re-assigning this to you as I'll be travelling tonight and probably unavailable)

[Raphaël Badin (rvb)]

We decided to wait till after 1.7 is release in order to publish a fix for this bug, for all the versions of MAAS out there at the same time.

[Christian Reis (kiko)]

This is ready to land, but we'll hold off until the first point release where we can do a security-only change which we backport to trusty and precise.

[Marc Deslauriers (mdeslaur)]

This is CVE-2014-1426

[Marc Deslauriers (mdeslaur)]

What's the status on this issue? Did this get fixed? Does this bug need to remain private?

[Marc Deslauriers (mdeslaur)]

This security bug has been open for over two years now. I plan on making this bug public on 2016-05-01.