4 ms·

What are the security implications? It sounds like they might be feeding the config text directly into Serde - which means allowing potentially untrusted user i

What are the security implications? It sounds like they might be feeding the config text directly into Serde - which means allowing potentially untrusted user input to instantiate arbitrary structs. That's a big attack surface.

chrismorgan 4y ago
None. Serde is strongly, strictly typed: you have to specify what type you want to decode to. It’s nothing like Python’s Pickle protocol. See, for example, https://github.com/ron-rs/ron/blob/484fcab0686dfd18c7e29b6c1815c5f74f6c6db4/examples/decode_file.rs#L27 https://github.com/ron-rs/ron/blob/484fcab0686dfd18c7e29b6c1..., where it (in a type-inferency way) says “parse as Config”.
- tetromino_ 4y ago
  I appreciate the response, but the link you gave only states that the value returned by from_reader is strongly typed; it says nothing about what from_reader might be doing internally before it returns that value. The actual answer seems to be https://github.com/serde-rs/serde/issues/1087#issuecomment-343030233 https://github.com/serde-rs/serde/issues/1087#issuecomment-3... - no security implications if no manually implemented Deserialize impls linked to by your application have security implications.
  - chrismorgan 4y ago
    Well that’s just common sense. You write the deserialiser, it’s your responsibility. It’s no security implication in Serde or Ron.
    - tetromino_ 4y ago
      The interesting part is that it's also your responsibility to audit deserializer code in your dependencies.
      - chrismorgan 4y ago
        That’s still just a normal aspect of code. If you care about security, you have to audit all your dependencies. Security concerns in deserialising come about due to the input being able to control things, things like Python’s Pickle protocol where you get arbitrary object instantiation and function calls, even of things like os.system (pickle.loads(b"cos\nsystem\n(S'echo ACE'\ntR.")). Security cannot reasonably be retrofitted to such a model. With the likes of Serde (and indeed structural serialisers/deserialisers in practically every ahead-of-time-compiled language), this isn’t an issue: only the code controls things, and only types that declare a way of deserialising can be deserialised to.

chrismorgan 4y ago

None. Serde is strongly, strictly typed: you have to specify what type you want to decode to. It’s nothing like Python’s Pickle protocol. See, for example, https://github.com/ron-rs/ron/blob/484fcab0686dfd18c7e29b6c1815c5f74f6c6db4/examples/decode_file.rs#L27 https://github.com/ron-rs/ron/blob/484fcab0686dfd18c7e29b6c1..., where it (in a type-inferency way) says “parse as Config”.

tetromino_ 4y ago
I appreciate the response, but the link you gave only states that the value returned by from_reader is strongly typed; it says nothing about what from_reader might be doing internally before it returns that value. The actual answer seems to be https://github.com/serde-rs/serde/issues/1087#issuecomment-343030233 https://github.com/serde-rs/serde/issues/1087#issuecomment-3... - no security implications if no manually implemented Deserialize impls linked to by your application have security implications.
- chrismorgan 4y ago
  Well that’s just common sense. You write the deserialiser, it’s your responsibility. It’s no security implication in Serde or Ron.
  - tetromino_ 4y ago
    The interesting part is that it's also your responsibility to audit deserializer code in your dependencies.
    - chrismorgan 4y ago
      That’s still just a normal aspect of code. If you care about security, you have to audit all your dependencies. Security concerns in deserialising come about due to the input being able to control things, things like Python’s Pickle protocol where you get arbitrary object instantiation and function calls, even of things like os.system (pickle.loads(b"cos\nsystem\n(S'echo ACE'\ntR.")). Security cannot reasonably be retrofitted to such a model. With the likes of Serde (and indeed structural serialisers/deserialisers in practically every ahead-of-time-compiled language), this isn’t an issue: only the code controls things, and only types that declare a way of deserialising can be deserialised to.