5 ms·

I think one of the most desirable and under-appreciated goals of schema languages and serialization formats is safety. These tools are typically used in places

I think one of the most desirable and under-appreciated goals of schema languages and serialization formats is safety. These tools are typically used in places that deal with untrusted inputs, and features and design choices can go a long way in either exposing or shielding developers from potential safety bugs. My read of Cap’n’Proto didn’t make it sound that safety was the highest priority. At least not above performance.

signa11 3y ago
hmm, i don’t understand how schema-languages can do anything about that though. afterall, you just serialize/de-serialize based on provided inputs, GIGO if you will. safety w.r.t bad/malicious inputs should be a ‘higher level’ concern afaik.
- jiggawatts 3y ago
  Safety means: garbage in, error out.
  - signa11 3y ago
    right, and it should not be left to the serialization layer for that.
    - afiori 3y ago
      it depends on what type of safety. The schema language might for example allow you to specify that an input string/blob should be smaller than 10MB and refuse to deserialize it if it is longer, same for array/list/vector length.
      - seangrogg 3y ago
        It feels like a check against an input size of 10MB is something you would do well before deserialization, no?
        tom_ 3y ago
        The limit might apply to some specific part of the message, rather than the whole. You can't check this without actually deserialising, or at least doing most of the same work.
        baq 3y ago
        You would, but others might not. Defense in depth.
        afiori 3y ago
        not if it is a message you receive from a third party. A concrete example might be a batching third party client: the app sends N messages in a single batch and each message has its own size limit.
      - signa11 3y ago
        > ... allow you to specify that an input string/blob should be smaller than 10MB and refuse to deserialize it if it is longer ... why ? are there no cases where serializing even larger file is valid ?
        afiori 3y ago
        sure, a lot of cases, I suspect that S3 upload limits are different from imgur.
        signa11 3y ago
        and feel free to do that in _your_ application. don’t shackle others with the limitations of your domain. mechanism vs policy and all that.
        afiori 3y ago
        I believe I have already justified why it might be useful at the protocol/schema level in ways that cannot be replicated at the application level: to eagerly fail on expensive (eg memory) deserialization.
    - jiggawatts 3y ago
      Security is a concern for every layer. It's not magic pixie dust that' can be sprinkled on top of software to renders it secure! A while ago I read a great article about how the Adobe PDF serialization format is nearly impossible to secure because it allows inherently unsafe constructs. For example, it allows cross-references that are basically just arbitrary unaligned pointers. It uses many different alignment and padding algorithms. It has length-prefixed and not-length prefixed sections. Etc, etc... Apparently it was a serious research exercise to make a safe PDF parser, and they only covered a fraction of the full spec! To put things in perspective: Originally, PDF allowed arbitrary code execution as a core feature, allowing the output of shell commands to be used as document content. Most people like the Chromium and Firefox teams have just given up and now parse PDF using a sandboxed JavaScript VM because it's too hard to do it safely with C++. They parse HTML and JavaScript with C++, but not PDF. Think about that. A similar issue caused Log4j, where a "format string parser" contained a vulnerability because it was too flexible and allowed network requests to be triggered by user-controlled data. Even trivial, "surely it must be safe" formats like XML and JSON are riddled with security issues, such as different layers in a microservice architecture having different handling semantics for duplicate keys, null values, etc... This can result in exploits such as authentication and authorization tokens being interpreted by a system one way, but a different way by a different system. For real-world attacks along these lines, search for "request smuggling". Serialization and parsing are security minefields and it is dangerously naive to just hand-wave that away. See: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
      - signa11 3y ago
        > Serialization and parsing are security minefields and it is dangerously naive to just hand-wave that away. well, i am not hand-waving them away, i am not sure what can the serialization framework possibly _do_ to make things secure during the serialization ? when execution of user-supplied code is allowed (in the examples that you have outlined above), surely, the layer _executing_ the code cannot really do anything about it ! perhaps you actually did intend to `rm -rf /` ? policy checking, enforcement etc. has to happen at a higher / different layer. i am not sure why mechanism and policy are being conflated here. in the same way, you gave the serialization layer a 10mb or whatever sized input to serialize, sure...you get an valid serialized output etc. maybe there is a genuine usecase for that in some context or another f.e. when serializing say image files, or something else etc. etc. [edit] : minor comment.
    - formerly_proven 3y ago
      Disregard for safety and security in serialization is one of the most common, if not the most common, cause for security vulnerabilities.
