1. 27
  1.  

  2. 9

    The author of this post isn’t properly characterizing langsec:

    The basis of language security is starting from a programming language with a well-defined, easy-to-understand semantics. … This approach is taken, for example, by Google’s Caja compiler to isolate components from each other, even when they run in the context of the same web page.

    From what I can tell, he’s talking about the broader area of “programming languages and security”. That is not the same thing as http://langsec.org/, which is essentially about using grammars to recognize network protocol formats and file formats.

    As far as I remember, one motivating vulnerability is that there were two different parsers for SSL certificates, which allowed attackers to trick browsers into accepting invalid certificates. That doesn’t have anything to do with programming languages per se; you can write this vulnerability in any language. It’s analogous to the fact that using a memory safe language doesn’t prevent you from SQL injection.

    Some examples of what they are trying to address:

    http://langsec.org/papers/langsec-cwes-secdev2016.pdf

    I wrote a critique of langsec a few months ago here:

    https://lobste.rs/s/uyjzjc/science_insecurity_meredith_l_pat

    tl;dr I think they are using the wrong formalisms.

    I found it odd that the author was assuming that langsec is a widely used thing when I think it is nascent research.

    Even Google Caja, a totally different project outside of langsec, is not widely deployed, although I very much like its ideas.

    (copy of https://news.ycombinator.com/item?id=16126234)

    1. 4

      I could be misusing the term, but people have been using “langsec” to talk about the broader “programming languages and security” for a long time, apparently since before langsec.org started using the term; see e.g. https://www.cs.cmu.edu/~rwh/papers/langsec/dagstuhl.pdf from 1999-2001.

    2. 3

      Thanks for this submission. My hunch is that an architecture which makes e.g. caching and speculative execution an observable part of the API is the better approach. Afaiu mips does something similar and compilers learned to deal with it.

      1. 1

        My own hunch is that we should be avoiding impure operations like getting the current time.

        This post seems to be talking about trusting high-assurance languages for critical/sensitive tasks, and how those guarantees can be undermined if we run arbitrary machine code. That problem seems too difficult to me: surely a better langsec approach would be for the arbitrary code to be in a high-assurance language, with the only machine code we execute coming from trusted critical/sensitive programs?

        I would think a langsec approach to e.g. preventing timing attacks in Javascript is to make Javascript (the language) incapable of timing. Or, at least, providing a logical clock (also used for the interleaving of concurrent event handlers) rather than allowing access to the actual time.

        1. 2

          For the vast majority of uses of a computer at some point the application will need to know what time it is. Avoiding impure operations is throwing up your hands on general computing as a useful tool. I don’t think this is quite what you meant to say though. Can you clarify?

          1. 2

            The clock is a sensor and needs to be treated as such with permissions and similar. Many applications don’t have a need for the clock.

        2. -2

          It is, after all, a truth universally acknowledged, that a program with good use of data types, will be free from many common bugs.

          I’m afraid it is only so for the value of “universally” meaning “other fans of type safety”. And that’s a rather constrained subset.

          1. 2

            A language being free from a many common bugs does indeed change the set of common bugs for that language. But that doesn’t mean that it is indeed free from many common bugs of the languages without those safety features. You absolutely do gain a certain amount of safety the stronger your type system is and that does provide a fair amount of value that shouldn’t be dismissed just because there are still possible bugs. Type systems in many cases manage to push the remaining bugs into the “spec”. Which has the benefit of allowing you to fix the bug by fixing the spec and then having a compiler tell that you have indeed actually fixed said bug.

            For developers who can leverage this power it’s really useful and increases productivity. For those who can’t yet leverage this power it just feels like the language is slowing you down.

            1. 0

              I’m not trying to discuss the issue itself, I’m pointing out that that “truth” is not universally accepted, not even close.

              Talking about the issue, one of the assumption by type safety advocates I have qualms with is the word “many” here:

              A language being free from a many common bugs does indeed change the set of common bugs

              Another is this implied assumption that any gain in safety is good, without considering the disadvantages:

              You absolutely do gain a certain amount of safety the stronger your type system is and that does provide a fair amount of value that shouldn’t be dismissed just because there are still possible bugs.

              This is trivialization of the opposing view. Strong type safety system may be dismissed not because “there are still possible bugs” but because on balance they remove too few for too much effort. Simple as that.

              1. 1

                you’re shifting the goalposts a little. Sure, maybe the balance of safety versus effort is not worth it for you. But that doesn’t mean that there isn’t a much smaller set of bugs with type safety than without, all else being equal.