1. 40
  1. 8

    A path length which exceeds 1GB, holy moly!

    1. 1

      My thoughts, exactly.

    2. 8

      Relieved to see none of our devices are vulnerable by virtue of having less than 256Mb memory. There is such a thing as too much memory!

      1. 4

        Bill Gates was right!

        1. 7

          Gates himself has strenuously denied making the comment. In a newspaper column that he wrote in the mid-1990s, Gates responded to a student’s question about the quote: “I’ve said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time.” Later in the column, he added, “I keep bumping into that silly quotation attributed to me that says 640K of memory is enough. There’s never a citation; the quotation just floats like a rumor, repeated again and again.”


          1. 4

            The first time I heard this quote it was ‘64 K ought to be enough for anyone’. It was in reference to the fact that Microsoft BASIC had some fixed limits that made it impossible for it to support more than 64 KiB of RAM (some types had to be 16 bits, irrespective of the architecture that you ported it to, and on the 8086 / 8088 this limit still held because the 16-bit assumption was so ingrained in the codebase that removing it would have been close to a full rewrite). Some years later, I heard the 640 K version, which didn’t really make sense to me because that was an Intel-imposed limitation, not a Microsoft-imposed one.

            Bill Gates has always denied the 640 K version and I’ve always wondered if he’s so vocal about denying that he said ‘640 K ought to be enough for anyone’ to obscure the fact that he actually said ‘64 K ought to be enough for anyone’.

            1. 4

              Doesn’t matter; still funny.

        2. 4

          Pleased to find that Sandstorm blocks this, by two different mechanisms (no /proc and no userns).

          user namespaces in particular introduced a massive amount of new attack surface, and when it came out there was a flurry of privilege escalation vulnerabilities related to it – all sorts of kernel interfaces that were previously only accessible by root (such as unmount() in this case) that all of a sudden are potentially exposed to untrusted users.

          1. 2

            Does Sandstorm block the attack or only the POC ?

            1. 2

              IIUC it should block all forms of the attack – this requires being able to access virtual files backed by seq_file, and we don’t expose any of those to apps – just disk files and /dev/{null,zero,{u,}random}

              Edit: we do bind-mount /proc/cpuinfo, which I’m not sure whether it’s backed by seq_file, but the app shouldn’t be able to affect its contents, so I would be very surprised if that changed anything.

            2. 2

              You’re correct, but I think it’s important to add that in the long term user namespaces will enhance security a great deal.

            3. 4

              Am I misunderstanding things, or am I right in guessing that this is currently exploitable in the majority of actively running Linux instances [which have not been updated yet]? If so, it seems irresponsible to disclose this so soon.

              1. 2

                Wow, what a nice writeup! The visualizations and program slices helped explain things without requiring switching to the code and mentally tracking the state of things. Many other security writeups require more familiarity with the codebase, but I was able to follow along with this explanation easily.

                1. 1

                  I’m curious if this affects any BSD kernels.

                  1. 1

                    That’s a very thorough explanation.