-
-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sandbox escape vulnerability #377
Comments
@danielzgtg Thank you for reporting the vulnerability. While it is important to investigate, I should point out that the danger is low for these reasons:
However, a vulnerability could be more serious with Electron and NWJS versions of these apps. I use the contextBridge mechanism in the Electron app, which is supposed to limit messaging between the browser/renderer process and the main process, so I believe this will protect users, but of course I'd like to examine the vulnerability you've identified. If you use Slack and join the Kiwix Slack (open access), you could DM me there (same username). Otherwise by email egk10 (at) cam ac uk. |
I agree that this vulnerability is not very serious. I and most people only use trusted zims from https://download.kiwix.org/ . After yesterday's research, I learned that I shouldn't open any random zims if anyone sends me one, and that should be enough.
I tried multiple times and multiple ways of joining the Kiwix Slack but couldn't. It says "The email address must match one of the domains listed below. Please try another email. You can use any account with the domain: kiwix.org mgautier.fr wikimedia.org marcelsuter.ch bibliosansfrontieres.org eduairbox.com banyanlabs.io Don’t have an email address from one of those domains? Contact the workspace administrator at Kiwix for an invitation." You could try inviting me with the email listed on my GitHub profile, though eventually this needs to be fixed for other people to make it actually "open access". I think this means that you didn't receive the email with the password. I will forward it to the email you specified. |
Oops, sorry, I must have signed up with an invitation, I thought it was open! I've sent you an invite, in case interested, but email received, thanks. |
I found the correct invitation at https://www.kiwix.org/en/support-us/code/ and will edit the page at https://wiki.kiwix.org/wiki/Communication . But I digress. |
In 8da7604 I'm testing the sandbox attribute as reported in kiwix/kiwix-js#972 (comment). To test, visit the test PWA and let it update to v2.3.81 (after restart of app). So far, tested and working in Edge, Firefox and IE11. |
NB to test how this blocks top-level navigation in Wiktionary, it is necessary to turn off the option to Use locally cached Wikimedia styles (if it's on, then the vulnerability is patched by removing the offending script). |
Working in:
It should be noted that this is not a security fix against a malicious ZIM because, as Chrome warns: But it is a useful extra safeguard against poorly coded scripts and accidental (or intentional) "phone-home" attempts. |
I tested this to be working. It works as the controls survive both when the option is turned on and when it's turned off. I tested
Yeah, I see now. Firefox doesn't warn but when I loaded poc1 it still broke out, oh well. This should indeed block phone-home attempts by actors that don't expect to run in an iframe, which should include most accidental attempts. Actors that are aware they are inside an iframe can break out in the same way as poc1. At least this fixes broken zims like |
Thank you for testing. I opened the ZIMs you provided -- many thanks --, but I'm currently out of ideas to prevent these injections, unless you've had any further ideas. Possibly search for an additional iframe being added and halt the app with a warning. But adding an iframe is just one possible attack vector. It could be a div I guess, which I couldn't block. Or messing with the caches (possibly). (The only other idea I had was to ask user to consider if they trust the source of a ZIM before allowing it to be opened.) |
Update for this repo: Theoretically the vulnerability can be addressed by serving content to the iframe with a CSP header that includes the |
I think we've got as far as we can with this, and the fixes we have are included in v2.4.2 of the PWA. Consideration will be given to kiwix/kiwix-js#974, but for now I'm closing this. |
I confirm that poc1 and poc2 are patched. |
As mentioned in openzim/mwoffliner#1803 (comment) , I found a vulnerability in the sandbox that allows zims to break out and change the top level controls. The sandbox escape runs immediately after opening the zims.
This is new and don't involve redirects. Redirects nevertheless may weaken the sandbox, and I haven't checked whether CSP is enforced after redirects.
poc1
The fixed-position iframe stays there even after moving to the configuration page.
poc2
This one should be relatively simple to fix compared to poc1.
Steps
A zip of a proof-of-concept project is kiwix-pwa-poc.zip.
This the first time I have reported a security vulnerability ever in any project. I'm a bit lost and I don't see any
SECURITY.md
. I've read that it's not responsible to post proofs-of-concept publicly and that I should send an email instead. Therefore, I will be emailing [email protected] shortly with the password for the zip. EDIT: Email sent.The text was updated successfully, but these errors were encountered: