View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1708 | Composr | core | public | 2014-10-31 12:03 | 2015-11-07 22:36 |
| Reporter | Chris Graham | Assigned To | Chris Graham | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 1708: Security auto-updates | ||||
| Description | Drupal got some very bad press for not doing auto-updates: http://www.bbc.co.uk/news/technology-29846539 But auto-updates pose their own problems. If the auto-update system got hacked or Composr misdirected, that would be a huge security vulnerability, worse perhaps than any normal one. Additionally, there's a risk of corruption happening when auto-updating, Here is what I think we would have to do to do it well: 1) Completely separate updates server, with its own specific certificate, running over very high-security TLS settings 2) Have the auto-update only work if a sha1 checksum we post on our twitter account matches the sha1 checksum of what the update server is serving 3) Do a test-run, ensure all changed files pass "php -l" (if .php), and that the front page still gives a "200" status -- if not, it immediately rolls back and sends an error email to ocProducts 4) Server patches using our new smart patching system under development (not just replacing whole files or doing normal diff patching, as that is not reliable enough to work if files are customised) 5) Notifies owner their site is patched. 6) Notify ocProducts a site is patched via auto e-mailing in the patch file back to us (optional, per-site setting). This lets us detect if something malicious is patching select sites (=NSA or such). Not perfect, because at the end of the day a government entity could block that email too, but makes it a lot trickier for them. 7) Warn user if Curl's/OpenSSL's SSL checks not working (actually check them by ensuring a call to the wrong domain on the same server/certificate fails) 8) Has two waves. First wave is our own test sites, and compo.sr. Security server only passes out patch information according to the wave you're in, which is checked securely. This allows us to pre-test on our own sites but without leaking patch details out early (hence revealing the hole before sites are patched). 9) Patching would need to be very high-frequency or chrono-synched, as otherwise the source code changes could be analysed and someone could try and beat us infecting sites we're trying to patch. | ||||
| Additional Information | I know Wordpress has auto-updates. I suspect they have not given enough thought into it. Those in the know may wish to share in this discussion. | ||||
| Tags | Type: Security | ||||
| Attach Tags | |||||
| Time estimation (hours) | 64 | ||||
| Sponsorship open | |||||
|
|
A good idea to do in parallel or as an alternative is automatic update of patterns of request to block. This means no code has to be automatically updated (i.e. lower risk), but the pattern can be blocked. The user can then upgrade in their own time. |
|
|
Implemented the simpler idea - auto-updated software firewall - for v10. This is much better that the complex idea as it cannot be abused as an actual attack vector, and has far less scope to go wrong. |