woodruffw 3y ago
I agree entirely, and this is one of my single greatest frustrations with the majority of the current popular IDLs/schema languages. ASN.1 is hilariously bad in a lot of ways, but one thing it gets absolutely right is strong typing and being able to express constraints (ranges, values dependent on other values). That combined with a canonicalized encoding form (DER) goes a long way in making various error states unrepresentable.
- debugnik 3y ago
  Is there a reasonable subset of ASN.1 that could get traction nowadays if specified separately?
  - woodruffw 3y ago
    There’s a wide set of best practices (use only DER for encoding, avoid legacy string types, etc.) that are widely applied in cryptographic applications, although I don’t know if anybody has written them down explicitly. More generally: this wasn’t intended to be an endorsement of ASN.1 per se! It was only to say that it got some things right, things that Cap’n Proto and Protobuf appear to have eschewed. I’m not sure it is the right IDL for modern purposes, but I think it’s a useful piece of reference material.
- bsder 3y ago
  Except that ASN.1 is egregiously terrible at being able to be checked for wonky values due to complex parsing. Exactly how many vulnerabilities have been exploited in LDAP, SNMP, etc. because ASN.1 is so terrible?
  - woodruffw 3y ago
    ASN.1 isn’t an encoding; DER is. The problem with LDAP, etc. is that they all permit BER, which is a looser superset of DER. It includes (among other things) the ability to represent indefinite-length fields, which are the single biggest source of exploitable bugs in a typical application of ASN.1. Without that, the exploitable surface of DER is much smaller (and especially when implemented in a memory-safe language).
nullc 3y ago
> and serialization formats is safety. These tools are typically used in places that deal with untrusted inputs, and features and design choices can go a long way in either exposing or shielding developers from potential safety bugs My potentially incorrect understanding is that Cap'n Proto's zero copy nature means the serialization format IS the in-memory representation, which means that if you build a Cap'n Proto object on top of non-zeroed memory you can leak data in the padding when transmitting. [Presumably not an issue if the packed encoding is used rather than the zero-copy one]
- nly 3y ago
  It's only zero copy to parse/read. The builders allocate all over the place.
  - kentonv 3y ago
    A MessageBuilder allocates a single large buffer, writes into it, and only allocates further if that buffer is exhausted. If you use a preallocated buffer you can avoid allocation entirely. Very different from Protobuf which allocates strings, arrays, and sub-messages all as separate heap objects.
gizmo686 3y ago
Check out DFDL/Apache Daffodil. [0] a large portion of the development team is working on it specifically for use in a cybersecurity context. (Disclaimer, I was one such contributer. Although am presently not working on Daffodil). Having said that, DFDL fails pretty miserably by the standards set in the article. The main design goal was to be able to describe as many existing data formats as possible, which means the spec is massive and supports a lot of bad ideas. Despite having its 1.0 release in 2015, and being the most complete implementation, Apache Daffodil still does not fully implement the DFDL spec. And it is not an easy code base to jump into and understand. [0] https://daffodil.apache.org/ https://daffodil.apache.org/
kentonv 3y ago
With all due respect, you read completely wrong. * The very first use case for which Cap'n Proto was designed was to be the protocol that Sandstorm.io used to talk between sandbox and supervisor -- an explicitly adversarial security scenario. * The documentation explicitly calls out how implementations should manage resource exhaustion problems like deep recursion depth (stack overflow risk), were many serialization formats leave these things as the app's problem. * The implementation has been fuzz-tested multiple ways, including as part of Google's oss-fuzz. * When there are security bugs, I issue advisories like this: https://github.com/capnproto/capnproto/tree/v2/security-advisories https://github.com/capnproto/capnproto/tree/v2/security-advi... * The primary aim of the entire project is to be a Capability-Based Security RPC protocol. That's what "Cap" in the name comes from. The zero-copy serialization is actually a bonus feature. (I'm the author of Cap'n Proto.)

