Game-over scenarios

(Before you read this, “Effective partnerships” provides context)

I’ve talked about bringing human judgement to bear, but no measures that help a team produce good code help if an attacker finds a flaw that lets them effectively substitute their code for yours.

In the Attack Review Testbed, I’ve demoed several mechanisms to block these “Game Over scenarios”:

• When one module require()s another, resource integrity checks make
  sure that the file loaded is one that should load.
  This works, because when the tests are run, it generates a list of cryptographic hashes of each production source file. So, without developer interaction, we have an up-to-date definition for “trusted source file.”
  Even if an attacker can write to the file system, and overwrite a source file or trick a module that does require(x) into loading their file, the resource integrity checks will block it.
  This also prevents accidental loading of test code that might do something you don’t want in production.
• Sometimes modules turn strings into code via eval() or new Function().
  This can even happen in code that doesn’t explicitly mention eval or Function.
  The testbed turns off these dangerous operators via the rarely used flag
  --disallow_code_generation_from_strings.
  Unfortunately, that breaks widely used modules like depd and lodash which call new Function(), so the testbed does a trick to turn Function()
  back on for modules that are known to need it.
  This eliminates the risk of implicit access to Function() and bounds the risk to a well-defined and reviewable subset of widely used modules.
  The testbed declines to turn it back on for jsdom because it does not require the features that jsdom uses it for without breaking the features that it does require from jsdom.

There are some game-over scenarios that I’ve not addressed. The testbed would have denied the malicious event-stream code access to the http package which it used to send passwords to its author, but a malicious code author willing to work to bypass these protections would probably have found a way to get passwords out anyway. Malicious code is a real problem but not one of the threats I’ve been focusing on.

Thank you for reading this far. If you’re interested in understanding how these technical measures work together or like breaking things, take a look at the attack review testbed. I’d love to get community feedback on how robust these are in practice.

The target application has an intentionally large attack surface. This application should be easy to breach if it were not for the security machinery under test, so if it resists breach, then the security machinery provides value.