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

Audit for use of size_hint coming from untrusted data #744

Closed
dtolnay opened this issue Feb 3, 2017 · 5 comments
Closed

Audit for use of size_hint coming from untrusted data #744

dtolnay opened this issue Feb 3, 2017 · 5 comments
Labels

Comments

@dtolnay
Copy link
Member

dtolnay commented Feb 3, 2017

@nox pointed out in IRC that Bincode sequence and map deserializers provide a size_hint that comes straight from the input, and untrusted Bincode data could put a fake large number there. If a Deserialize type takes that hint and uses it for Vec::with_capacity, it could be bad.

Let's look through existing formats to see how prevalent this is and try to come up with guidelines for avoiding this problem.

@dtolnay dtolnay added the bug label Feb 3, 2017
@sfackler
Copy link
Contributor

sfackler commented Feb 3, 2017

See rust-lang-deprecated/rustc-serialize#150 for some similar discussion.

@oli-obk
Copy link
Member

oli-obk commented Feb 19, 2017

we can never protect against oom. If enough data comes from a stream, we will end up allocating too much memory at some point.

@oli-obk
Copy link
Member

oli-obk commented Feb 19, 2017

do bincode and similar check whether the number of hinted elements is also the number of deserialized elements? Otherwise another attack is to always suggest 4096 elements (or whatever the limit is), and only deserialize one element. Since the allocations are never shrunk, we waste a lot of memory.

@nox
Copy link
Contributor

nox commented Feb 19, 2017

Bincode can only succeed if 4096 elements were deserialised in that case.

@dtolnay
Copy link
Member Author

dtolnay commented May 7, 2018

Let's continue to track this under #850.

@dtolnay dtolnay closed this as completed May 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

4 participants