You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At least with #101 it is now possible to craft a malicious bytestring that, when peeked, results in an invalid data structure.
I think it should be documented that store must not be used to deserialize binary data from untrusted sources.
It also seems like it is in principle possible to "misinterpret" data that was encoded e.g. with different Store instances. Maybe the README and/or Haddocks should suggest using something like stacks VersionHash.
BTW cereal has intentionally used fromList to deserialize Maps etc since GaloisInc/cereal#20. I still believe that at least WRT stack, store makes the right speed-security-tradeoff now.
The text was updated successfully, but these errors were encountered:
On the other hand, it's nice to know that some things are safe to peek (e.g. reading some Int will definitely give you a value and will not crash your program). Can we document these security aspects by specifying both what's supposed to be safe and what's definitely not safe?
At least with #101 it is now possible to craft a malicious bytestring that, when peeked, results in an invalid data structure.
I think it should be documented that
store
must not be used to deserialize binary data from untrusted sources.It also seems like it is in principle possible to "misinterpret" data that was encoded e.g. with different
Store
instances. Maybe the README and/or Haddocks should suggest using something likestack
sVersionHash
.BTW
cereal
has intentionally usedfromList
to deserializeMap
s etc since GaloisInc/cereal#20. I still believe that at least WRTstack
, store makes the right speed-security-tradeoff now.The text was updated successfully, but these errors were encountered: