Opened 17 months ago

Last modified 9 months ago

#22962 accepted task

Clarify the security severity of issues that make denial of service easier

Reported by: teor Owned by: nickm
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: docs policy
Cc: Actual Points:
Parent ID: #22948 Points:
Reviewer: Sponsor: SponsorV

Description

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy

In #22948, we discovered that the relay integrity digest was easier to guess than it should be. This makes the following classes of attacks easier:

  • sending bandwidth and guessing the integrity digest, and
  • modifying cells and manipulating the integrity digest.

Child Tickets

Change History (8)

comment:1 Changed 15 months ago by nickm

Keywords: docs added

add the "docs" keyword to tickets that are documentation-only, and can enter Tor post-freeze.

comment:2 Changed 15 months ago by nickm

Keywords: policy added

comment:3 Changed 14 months ago by nickm

Sponsor: SponsorV

comment:4 Changed 13 months ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final
Owner: set to nickm
Status: newaccepted

comment:5 Changed 13 months ago by nickm

I think we should follow the lead of OpenSSL, and split "HIGH" into "HIGH" and "CRITICAL".

Here's my back-of-the-envelope attempt to do the division, of the categories currently in "HIGH".

These should be "HIGH":

Any remote crash attack against hidden services. (This includes unfreed memory and other resource exhaustion attacks that can lead to denial-of-service.)
Any memory-disclosure vulnerability.

These should be "CRITICAL":

Any bug that can remotely cause clients to de-anonymize themselves.
Any remote code-execution vulnerability.
Any bug that allows impersonation of a relay. (If someone accesses a relay's keys, and it's not due to a bug in tor, we deal with that through the bad-relays process.)
Any bug that lets non-exit relays get at user plaintext.
Any privilege escalation from a Tor user to the higher-privileged user that started the Tor process. (For example, if Tor is started by root and told to drop privileges with the User flag, any ability to regain root privileges would be high-severity.)

And I think we should be more explicit that we may revise severities upwards or downwards depending on specifics of the issue.

comment:6 Changed 13 months ago by teor

Seems sensible to me.
Are we worried that memory disclosure vulnerabilities will ever de-anonymise users?
Remote crashes against clients aren't in our existing list, should they be high or critical?

The last sentence in the critical section should read "… any ability to regain root privileges would be critical-severity."

comment:7 Changed 13 months ago by nickm

Are we worried that memory disclosure vulnerabilities will ever de-anonymise users?

Well, when I think of memory disclosure, in the worst case I think of Heartbleed. That could have de-anonymized users FWICT.

Remote crashes against clients aren't in our existing list, should they be high or critical?

Hm. I would say "high". What would others say?

The last sentence in the critical section should read "… any ability to regain root privileges would be critical-severity."

Agreed.

comment:8 Changed 9 months ago by nickm

Milestone: Tor: 0.3.3.x-finalTor: unspecified

We've had the existing definitions for a while, and they doesn't seem to have actually caused confusion in practice. I did this part on the wiki page:

And I think we should be more explicit that we may revise severities upwards or downwards depending on specifics of the issue.

but I'm going to move this ticket into Undecided for now.

Note: See TracTickets for help on using tickets.