[Pkg-mozext-maintainers] Bug#919557: Bug#919557: Bug#919557: Bug#919557: Bug#922944: handling symbolic links in webextensions

[Ximin Luo]

Control: tags -1 + patch

Ximin Luo:
> Dmitry Smirnov:
>> On Sunday, 26 April 2020 9:25:06 AM AEST Ximin Luo wrote:
>>> The source code doesn't mention any particular reason, and one person on
>>> the upstream bug report mentions it in such an off-the-cuff and
>>> non-explanatory way I can't take it into account as a serious data point.
>>> We shouldn't just let a mere mention of "security" scare us into not
>>> touching stuff and using our own reasoning to fix bugs.
>>>
>>> And I *did* think about the possible security considerations, as I
>>> explained in my previous email, and derived my suggested patch based on
>>> these considerations. (FWIW, I have done and am doing various types of
>>> security work professionally, and I'm confident about this type of
>>> reasoning in general.)
>>
>> Did you consider the possibility of users having a mix of packaged and non-
>> packaged extensions? I think it is reasonable to contain/sandbox extensions 
>> to prevent peeking to various file system locations through symlinks.
>>
>> Once Firefox is patched to allow symlinks, the threat might be from malicious 
>> symlinks in non-packaged extensions.
>>
> 
> Yes, I covered this already. My suggested patch (B) would only traverse symlinks when the extension being loaded (the symlink being resolved) is itself underneath /usr/share/webext, other extensions would still not be allowed to traverse symlinks.
> 
> Please do read through my first email in full.
> 

Please see my attached patches, they work to fix the bug and I can now undo my local umatrix workarounds, and firefox will traverse the symlinks fine.

IMO both of these patches should be applied. Although the second one is slightly more intrusive, it results in much more flexible behaviour. Specifically, firefox resolves extension directories if they are symlinks, so a single "extensions directory" does not suffice for the typical Debian method of symlinking stuff from /usr/share/webext.

In patch 1 to avoid complexity, only one single extensions directory is whitelisted, and that is /usr/share/webext. This means extensions installed directly into /usr/share/mozilla/extensions (e.g. uBlock) still won't work with symlinks.

In patch 2, we avoid resolving extension directories if they are symlinks. Then, anything installed into /usr/share/mozilla/extensions will be allowed to traverse symlinks, including extensions that are symlinked into that directory.

By looking at the surrounding code, it is fairly clear that the patch only affects unpacked system extensions and nothing else, so it should be uncontroversial. However it does go a bit deeper into firefox internals, and I am unclear exactly why one part of it works - but empirically it works, I have tested it quite thoroughly. More testing is of course welcome, as well as any feedback.

(It is possible to shortcut part of the Debian build process for firefox, and sudo cp libxul.so and omni.ja into /usr/lib/firefox as soon as they have been built. However you will need to rm -rf ~/.cache/mozilla/firefox/*/startupCache/ for firefox to see the updates to omni.ja. If you install the debs, this step should be unnecessary, however it takes about 20-30 more minutes to produce them.)

Best,
X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 922944-1.patch
Type: text/x-patch
Size: 1585 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-mozext-maintainers/attachments/20200427/5dfef56f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 922944-2.patch
Type: text/x-patch
Size: 2809 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-mozext-maintainers/attachments/20200427/5dfef56f/attachment-0001.bin>