Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harden untrusted genesis file consumption #7919

Open
ryoqun opened this issue Jan 22, 2020 · 5 comments
Open

Harden untrusted genesis file consumption #7919

ryoqun opened this issue Jan 22, 2020 · 5 comments
Labels
security Pull requests that address a security vulnerability
Milestone

Comments

@ryoqun
Copy link
Member

ryoqun commented Jan 22, 2020

Problem

Like #7167, as HTTP/GET-ed genesis files can not be trusted, its deserialization and handling should be hardened. At least, before genesis hash check is done.

TBD

Proposed Solution

Just redo similar measured as #7167?

TBD

@ryoqun ryoqun added the security Pull requests that address a security vulnerability label Jan 22, 2020
@mvines mvines added this to the Rincon v0.24.0 milestone Jan 22, 2020
@mvines mvines modified the milestones: Rincon v0.24.0, v0.25.0 Feb 20, 2020
@ryoqun
Copy link
Member Author

ryoqun commented Feb 25, 2020

As guessed this will happen someday, this became a real issue now: #8427

@ryoqun
Copy link
Member Author

ryoqun commented Mar 24, 2020

Also, like this #7167 (comment), we're currently challenged to sanitize bunch of rocksdb binary files which cannot be trusted at all and can be tampered in any arbitrary way. I'll suspect rocksdb are prepared to combat off that attack surface. So, we're forced to transition to some DDL emitter for genesis instead of carrying a tiny rocksdb instance or completely outplace it. :)

@mvines
Copy link
Member

mvines commented Mar 24, 2020

I'd like to remove (more practically just ignore rocksdb/) in genesis entirely. It's superfluous, genesis.bin is all that matters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security Pull requests that address a security vulnerability
Projects
None yet
Development

No branches or pull requests

3 participants