Guard history subsystem against corrupt data

Open
#511 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
cpp
Domain
distributed-systems

Research direction

Start by tracing the history subsystem around XDRInputFileStream::readOne and the handling of xdr::xdr_runtime_error. Inspect related history-data paths for additional malformed-input resource conditions; done means bad history data no longer crashes nodes or causes excessive downloading and processing.

Written by the indexing model from the issue text.

Description

Couple things that we don't seem to do much about:

  1. no guard for xdr::xdr_runtime_error that is thrown when an xdr object cannot be de-serialized

  2. no check for abnormally large objects XDRInputFileStream::readOne will happily accept objects that are 2GB

  3. will crash nodes depending on the bad data

  4. will also crash nodes but after spending a lot of time downloading bogus data

There are probably more conditions that may lead to nodes spending extraordinary amount of resources when facing bad data stored in history. (note that the bad dataset could be there by accident/bug, not just because of an active attack).

Dominant language
C++
Stars
3.3k
Forks
1.1k
Avg merge
3d 16h
Merged PRs (30d)
14

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from stellar/stellar-core

All issues in stellar/stellar-core

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.