Changes between Version 1 and Version 2 of org/meetings/2016SummerDevMeeting/Notes/SecurityIssuePolicy


Ignore:
Timestamp:
Sep 27, 2016, 11:12:34 PM (3 years ago)
Author:
nickm
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • org/meetings/2016SummerDevMeeting/Notes/SecurityIssuePolicy

    v1 v2  
    2828TVE.  (Tor Vulnerabilities and Exposures)
    2929
    30 
     30------
     31Working document: "Draft tor software security issue response policy, v3"
     32
     33[This is a draft.  If I declare something stupid here, please help
     34me fix it!  -Nick]
     35
     36   Tor software security issue response policy [draft]
     37
     38
     39In the past, our security policy has been driven by dedication to our
     40users' well-being, but our incident-response decisions have for the
     41most part been made under stress and pressure.  So let's step back and
     42try to say what we'd *like* our decisions to be.  This doesn't reflect
     43a change in our policies, but an attempt to specify them in advance,
     44and commit to them in advance, to speed up our decision-making.
     45
     46The golden rule:
     47
     48      When in doubt, protect users.
     49
     50
     51-1. I am deeply suspicious; How should I read this document?
     52
     53   Please read it as having been written by and for honest people of
     54   good intent.  It is not intended to be sufficient on its own to
     55   guarantee good outcomes from people more determined to comply with
     56   its letter than its spirit.  Rather, it is intended to reflect a
     57   consensus on the right way to do things, help people of good intent
     58   make the right decisions under pressure, and let users know what to
     59   expect.
     60
     61
     62
     630. What does this document apply to?
     64
     65   Nothing, right now.  It's a draft.
     66
     67   But when it's not a draft, this section will say,
     68
     69   "This document was written to apply to Tor. Other projects
     70   under the Tor umbrella may choose to adopt it, or may have their
     71   own security policies."
     72
     73
     741. What should I do if I find a security flaw in something Tor makes?
     75
     76   First, try to make sure it's a real security flaw; see section 3
     77   below.  If the flaw is low-severity or already public, you can
     78   just report it on the bugtracker at https://trac.torproject.org/
     79
     80   If you find a security flaw in a Tor product that has adopted
     81   these guidelines, and the flaw is neither low-severity nor
     82   already public, please use private email to tell the list below.
     83
     84      tor-security@torproject.org
     85
     86   We hope to have a PGP key set up for this list soon; but until we do,
     87   you can use unencrypted email to tor-security to make initial
     88   contact, and figure out whose PGP keys you should use to communicate
     89   about the issue in more detail.  See section A below for some initial
     90   suggestions.
     91
     92
     93   Please don't rely on twitter direct messages, online chat, blog
     94   comments, postal mail, messages in bottles, or notes wrapped
     95   around bricks: anything that doesn't get sent to tor-security@ is
     96   at higher risk of being missed, misclassified, misevaluated, or
     97   misfiled.
     98
     99     [TODO: provide a non-PGP mechanism for secure issue
     100     reporting.]
     101
     102   You might also be interested in our HackerOne program.
     103
     104
     1052. How will Tor handle security issues?
     106
     107   First, we will assess whether an issue is already public, and
     108   we'll try to classify it as "research," "low-severity,"
     109   "medium-severity," or "high-severity."
     110
     111   For all public issues, we will do our work on them in public, on
     112   our bugtracker and other forums. When an issue is public, there's
     113   no point trying to keep it confidential.  (For the purposes of
     114   this document, we're considering an issue 'public' if it's
     115   already well-enough known that working on it in public will not
     116   make it easier for attackers to put our users at risk.)
     117
     118   For research issues, we will try to collect and document them in
     119   public, encourage researchers to work on them, and when possible
     120   develop defenses for them in public.
     121
     122
     123   All low-severity issues will be discussed on the bugtracker, and
     124   fixed in the development branch when possible.  Like other small
     125   bugfixes, these fixes will be backported to the extent that doing
     126   so seems likely to fix more problems than it causes.
     127
     128   For medium-severity non-public issues, we will keep them
     129   private, and try to batch up several fixes at once.  When we do
     130   fix them, we will apply the patches to at least the latest
     131   development and stable branches, and may backport to supported
     132   stable releases. We will announce that such an issue is being
     133   fixed in advance of the patch release date; we will announce
     134   details when the patch is released.
     135
     136   For high-severity issues not already publicly disclosed or being exploited,
     137   we will fix them in all affected releases, all at once, as soon as
     138   we can.  We will notify the world that such a bug exists in advance
     139   of the patch, and we will release the patch once we believe it
     140   works.
     141
     142   At our discretion, we will work for packagers on high-impact
     143   platforms to ensure that they have packages ready when the issue
     144   is disclosed.
     145
     146   For all non-disclosed issues, we will create an empty trac ticket, or
     147   some other mechanism to track the existence of the non-disclosed bug.
     148
     149
     150   Additionally, **flaws that harm users in the wild will be made
     151   public**.  Specifically, if we have reason to believe that an
     152   attack is being (or might be being) actively used to harm our
     153   users, we will sometimes inform people about the scope and extent
     154   of the attack as we become aware of it, even if we don't have a
     155   fix yet.  In deciding whether to do so, we will act so as to
     156   maximize user safety.
     157
     158
     1593. How will we assess the severity of a security issue?
     160
     161   We'll try to classify security issues as "research," "low-severity,"
     162   "medium-severity," or "high-severity." We may also classify an issue
     163   as "upstream."  See the next section for more information on these
     164   classifications.
     165
     166   Some issues arise because of unanswered "research questions," not
     167   because of bugs in the Tor software.  These include:
     168
     169     * End-to-end traffic correlation by an adversary who can observe
     170       both ends of the Tor circuit channel.
     171
     172     * Profiling attacks by waiting for a long time to become
     173       somebody's guard.
     174
     175     * Website- and traffic-type fingerprinting attacks.
     176
     177    In general, if no best or implementable solution is known for a
     178    given issue, it should be treated as a research problem rather
     179    than a security bug. These issues *matter*, and sometimes matter as
     180    deeply as any high-severity issue, but we shouldn't keep them
     181    private. Instead we will engage the research community for help
     182    solving them.
     183
     184
     185   Here are some things that typically count as "low-severity"
     186   security issues, or not as security issues at all:
     187
     188     * A program can be made to crash or work incorrectly, but the
     189       program's user is the only one who can cause this.
     190
     191     * An attack is possible by a class of attacker that Tor does
     192       not attempt to defend against. (For example, Tor assumes
     193       that the attacker does not have administrator access to your
     194       computer, has not installed a keylogger, does not control a
     195       majority of directory authorities, cannot make an
     196       authenticated connection to the control port, and so on.)
     197
     198     * An attack is possible when the user ignores the advice on our
     199       download page.
     200
     201     * When users go to the wrong hidden service address, they get the
     202       wrong hidden service.
     203
     204     * When users ignore clear certificate warnings from the browser,
     205       they are vulnerable to MITM from an exit node.
     206
     207     * When users ignore a warning that doing something will make Tor
     208       less secure, Tor becomes less secure.
     209
     210     * At significant expense or effort, an attacker can cause a
     211       denial of service to a relay.
     212
     213     * Timing side-channel attacks are present, but can only be
     214       exploited at great difficulty, and only by local users.
     215
     216
     217  These are typically "low-severity" issues:
     218
     219     * A defense-in-depth mechanism provides less defense-in-depth than
     220       it should (with no known corresponding attack enabled). For
     221       example, if sensitive material remains on the stack or heap
     222       without getting memwipe'd, but there is no means to exfiltrate
     223       it, it is typically low-severity.
     224
     225     * Undefined behavior is invoked, but not in a way that actually
     226       causes undesirable behavior when interpreted by any compiler we
     227       support.
     228
     229
     230   Anything in this category is typically a medium-severity issue:
     231
     232     * Any remote crash or denial-of-service attack that does not
     233       affect clients or hidden services, only relays. (This includes
     234       unfreed memory and other resource exhaustion attacks that can
     235       lead to denial-of-service.)
     236
     237     * Security bugs affecting configurations which almost nobody
     238       uses.
     239
     240     * Timing side-channel attacks that can be observed remotely, but
     241       only at great difficulty.
     242
     243     * Security bugs that require local (non privileged) access to
     244       your computer to exploit.
     245
     246     * Security bugs that only affect highly-unused platforms (like
     247       Irix, Windows 98, Linux 1.3, etc).
     248
     249
     250   Anything in this category is typically a "high-severity" issue,
     251   unless it is classified as lower severity because of one of the
     252   definitions above:
     253
     254     * Any means to remotely cause clients to de-anonymize themselves.
     255
     256     * Any remote code-execution vulnerability.
     257
     258     * Any remote crash attack against hidden services. (This includes
     259       unfreed memory and other resource exhaustion attacks that can
     260       lead to denial-of-service.)
     261
     262     * Any memory-disclosure vulnerability.
     263
     264     * Any means to impersonate a relay.
     265
     266     * Any way for non-exit relays to get at user plaintext.
     267
     268     * Any privilege escalation from a Tor user to the higher-privileged
     269       user that started the Tor process. (For example, if Tor is
     270       started by root and told to drop privileges with the User flag,
     271       any ability to regain root privileges would be high-severity.)
     272
     273
     274   Some bugs affect Tor, but are not bugs in Tor itself: they include
     275   bugs in external libraries, like OpenSSL, Libevent, or zlib; bugs in
     276   an operating system's kernel; or bugs in upstream Firefox affecting
     277   TorBrowser.  When we become aware of an "upstream" issue like this,
     278   we will coordinate with the upstream developers to find and deploy an
     279   appropriate fix, in accordance with their own security processes.
     280
     281
     282   Finally, the above categories are approximation only; difficulty
     283   of exploitation and other public factors may increase or decrease
     284   the security of an issue.
     285
     286      [TODO: Compare the above list with the categories in our bug
     287      bounty program.]
     288
     289
     2904. Can I show you my research findings in advance of disclosure? Or
     291   will you spoil my conference talk?
     292
     293   We'd rather have a fix today than a fix at the conference; but
     294   we'd rather have a fix that goes live the day of your talk than a
     295   fix that won't be ready till a week later.
     296
     297   Therefore, if you want to coordinate our disclosure to correspond
     298   with yours, we can arrange that, assuming that the interval
     299   during which you want us to keep the issue private (that is, to
     300   "embargo" it) is not longer than 60 days.
     301
     302   We will *not* embargo an issue under any of the following
     303   circumstances:
     304
     305      * The issue becomes public through other means, or somebody
     306        else finds it.
     307
     308      * We have reason to believe that the issue is being exploited
     309        against real users in the wild.
     310
     311   If one of these situations does occur, we will make an effort to
     312   alert you to the situation, and will coordinate with you to
     313   acknowledge your research and help: but our first priority will
     314   be to our users.
     315
     316
     3175. Who will find out about non-public flaws?  When?
     318
     319   The core developers of the affected software component, and the
     320   research director (Roger) will find out immediately.  We will work
     321   together with the bug reporter to identify and validate a solution.
     322
     323   We may enlist packagers, researchers and testers as needed to
     324   ensure that our fix is correct, and complete, and doesn't break
     325   anything else.
     326
     327   All other packagers will learn that there is an upcoming release
     328   that will fix a security flaw, and will learn the flaw's general
     329   severity, but won't learn specific information.
     330
     331   (And of course, everybody will learn about the flaw when it becomes
     332   public.)
     333
     334
     3357. More Questions and answers.
     336
     337  Q: Will you attribute bug reports and fixes?
     338
     339  A: Yes.
     340
     341  Q: How will you publicize issues and fixes?
     342
     343  A: All high-severity issues will get tweeted and blogged and
     344     emailed to tor-announcements.  All issues will be discussed
     345     in the changelog.  When appropriate, the changelog will feature a
     346     prominent sentence saying who should update.
     347
     348     Packagers will get personal email.
     349
     350     We will look into more ways to announce and publicize fixes and
     351     issues.
     352
     353  Q: Will you get CVEs?
     354
     355  A: Dunno.
     356
     357
     358
     359A. Secondary contact info
     360
     361   If for some reason the tor-security mailing list doesn't work for
     362   you, or you want to make initial contact in an encrypted way,
     363   please use the PGP keys here to encrypt your description of the
     364   issue, sending it to the appropriate project leads.
     365
     366   If you do not get a response, however, please try the
     367   tor-security mailing list above: do not assume that your email
     368   got through!
     369
     370
     371      Tor:
     372         Nick Mathewson <nickm@torproject.org>
     373               B35B F85B F194 89D0 4E28  C33C 2119 4EBB 1657 33EA
     374
     375      Tor browser:
     376         Georg Koppen <gk@torproject.org>
     377               35CD 74C2 4A9B 15A1 9E1A  81A1 9437 3AA9 4B7C 3223
     378
     379      Research director:
     380         Roger Dingledine <arma@torproject.org>
     381               F65C E37F 04BA 5B36 0AE6  EE17 C218 5258 19F7 8451
     382
     383
     384B. Acknowledgments
     385
     386   Thanks to everyone who offered helpful suggestions on earlier drafts,
     387   including Arlo Breault, Cass Brewer, David Goulet, George Kadianakis,
     388   Georg Koppen, Kate Krauss, Lunar, and Tom Ritter.
     389
     390   Thanks to everyone over the years who has patiently explained a
     391   security problem that we didn't understand to us until we finally
     392   understood what they were talking about.
     393
     394
     395C. Open issues
     396
     397   * How does this apply to censorship events?
     398
     399-------- comments?
     400
     401
     402