signa11 3y ago

hmm, i don’t understand how schema-languages can do anything about that though. afterall, you just serialize/de-serialize based on provided inputs, GIGO if you will. safety w.r.t bad/malicious inputs should be a ‘higher level’ concern afaik.

jiggawatts 3y ago
Safety means: garbage in, error out.
- signa11 3y ago
  right, and it should not be left to the serialization layer for that.
  - afiori 3y ago
    it depends on what type of safety. The schema language might for example allow you to specify that an input string/blob should be smaller than 10MB and refuse to deserialize it if it is longer, same for array/list/vector length.
    - seangrogg 3y ago
      It feels like a check against an input size of 10MB is something you would do well before deserialization, no?
      - tom_ 3y ago
        The limit might apply to some specific part of the message, rather than the whole. You can't check this without actually deserialising, or at least doing most of the same work.
      - baq 3y ago
        You would, but others might not. Defense in depth.
      - afiori 3y ago
        not if it is a message you receive from a third party. A concrete example might be a batching third party client: the app sends N messages in a single batch and each message has its own size limit.
    - signa11 3y ago
      > ... allow you to specify that an input string/blob should be smaller than 10MB and refuse to deserialize it if it is longer ... why ? are there no cases where serializing even larger file is valid ?
      - afiori 3y ago
        sure, a lot of cases, I suspect that S3 upload limits are different from imgur.
        signa11 3y ago
        and feel free to do that in _your_ application. don’t shackle others with the limitations of your domain. mechanism vs policy and all that.
        afiori 3y ago
        I believe I have already justified why it might be useful at the protocol/schema level in ways that cannot be replicated at the application level: to eagerly fail on expensive (eg memory) deserialization.
  - jiggawatts 3y ago
    Security is a concern for every layer. It's not magic pixie dust that' can be sprinkled on top of software to renders it secure! A while ago I read a great article about how the Adobe PDF serialization format is nearly impossible to secure because it allows inherently unsafe constructs. For example, it allows cross-references that are basically just arbitrary unaligned pointers. It uses many different alignment and padding algorithms. It has length-prefixed and not-length prefixed sections. Etc, etc... Apparently it was a serious research exercise to make a safe PDF parser, and they only covered a fraction of the full spec! To put things in perspective: Originally, PDF allowed arbitrary code execution as a core feature, allowing the output of shell commands to be used as document content. Most people like the Chromium and Firefox teams have just given up and now parse PDF using a sandboxed JavaScript VM because it's too hard to do it safely with C++. They parse HTML and JavaScript with C++, but not PDF. Think about that. A similar issue caused Log4j, where a "format string parser" contained a vulnerability because it was too flexible and allowed network requests to be triggered by user-controlled data. Even trivial, "surely it must be safe" formats like XML and JSON are riddled with security issues, such as different layers in a microservice architecture having different handling semantics for duplicate keys, null values, etc... This can result in exploits such as authentication and authorization tokens being interpreted by a system one way, but a different way by a different system. For real-world attacks along these lines, search for "request smuggling". Serialization and parsing are security minefields and it is dangerously naive to just hand-wave that away. See: https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
    - signa11 3y ago
      > Serialization and parsing are security minefields and it is dangerously naive to just hand-wave that away. well, i am not hand-waving them away, i am not sure what can the serialization framework possibly _do_ to make things secure during the serialization ? when execution of user-supplied code is allowed (in the examples that you have outlined above), surely, the layer _executing_ the code cannot really do anything about it ! perhaps you actually did intend to `rm -rf /` ? policy checking, enforcement etc. has to happen at a higher / different layer. i am not sure why mechanism and policy are being conflated here. in the same way, you gave the serialization layer a 10mb or whatever sized input to serialize, sure...you get an valid serialized output etc. maybe there is a genuine usecase for that in some context or another f.e. when serializing say image files, or something else etc. etc. [edit] : minor comment.
  - formerly_proven 3y ago
    Disregard for safety and security in serialization is one of the most common, if not the most common, cause for security vulnerabilities.

