[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <etPan.53dd4a95.327b23c6.d5d9@Thor.local>
Date: Sat, 2 Aug 2014 16:31:17 -0400
From: Donald Stufft <donald@...fft.io>
To: gremlin@...mlin.ru, oss-security@...ts.openwall.com
Subject: Re: CVE Request: Enforce use of HTTPS for
MathJax in IPython
On August 2, 2014 at 1:08:12 PM, gremlin@...mlin.ru (gremlin@...mlin.ru) wrote:
> On 31-Jul-2014 23:23:18 -0500, Kyle Kelley wrote:
>
> > Summary: When using the IPython notebook without encryption
> > (i.e. running the server on HTTP instead of HTTPS), mathjax is
> > loaded over HTTP. An attacker with fortuitous network position
> > could execute code on a local IPython notebook by modifying the
> > mathjax javascript.
>
> HTTPS wouldn't help much: the attackers (most of which are known to
> use 3-letter names) can (and they really do) issue a fake certificate
> for their decoy servers.
There are attackers other than 3 letter agencies.
>
> In general, nothing received from the Net could be trusted. And the
> HTTPS doesn't guarantee anything beyond "this certificate was signed
> by this CA" - was that voluntary or forced.
>
> Enforcing HTTPS for the whole site is even more stupid: normally only
> user-specific data (login procedure, personal settings for registered
> users, etc) should be forced to go through HTTPS; everything else
> should normally be left up to the users' wish.
This is incredibly wrong. First off if only your login procedures, personal
settings, etc are password protected then it's trivial for a MITM to simply
strip the HTTPS from the link to the login page. The vast bulk of users simply
won't notice that they are visiting a page via HTTP instead of HTTPS.
Furthermore, even if you manage to login over HTTPS, HTTP, being a stateless
protocol, includes authentication credentials with every request. This is
typically taken in the form of cookies which are sent with every request. In
order to protect these cookies they need to only be sent over a HTTPS connection.
Even if you set cookies to secure, that still doesn't prevent an attacker from
writing cookies and doing a fixation attack to trick a victim into being logged
into another account. Perhaps they don't notice this and they do something
sensitive, such as adding a credit card to their account, and in reality they
are adding their credit card to another account.
Even simply redirecting to HTTPS isn't enough, because a MITM attacker could
simply intercept the redirect and terminate the TLS themselves and return a
plaintext page. You must use HSTS with a long timeout to enforce HTTPS for the
entire domain.
Even with HSTS on just that single domain isn't enough, you need to use the
includeSubdomains option otherwise a MITM attacker simply needs to convince
your browser, through a redirect or embedded image or what have you, to visit
a non-existant sub domain of your domain which, due to the nature of browser's
cookie domain policy, will be able to write cookies doing a session fixation
or even read cookies if you don't have them set to secure.
Finally if the domain that is to be protected is a subdomain itself, than the
parent domain must also have HTTPS enforced via HSTS with includeSubdomains
because again, the browser policy allows a parent domain to set a cookie that
the sub domains will read allowing yet another avenue for a fixation attack.
So sure, this doesn't prevent a TLA with access to a root key doing a targeted
attack against a site, however it does prevent an attacker who just happens
to be on the same network (Coffeshop Wifi etc) from attacking you.
>
> But the terminal state of mental disability is... yes, using scripts
> from outer sources: intercepting one popular source like
> https://ajax.googleapis.com/ajax/libs/jquery/*/jquery.min.js will
> allow the attacker to not bother of intercepting other sites directly.
>
> > This issue was fixed in the git master branch (development branch
> > for upcoming v. 2.2) with commit cf793ebc4, on 7/31/2014:
>
> Not a vulnerability, not a fix.
>
Absolutely is a vuln and is a fix.
--
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
