Release goals for 20.XX

[Sam Kuper]

On Fri, Jul 31, 2020 at 01:37:00PM +0200, baptiste at bitsofnetworks.org wrote:
> 3) organisational: switch to gitlab?
> 
>    While there was a vote about it,

Hi, do you happen to have a link to that discussion/vote?

>    I don't know if this is planned for 20.XX.  I think it makes sense:
>    we could start using gitlab to track 20.XX bug reports, and
>    possibly drop 18.06 bug reports from flyspray.  But if it is not
>    ready, it should probably not block the 20.XX release.

I would encourage delaying such a move.

My reason is that although Gitlab is free as in freedom (good!), it does
rely on client-side JavaScript for much of the functionality of its web
pages (bad!).  (By "the functionality in its web pages", I mean as
opposed to, say, the functionality exposed through its API.)

This means that any visitor/developer who needs to interact with a
Gitlab instance via its webpages is forced to increase their attack
surface by enabling JavaScript in their browser.

This in turn means that if the server running the Gitlab instance gets
compromised by an attacker, then the attacker would be able to pivot to
visitors/developers' workstations or laptops by serving JavaScript-based
malware.  This might in principle allow the attacker to e.g.:

- steal the visitor's/developer's private keys if present in the cache
  or RAM of that person's PC;[1] or

- gain privileged code execution on that person's PC,[2] allowing for
  installation of a remote access tool (RAT) and consequent ability to
  exfiltrate private keys or otherwise masquerade as the PC's owner.

Clearly, such an attack if carried out would have serious implications
for the future integrity of OpenWRT.

Such malware, especially if it exploits unfixable hardware
vulnerabilities in client CPUs (e.g. Spectre, Meltdown, etc) can be
protected against by disabling JavaScript in one's web-browser.  But
although this protection works well when visiting the *current* OpenWRT
websites (wiki, bug tracker, etc), it would *NOT* be viable if OpenWRT
switches to Gitlab.  (This is because of Gitlab's reliance on
client-side JavaScript, as mentioned earlier.)

Sadly, this is not only theoretical.  Attacks along roughly these lines
are known to have been conducted in the past, in order to insert
vulnerabilities into networks and codebases.[3]

OpenWRT is widely used, especially by people who value security and
therefore choose it over proprietary alternatives.  Consequently, it is
a "target-rich environment".

For this reason, I would urge the OpenWRT devs *not* to switch to any
web-based software that requires visitors to browse with JavaScript
enabled.

All best,

Sam


[1] "Research showed that microarchitectural attacks like cache attacks
can be performed through websites using JavaScript. ...  However, the
W3C and browser vendors responded to this significant threat by
eliminating fine-grained timers from JavaScript. ...  We demonstrate the
inefficacy of this mitigation by finding and evaluating a wide range of
new sources of timing information.  We develop measurement methods that
exceed the resolution of official timing sources by 3 to 4 orders of
magnitude on all major browsers, and even more on Tor browser.  Our
timing measurements do not only re-enable previous attacks to their full
extent but also allow implementing new attacks."
https://gruss.cc/files/fantastictimers.pdf

[2] "side-channel attacks allow to detect the exact location of kernel
data structures or derandomize ASLR in JavaScript.  A combination of a
software bug and the knowledge of these addresses can lead to privileged
code execution."
https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-lipp.pdf

"We demonstrate a fully automated attack that requires nothing but a
website with JavaScript to trigger faults on remote hardware.  Thereby
we can gain unrestricted access to systems of website visitors.  We show
that the attack works on off-the-shelf systems.  Existing
countermeasures fail to protect against this new Rowhammer attack."
https://link.springer.com/chapter/10.1007%2F978-3-319-40667-1_15

[3]
https://theintercept.com/2014/03/20/inside-nsa-secret-efforts-hunt-hack-system-administrators/

https://theintercept.com/document/2014/03/20/hunt-sys-admins/

https://theintercept.com/2014/03/12/nsa-plans-infect-millions-computers-malware/

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.