Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 342
    • Issues 342
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 39
    • Merge requests 39
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #40304
Closed
Open
Issue created Feb 19, 2021 by Nick Mathewson@nickm🐉Owner

TROVE-2021-001: Bug in dump_desc() code

The dump_desc() code dumps its entire input, but it is sometimes called with an input that extends beyond the end of the string.

This can cause two kinds of bugs:

  • A CPU-based DOS bug, where we try to parse a string that contains a zillion tiny unparseable descriptors.
  • Possibly, an unbounded read bug, where we read off the end of an allocation. The latter is not a privacy leak, since we don't expose the data, but it could be a crash bug. (I think it might not even be a crash bug, since we NUL-terminate our downloads, but we should check.)

For 0.3.5 through 0.4.4, I believe we should just disable dump_desc().

For a real fix, we should give it a length argument.

Edited Feb 19, 2021 by Nick Mathewson
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking