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

Sep 27, 2016, 11:12:34 PM (3 years ago)



  • org/meetings/2016SummerDevMeeting/Notes/SecurityIssuePolicy

    v1 v2  
    2828TVE.  (Tor Vulnerabilities and Exposures)
     31Working document: "Draft tor software security issue response policy, v3"
     33[This is a draft.  If I declare something stupid here, please help
     34me fix it!  -Nick]
     36   Tor software security issue response policy [draft]
     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.
     46The golden rule:
     48      When in doubt, protect users.
     51-1. I am deeply suspicious; How should I read this document?
     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.
     630. What does this document apply to?
     65   Nothing, right now.  It's a draft.
     67   But when it's not a draft, this section will say,
     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."
     741. What should I do if I find a security flaw in something Tor makes?
     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
     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.
     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.
     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.
     99     [TODO: provide a non-PGP mechanism for secure issue
     100     reporting.]
     102   You might also be interested in our HackerOne program.
     1052. How will Tor handle security issues?
     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."
     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.)
     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.
     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.
     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.
     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.
     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.
     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.
     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.
     1593. How will we assess the severity of a security issue?
     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.
     166   Some issues arise because of unanswered "research questions," not
     167   because of bugs in the Tor software.  These include:
     169     * End-to-end traffic correlation by an adversary who can observe
     170       both ends of the Tor circuit channel.
     172     * Profiling attacks by waiting for a long time to become
     173       somebody's guard.
     175     * Website- and traffic-type fingerprinting attacks.
     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.
     185   Here are some things that typically count as "low-severity"
     186   security issues, or not as security issues at all:
     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.
     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.)
     198     * An attack is possible when the user ignores the advice on our
     199       download page.
     201     * When users go to the wrong hidden service address, they get the
     202       wrong hidden service.
     204     * When users ignore clear certificate warnings from the browser,
     205       they are vulnerable to MITM from an exit node.
     207     * When users ignore a warning that doing something will make Tor
     208       less secure, Tor becomes less secure.
     210     * At significant expense or effort, an attacker can cause a
     211       denial of service to a relay.
     213     * Timing side-channel attacks are present, but can only be
     214       exploited at great difficulty, and only by local users.
     217  These are typically "low-severity" issues:
     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.
     225     * Undefined behavior is invoked, but not in a way that actually
     226       causes undesirable behavior when interpreted by any compiler we
     227       support.
     230   Anything in this category is typically a medium-severity issue:
     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.)
     237     * Security bugs affecting configurations which almost nobody
     238       uses.
     240     * Timing side-channel attacks that can be observed remotely, but
     241       only at great difficulty.
     243     * Security bugs that require local (non privileged) access to
     244       your computer to exploit.
     246     * Security bugs that only affect highly-unused platforms (like
     247       Irix, Windows 98, Linux 1.3, etc).
     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:
     254     * Any means to remotely cause clients to de-anonymize themselves.
     256     * Any remote code-execution vulnerability.
     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.)
     262     * Any memory-disclosure vulnerability.
     264     * Any means to impersonate a relay.
     266     * Any way for non-exit relays to get at user plaintext.
     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.)
     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.
     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.
     286      [TODO: Compare the above list with the categories in our bug
     287      bounty program.]
     2904. Can I show you my research findings in advance of disclosure? Or
     291   will you spoil my conference talk?
     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.
     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.
     302   We will *not* embargo an issue under any of the following
     303   circumstances:
     305      * The issue becomes public through other means, or somebody
     306        else finds it.
     308      * We have reason to believe that the issue is being exploited
     309        against real users in the wild.
     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.
     3175. Who will find out about non-public flaws?  When?
     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.
     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.
     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.
     331   (And of course, everybody will learn about the flaw when it becomes
     332   public.)
     3357. More Questions and answers.
     337  Q: Will you attribute bug reports and fixes?
     339  A: Yes.
     341  Q: How will you publicize issues and fixes?
     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.
     348     Packagers will get personal email.
     350     We will look into more ways to announce and publicize fixes and
     351     issues.
     353  Q: Will you get CVEs?
     355  A: Dunno.
     359A. Secondary contact info
     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.
     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!
     371      Tor:
     372         Nick Mathewson <>
     373               B35B F85B F194 89D0 4E28  C33C 2119 4EBB 1657 33EA
     375      Tor browser:
     376         Georg Koppen <>
     377               35CD 74C2 4A9B 15A1 9E1A  81A1 9437 3AA9 4B7C 3223
     379      Research director:
     380         Roger Dingledine <>
     381               F65C E37F 04BA 5B36 0AE6  EE17 C218 5258 19F7 8451
     384B. Acknowledgments
     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.
     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.
     395C. Open issues
     397   * How does this apply to censorship events?
     399-------- comments?