Opened 2 years ago

Last modified 6 months ago

#22962 assigned task

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

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

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 (11)

comment:1 Changed 2 years 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 2 years ago by nickm

Keywords: policy added

comment:3 Changed 2 years ago by nickm

Sponsor: SponsorV

comment:4 Changed 2 years ago by nickm

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

comment:5 Changed 2 years 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 2 years 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 2 years 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 21 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.

comment:9 Changed 6 months ago by gaba

Removing sponsor V as we do not have more time to include this tickets in the sponsor.

comment:10 Changed 6 months ago by gaba

Sponsor: SponsorV

Removing sponsor from tickets that we do not have time to fit in the remain of this sponsorship.

comment:11 Changed 6 months ago by nickm

Owner: nickm deleted
Status: acceptedassigned

These tickets are not things I'm currently working on. They may be important, but they don't need to be done by me specifically. Un-assigning.

Note: See TracTickets for help on using tickets.