Binaries mitigations

[Andrew Herbert]

How true/false are these allegations?

Anyone can easily verify this by downloading the binaries, and running checksec themselves.

Here's the output:

Code: Select all

$ sha256sum palemoon-bin
    0b7f4ad73fc671e20bfb2366aa9d9ad81e82a3c8f63acde7f37063e73fda2141  palemoon-bin

    $ checksec --file=./palemoon-bin --output=json --extended | jq 
    {
      "./palemoon-bin": {
        "relro": "partial",
        "canary": "no",
        "nx": "yes",
        "pie": "no",
        "clangcfi": "no",
        "safestack": "no",
        "rpath": "no",
        "runpath": "no",
        "symbols": "no",
        "fortify_source": "no",
        "fortified": "0",
        "fortify-able": "15"
      }
    }

Notably, the binary has not been compiled with -fPIE and -fstack-protector, which disables two very basic exploit mitigations - ASLR and stack canaries. Any self-respecting Linux distribution enables these compiler flags by default nowadays. -D_FORTIFY_SOURCE is also missing, unlike Chrome or Firefox. A modern browser uses dozens of custom binary exploitation mitigations in addition to this.

Mitigations and sandboxing are the difference between an exploit a CTF player can write on an afternoon, and a multi-month expert-level endeavour.

[Lunokhod]

libxul.so is built with fortify_source apparently, so not all the binaries that make up Pale Moon seem to be the same. That does make bigger (and probably slower) binaries I have noticed in the past. Interesting.

Code: Select all

$ checksec --file=./libxul.so --output=json --extended |jq
{
  "./libxul.so": {
    "relro": "partial",
    "canary": "yes",
    "nx": "yes",
    "pie": "dso",
    "clangcfi": "no",
    "safestack": "no",
    "rpath": "no",
    "runpath": "no",
    "symbols": "no",
    "fortify_source": "yes",
    "fortified": "0",
    "fortify-able": "26"
  }
}

[Moonchild]

The Pale Moon binary itself doesn't have much to it. it is simply the component glue and application launch shell. All effectively potentially exploitable code will be in the libs, primarily libxul.so -- which as pointed out is built with fortify_source as well as pie:dso.
Using pie on the executable binary "runner" is problematic because pie, as far as I understood the mechanism, only properly works on (dynamically loaded) libraries, and several people who have tried building with it globally have run into compatibility issues due to that.

So people can jump to conclusions and scream about it not being used on palemoon-bin, but as you can see it's once again allegations with a biased and poorly informed foundation.
This is why people, before they write articles, especially about security, should always verify their "facts" and sources -- unless of course it is their sole purpose to try and paint black in which case it's expected, and about as sensationalist as your average tabloid.