building libjnidispatch with stack canaries in default jar files ?

[Lousticator]

hello

we are using this fantastic JNA code in our software, but some of our users are eager to pass security analysis tools on everything, and their tools complain that the libjnidispatch.so doesn't match "their" security requirements (apparently, "the mobsf tool or the checksec tool" complain about "the absence of stack canaries and libc fortification")

 
of course we could build our own JNA jar files, ... but as they are also downloading their jar files directly from the official JNA website, ...

... what does the JNA community think about the possibility to include some kind of "safety guards" options in the build script, and have libjnidispatch.so available by default with these security protections ?

(just asking, in the case it could be a problem for another reason...)

thx in advance for your answers,
loustic

[Matthias Bläsing]

Hi,

the prebuild binaries are build to be able to run on a big number of platforms. For linux this means, you need to link against an old glibc, which at least for me means I have to build the native parts in an old chroot. I'm reluctant to require newer gcc's as this raises the question how the build environment will be created.

I don't know what would be involved, but it currently takes more than a day to rebuild the native libraries, anything that makes it harder, makes me unhappy.

Building for android is currently the most convenient, as it can be quickly cross-build. All other architectures a pain in one way or another, so if you can improve this, I'm happy to have a look.

Greetings

Matthias

[Tres Finocchiaro]

From what I'm reading, some build environments have been using these settings by default for a while now... 

Quoting Matthew Ruffell: (link removed, google groups blocked my previous reply?)

"Reading the wiki page, -fstack-protector has been enabled for all packages by default since Ubuntu 6.10, and was extended to include greater coverage in more binaries being built with the stack protector with --param ssp-buffer-size=4 by default in 10.10. 

 

Currently -fstack-protector-strong is the default compiler flag, and this has been enabled for all packages since 14.10."  

... 

 

The wiki mentions -D_FORTIFY_SOURCE=2 has been enabled for all packages since 8.10, which is a really long time. It does only apply to packages built with -O1 optimisation or higher, but I would expect the amount of packages not using -O2 or higher to be very low.

... The article continues to explain that scanning tools may not be properly suited to detect the presence of these protections.

Assuming the tools are correct and a recompile is needed, it may be best to start from Matthias's procedures and see if the chroot environment has the necessary flags.

Matthias, do you have the Linux chroot steps published?

[Matthias Bläsing]

Hi Tres,

Am Dienstag, dem 28.02.2023 um 20:44 -0500 schrieb Tres Finocchiaro:
>
> Matthias, do you have the Linux chroot steps published?

I pushed my build setup here:

https://github.com/matthiasblaesing/docker-jna-build

HTH

Matthias

[Tres Finocchiaro]

I haven't had success yet with this task, but I wanted to document my progress (or lack thereof).

According to ant, we should be able to pass "-fstack-protector-strong" as a gcc build flag:

ant clean && ant -Dcflags_extra.native=-fstack-protector-strong native && checksec --file=build/native-linux-$(arch)/libjnidispatch.so

However, testing this on Ubuntu 24.04, I can't seem to establish a baseline.  All builds from this environment (even if I explicitly disable stack protection) show stack protection enabled.

I pushed my build setup here:

https://github.com/matthiasblaesing/docker-jna-build

Thanks.

it currently takes more than a day to rebuild the native libraries, anything that makes it harder, makes me unhappy.

Now that I have attempted to run this setup, I'm starting to understand first-hand how long this takes. My main goal is to set up a single arch environment to test the viability of these compiler flags for the OP.  Perhaps it would be better for me to set up a dedicated VM for testing this?  Thoughts are welcome.  I'm currently trying to run docker from mac on arm64 and the scripts you've written fail with some errors.  I'd rather not troubleshoot the errors here if there's a portion of these steps you can recommend to replay in a VM to produce binaries identical to what JNA ships (since the builds from an Ubuntu VM seem to have the stack protections built-in and I can't find a way to disable them as a baseline).