Enable RELRO

[KiWiLss]

This shared object does not have RELRO enabled.The entire GOT(.got and .got.plt both)are writable. Without this compiler flag, bugger overflows on a global variable can overwrite GOT entries. Use the option -z,relro,-z,now to enable full RELRO and only -z,relro to enable partial RELRO.

[matthiasblaesing]

Please describe in plain english what you see as a problem, why this is a problem and which shared object you are talking about.

You should have explained what is the GOT (https://ctf101.org/binary-exploitation/what-is-the-got/):

The Global Offset Table (or GOT) is a section inside of programs that holds addresses of functions that are dynamically linked.

And RELRO (https://ctf101.org/binary-exploitation/relocation-read-only/):

Relocation Read-Only (or RELRO) is a security measure which makes some binary sections read-only.
Full RELRO makes the entire GOT read-only which removes the ability to perform a "GOT overwrite" attack, where the GOT address of a function is overwritten with the location of another function or a ROP gadget an attacker wants to run.

JNA allows users full access to memory. You can create a raw pointer and write anywhere there OS gives you access to, so why would you need an exploit for?

At this point in time I don't see your point.

[charles-xu]

We are have vulnerability scanning for our app. It indicates we have security risk since we do not enable the Canary and RELRO when compile this lib. But actually, we only copy and use this lib, that's the reason we are asking your help. :)

For Canary, there is following link for your reference. It is an stack cookie, when the function return, it will check the cookie firstly to ensure the stack is not overwritten (to prevent the return address manipulation in the stack for exploit). The link is for QNX, but the concept and mechanism is similar. It is recommend to enable this check to protect the stack. To open the check fully, with option: -fstack-protector-all
https://www.qnx.com/developers/docs/8.0/com.qnx.doc.security.system/topic/manual/stack_protection.html .

For RELRO, there is following link for your reference. It tries to protect from the lib address manipulation.
https://www.qnx.com/developers/docs/8.0/com.qnx.doc.security.system/topic/manual/developer_relro.html

Would you please help check whether it is possible to enable those two options in the release, then we can get rid of those security warning? Thanks.

[matthiasblaesing]

Sorry but I refuse to work on issues reported by "security scanners", which were then not vetted by humans.

Would you please help check whether it is possible to enable those two options in the release, then we can get rid of those security warning? Thanks.

No, the project is driven by the needs of its users, who fix "their" pet problems. The native library is build on various platforms:

https://github.com/java-native-access/jna/blob/master/www/BuildingNativeLibraries.md

Not sure what gcc version is the base line version to make the above possible or whether this is feasible on all platforms.

[dblock]

Would you please help check whether it is possible to enable those two options in the release, then we can get rid of those security warning? Thanks.

I think what @matthiasblaesing is saying is that if you would like this enabled, you should submit a PR.