Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Block External Entity Resolution (or force through Tor) #303

Closed
s-rah opened this issue Nov 9, 2015 · 1 comment
Closed

Block External Entity Resolution (or force through Tor) #303

s-rah opened this issue Nov 9, 2015 · 1 comment

Comments

@s-rah
Copy link
Member

s-rah commented Nov 9, 2015

I'm not entirely sure this is possible, but I was writing up my ricochet fuzzing adventures and while thinking about deeper mitigations for #274 the idea came up.

Is it possible in Qt to either a) block the resolution of external resource e.g. tags entirely or b) force the resolution through Tor?

Such an option would effectively mitigate any future HTML rendering bugs by turning, what is currently, an easy de-anonymization bug into an annoying, but mostly harmless, UX bug.

I had a quick search but haven't found a way so far, so I'm putting it out there in the hopes someone has an idea.
special added a commit to special/ricochet that referenced this issue Dec 23, 2015
@special
Block all network requests originating from QML
1956d6c 
Ricochet's UI does not make any network requests under any
circumstances; if one happens, it's likely a bug and potentially an
input sanitization issue that could lead to deanonymization.

Using QML's network access manager factory, intercept all of these
requests, trigger an assert, and make sure it's absolutely not possible
for any network traffic to occur as a result.

Contributes to ricochet-im#303, inspired by Sarah Jamie Lewis
@special
Copy link
Member

special commented Jan 2, 2016

With 1956d6c, we now block all network requests originating from QML. That can't block traffic from Qt or anything else, but that's a problem we should handle with sandboxing when possible.

@special special closed this as completed Jan 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@special @s-rah