woodruffw 3y ago

I agree entirely, and this is one of my single greatest frustrations with the majority of the current popular IDLs/schema languages. ASN.1 is hilariously bad in a lot of ways, but one thing it gets absolutely right is strong typing and being able to express constraints (ranges, values dependent on other values). That combined with a canonicalized encoding form (DER) goes a long way in making various error states unrepresentable.

debugnik 3y ago
Is there a reasonable subset of ASN.1 that could get traction nowadays if specified separately?
- woodruffw 3y ago
  There’s a wide set of best practices (use only DER for encoding, avoid legacy string types, etc.) that are widely applied in cryptographic applications, although I don’t know if anybody has written them down explicitly. More generally: this wasn’t intended to be an endorsement of ASN.1 per se! It was only to say that it got some things right, things that Cap’n Proto and Protobuf appear to have eschewed. I’m not sure it is the right IDL for modern purposes, but I think it’s a useful piece of reference material.
bsder 3y ago
Except that ASN.1 is egregiously terrible at being able to be checked for wonky values due to complex parsing. Exactly how many vulnerabilities have been exploited in LDAP, SNMP, etc. because ASN.1 is so terrible?
- woodruffw 3y ago
  ASN.1 isn’t an encoding; DER is. The problem with LDAP, etc. is that they all permit BER, which is a looser superset of DER. It includes (among other things) the ability to represent indefinite-length fields, which are the single biggest source of exploitable bugs in a typical application of ASN.1. Without that, the exploitable surface of DER is much smaller (and especially when implemented in a memory-safe language).

nullc 3y ago

> and serialization formats is safety. These tools are typically used in places that deal with untrusted inputs, and features and design choices can go a long way in either exposing or shielding developers from potential safety bugs My potentially incorrect understanding is that Cap'n Proto's zero copy nature means the serialization format IS the in-memory representation, which means that if you build a Cap'n Proto object on top of non-zeroed memory you can leak data in the padding when transmitting. [Presumably not an issue if the packed encoding is used rather than the zero-copy one]

nly 3y ago
It's only zero copy to parse/read. The builders allocate all over the place.
- kentonv 3y ago
  A MessageBuilder allocates a single large buffer, writes into it, and only allocates further if that buffer is exhausted. If you use a preallocated buffer you can avoid allocation entirely. Very different from Protobuf which allocates strings, arrays, and sub-messages all as separate heap objects.

gizmo686 3y ago

Check out DFDL/Apache Daffodil. [0] a large portion of the development team is working on it specifically for use in a cybersecurity context. (Disclaimer, I was one such contributer. Although am presently not working on Daffodil). Having said that, DFDL fails pretty miserably by the standards set in the article. The main design goal was to be able to describe as many existing data formats as possible, which means the spec is massive and supports a lot of bad ideas. Despite having its 1.0 release in 2015, and being the most complete implementation, Apache Daffodil still does not fully implement the DFDL spec. And it is not an easy code base to jump into and understand. [0] https://daffodil.apache.org/ https://daffodil.apache.org/

kentonv 3y ago

With all due respect, you read completely wrong. * The very first use case for which Cap'n Proto was designed was to be the protocol that Sandstorm.io used to talk between sandbox and supervisor -- an explicitly adversarial security scenario. * The documentation explicitly calls out how implementations should manage resource exhaustion problems like deep recursion depth (stack overflow risk), were many serialization formats leave these things as the app's problem. * The implementation has been fuzz-tested multiple ways, including as part of Google's oss-fuzz. * When there are security bugs, I issue advisories like this: https://github.com/capnproto/capnproto/tree/v2/security-advisories https://github.com/capnproto/capnproto/tree/v2/security-advi... * The primary aim of the entire project is to be a Capability-Based Security RPC protocol. That's what "Cap" in the name comes from. The zero-copy serialization is actually a bonus feature. (I'm the author of Cap'n Proto.)