Enable stack protection (CI release executables)

[nicowilliams]

Resolves #1514.

[nicowilliams]

-mshstk didn't work, though I'm sure it would work if we only use clang. I suppose we could switch to clang for this. Also, I should enable this for OS X and for Windows too.

[wader]

Doh i somehow assumed -fsanitize=safe-stack was clang's versions of -fstack-protector-all but seems to be two different stack protection techniques.

I still haven't managed to get -fsanitize=safe-stack to work for darwin x86, but do seems to work on linux 🤷

[wader]

I think this is good enough for 1.7. It would be great post 1.7 to provide these things using configure options somehow.

[itchyny]

Did you check the executables built on CI to make sure hardening-check?

[nicowilliams]

Did you check the executables built on CI to make sure hardening-check?

Not yet. Though, hmm, how would I? Use a debugger to try to force a buffer overflow?

[wader]

Did you check the executables built on CI to make sure hardening-check?

Not yet. Though, hmm, how would I? Use a debugger to try to force a buffer overflow?

Seems like hardened-check should be able to detect it heuristically for ELF at least:

Stack Protected

This indicates that there is evidence that the ELF was compiled with the [gcc]>(https://manpages.ubuntu.com/manpages/trusty/man1/gcc.1.html)(1)
option -fstack-protector (e.g. uses __stack_chk_fail). The program will be
resistant to having its stack overflowed.

When an executable was built without any character arrays being allocated on the
stack, this check will lead to false alarms (since there is no use of
__stack_chk_fail), even though it was compiled with the correct options.

[wader]

@nicowilliams noticed a fixup commit slipped in

[nicowilliams]

What's stripping the executable?

[wader]

Think this https://github.com/jqlang/jq/blob/master/.github/workflows/ci.yml#L74 probably?

[nicowilliams]

Think this https://github.com/jqlang/jq/blob/master/.github/workflows/ci.yml#L74 probably?

Ay, yes. Well, I suppose I could build jq twice, once w/o stripping, to check if it has stack protection. Or maybe just punt. I'm doing a build without -s and if that works I'll put it back and drop the nm check and call it a day.

[nicowilliams]

Without stripping we see:

So I'm going to undo the nm check and restore stripping.

[wader]

👍 I think we can makes this nicer after 1.7

[nicowilliams]

I wonder if we could have a command-line option to indicate whether jq was built with any stack protection features. Or maybe we could have a command-line option that shows the build options used to build jq, just like many programs have.

[wader]

I wonder if we could have a command-line option to indicate whether jq was built with any stack protection features. Or maybe we could have a command-line option that shows the build options used to build jq, just like many programs have.

Yeap that feels like quite neat solution. I poked around a bit with harden-checker and noticed that with static builds the __stack_chk_fail symbol seem to be included even when -fstack-protector is not used (so it part of glibc?), feels a bit shaky, so your proposal seems safer.

[nicowilliams]

Yeap that feels like quite neat solution. I poked around a bit with harden-checker and noticed that with static builds the __stack_chk_fail symbol seem to be included even when -fstack-protector is not used (so it part of glibc?), feels a bit shaky, so your proposal seems safer.

With --run-tests we could spawn a thread to run a bit of vulnerable code and test it. Not sure that's a great idea or a terrible idea. Anyways, I opened #2817 to have jq print it's build configuration -- it captures only ./configure options, but maybe we could add to it a way to record the versions of all the relevant tools (autotools, compiler, bison, Oniguruma, etc.), and we could always do that later.