Re: [Debconf-team] concerns about storm.debian.net (was Re: Meeting this week: A general sprint on stuff)
Hi Joerg & all,
(I just subscribed by mail to this list, but I'm replying here by GMANE,
so hopefully everything will do the Right Thing.)
I'm one of the maintainers of storm.debian.net, along with Clint.
Moreover I'm one of the upstream authors of Sandstorm. Thanks for being
willing to try something I've been working on.
On Fri, 23 Oct 2015 09:57:50 +0200, Joerg Jaspert wrote:
> On 14102 March 1977, Laura Arjona Reina wrote:
>
>>> The main point that makes it entirely unusable is its usage of a new
>>> subdomain for serving the javascript FOR EVERY NEW REQUEST. This is
>>> beyond stupid and disallows any kind of javascript blocker in your
>>> browser, unless you allow it to trust the whole debian.net domain,
>>> which is way too far fetched.
>> I understand. Would adding storm.debian.net to the white list do the
>> trick?
>> I've done it in my Iceweasel with NoScript and it seems to work but I'm
>> not totally sure.
>
> Only if JS gets served from there. The two anti-js things i tested for
> chromium either want to trust all of debian.net for full domain, or just
> the host, ie they dont want to allow "everything below this subdomain".
> :/
I just tested NoScript for Firefox/Iceweasel, and when I whitelist
storm.debian.net (or rose.sandcats.io, the UI for my personal install) it
seems to effectively whitelist all subdomains. That isn't one of the
options presented in the immediate UI, but when I go into
* Noscript -> Options
* Whitelist "You can specify which websites are allowed to execute
scripts"
* Enter rose.sandcats.io into "Address of website", then click "Allow",
then click "OK"
When I reload rose.sandcats.io, the dashboard works and so do all the web
apps within that host.
The same works for me for storm.debian.net.
I can try with a Chromium-based script blocker and help provide
configuration details that work for it. Which one are you using?
> In any sensible setup there isnt the need for it. :/
Unfortunately I can't agree with that.
You're probably familiar with the idea that each app should be on its own
domain. Otherwise, apps can typically steal user cookies frome each
other, and then one compromised app can exploit a bug in another one:
* DSA-3338 <https://security.debian.org/security/2015/dsa-3338> - SQL
injection vulnerability in graphs.php (cacti)
If two apps share a domain, then one compromised app can be used to steal
the CSRF token (or session ID cookie) another app on the same domain.
That situation could lead to successfully exploiting bugs like this.
But Sandstorm goes a bit further, with a temporary subdomain, unique to
this (user, app instance, session) triple. I wrote about the security
benefits in the Sandstorm docs https://docs.sandstorm.io/en/latest/
administering/wildcard/ but I can also summarize:
Predictable domain names enable attacks where evilsite.com crafts POST or
GET requests to the well-known hostname, which results in your browser
sending a request to the well-known hostname with your login cookies for
that hostname. One name for this is cross-site request forgery. Depending
how vulnerable the app is, this can work even without Javascript enabled;
mere IMG tags can do the job.
These vulnerabilities are very common against web apps (free and non-
free), so Sandstorm uses this one-time-use domain name measure as an
extra hardening against them.
Here are some recent Debian Security Advisories that are mitigated by the
Sandstorm one-time-use domain name feature.
* DSA-3346 <https://security.debian.org/security/2015/dsa-3346> - Cross-
site Request Forgery - Form API - Drupal 6 and 7
* CVE-2015-3439 within DSA-3250 <https://security.debian.org/
security/2015/dsa-3250> and CVE-2015-3429 in DSA-3328 <https://
security.debian.org/security/2015/dsa-3328> - WordPress ships bundled
files that created cross-site scripting bugs. Since no user knows another
user's temporary, per-session, per-user Sandstorm subdomain, they can
only use this to attack themselves.
* DSA-3291 <https://security.debian.org/security/2015/dsa-3291> -
Unvalidated redirect. Since no user knows another user's temporary, per-
session, per-user Sandstorm subdomain, they can't realistically attack
each other.
* DSA-3241-1 <https://security.debian.org/security/2015/dsa-3241> Path
traversal vulnerability allows file disclosure (Elasticsearch) - I can't
tell if this requires being logged in or not, but if it doesn't require
being logged in, then Sandstorm's one-time-use domain name means that an
external user can't guess what hostname to use to reach the buggy app.
* DSA-3227 <https://security.debian.org/security/2015/dsa-3227> - Movable
Type has a format string injection vulnerability that requires knowing
the hostname of the app. But Sandstorm won't give you the app's hostname
unless you are authorized to access the app, so remote unauthenticated
attackers can't exploit this.
Those are from my reviewing Debian Security Advisories from the past 6
months or so.
And there are some Etherpad bugs that Sandstorm mitigates through the per
(user, app instance, session) temporary subdomains. Here's two.
* CVE-2015-3297 <http://www.openwall.com/lists/oss-security/2015/04/12/2>
- Read arbitrary file from filesystem - only usable by authenticated
users, within Sandstorm (further mitigated by filesystem namespaces but
that's a separate thing)
* CVE-2015-2298 <https://security-tracker.debian.org/tracker/
CVE-2015-2298> - Etherpad will disclose a list of all pads, erasing all
pad security since Etherpad's only security mechanism is secret pad
names. One-time-use subdomains means that an attacker can't find the URL
to a valid Etherpad instance unless they're authorized. (Also Sandstorm
runs one Etherpad document per app instance so it's further hardened, but
that's separate.)
So I hope that helps explain why Sandstorm does that weird constantly-
rotating hostnames thing.
As a sidenote, I ran into the whitelisting UI problem with NoScript
myself -- when I visited https://rose.sandcats.io/ (my personal server's
Sandstorm interface), I was offered the ability to whitelist sandcats.io.
But that's a bug in NoScript, in my opinion -- sandcats.io is a dyndns
service, listed in the Public Suffix List <https://publicsuffix.org/>, so
rose.sandcats.io should be what NoScript offers me to whitelist. I'll see
if I can read the NoScript code and figure out if they could use the
nsIEffectiveTLDService Gecko API and then present a more reasonable
prompt.
Hope that helps explain why Sandstorm does what it does. Let me know if I
can be of further use. In particular I'd love to know what Chromium addon
you're using so I can document how to whitelist storm.debian.net
appropriately.
-- Asheesh.
Reply to: