If you are building an app that is supposed to preserve privacy I want to tell you about (& how to fix) a vulnerability you probably have: Unintentional remote resource loading.
(I've found it in nearly every app I've ever audited under a privacy preserving risk model)
(I've found it in nearly every app I've ever audited under a privacy preserving risk model)
We find ourselves in a future where every goddamn app framework is actually a browser engine.
Browsers think auto-loading remote resources is a feature, and while there is some momentum to change that it isn't happening anytime soon.
Browsers think auto-loading remote resources is a feature, and while there is some momentum to change that it isn't happening anytime soon.
Whether it's something that is obviously a browser engine, like electron, or something that is sneakily a browser engine (like Qt/QML) chances are that you definitely have some kind of widget in your app that will happily interpret and display (a subset of) HTML.
Has anyone in the history of computers ever benefited from a random app element parsing html? Probably not,
Have otherwise robust privacy-preserving apps been screwed up by random elements parsing html...oh have they ever.
Have otherwise robust privacy-preserving apps been screwed up by random elements parsing html...oh have they ever.
Ok so the attack goes something like this:
Random UI element can parse HTML (usually by default)
Some untrusted input finds its way into the element
Even in html subsets img tags are usually around
UI automatically attempts to fetch the image
IP address leak to random server.
Random UI element can parse HTML (usually by default)
Some untrusted input finds its way into the element
Even in html subsets img tags are usually around
UI automatically attempts to fetch the image
IP address leak to random server.
Even when the input is implicitly trusted the leak is *unexpected* and even if you don't have such a path you might create one in the future - defending against such unexpected behaviour will save your ass down the line.
Defending against this attack is easier in some frameworks than in others. In QML it looks like this - effectively blocking QML from making network requests and forcing any networking requests to go through a custom API.
Annoying? A little. But better than the alternative.
Annoying? A little. But better than the alternative.
(Code from the Cwtch UI: git.openprivacy.ca/cwtch.im/ui/sr…)
It's worth noting that the above will also prevent things like anchor tags pointing to an external source from deanonymizing an active user (but that scenario is a little more involved)
How do you defend against either of those attack vectors using electron? I have no idea, please tell me. At best you can disable most of ways this prviacy leak can happen most of the time.
And, again, I need to stress here that "just only load trusted content" isn't a defence.
New features will always take priority above security concerns. Mistakes happen. A robust app has to be designed to expect and defend against such mistakes.
New features will always take priority above security concerns. Mistakes happen. A robust app has to be designed to expect and defend against such mistakes.
I usually see this vulnerability manifest through html images, but I've also seen it happen with audio, automatic api requests and dns/hostname lookups.
The complexity of modern application attacks means that the number of ways this can happen is forever growing.
The complexity of modern application attacks means that the number of ways this can happen is forever growing.
I see this vulnerability *everywhere*. It's usually the first thing I look for when evaluating an app because proactive defences are a good sign other vulnerabilities are likely to be mitigated, and a lack of defence likely means even small vulnerabilities become catastrophic.
It exists because the web became the defacto platform and UI frameworks evolved to be more like the web.
Sadly those evolution were based on designs that ignored privacy as a primary concern.
Sadly those evolution were based on designs that ignored privacy as a primary concern.
Little bit of trivia before I finish my thoughts on this: In QML the TLS engine isn't loaded in a usable configuration by default and so if you try to load a resource behind tls is will fail and if you are just monitoring networking traffic you might think you're secure.
Anyway, even if you are stuck in a framework that makes it difficult to defend against such issues take some time to think about ways to mitigate remote resource loading.
Disable frontend networking, Explicitly use plain text elements, Chokepoint filtering, Template engines etc.
Disable frontend networking, Explicitly use plain text elements, Chokepoint filtering, Template engines etc.
Technical privacy is hard because there are so many layers where things go catastrophically wrong because some engineer 30 years ago had a great feature idea that became default.
If you are advertising your app as a privacy app & you haven't considered this, you really need to.
If you are advertising your app as a privacy app & you haven't considered this, you really need to.
Remote resource loading is not the only thing that can go wrong and I can help you find (and fix!) all the other things too. I've very good at it. You should consider trying to hire me.
