Adding Address Space Layout Randomization support for SSH binaries in AIX

[AkankshaP15]

Adding Address Space Layout Randomization support for SSH binaries in AIX to enhance security against memory-based attacks.
This feature is designed to improve security by loading shared memory objects at random addresses instead of fixed addresses.

[daztucker]

This will break any AIX systems using xlc whose linker doesn't support that flag, which will likely include a number where OpenSSH would otherwise work fine. Instead, could you please use the OSSH_CHECK_LDFLAG_LINK macro to only add it if the linker supports it?

[daztucker]

also, you placed it inside a configure test that's for a completely different purpose. Given that it's a linker flag, does it work with alternative compilers such as gcc or clang on those systems? Either way I think it should be its own stand-alone test, not inside AC_MSG_CHECKING([if compiler allows macro redefinitions]).

[AkankshaP15]

I have updated configure.ac in the latest commit. Below are the test scenarios executed for the cc, gcc, and ibm-clang compilers:

1. cc compiler (Supports -baslr flag)

# ./configure --with-zlib=<zlib_directory> --with-ssl-dir=<openssl_directory> --with-baslr
checking for cc... cc
…
…
checking if cc -qlanglvl=extc1x supports link flag -baslr... yes
checking whether linker supports -baslr... yes
…
…
# grep '^LDFLAGS' Makefile
LDFLAGS=-L. -Lopenbsd-compat/ -L/<openssl_directory> -L/<zlib_directory>  -baslr -blibpath:/usr/lib:/lib 
LDFLAGS_NOPIE=-L. -Lopenbsd-compat/ -L/<openssl_directory> -L/<zlib_directory>  -baslr -blibpath:/usr/lib:/lib 

2. gcc compiler (Doesn’t support -baslr flag)

# ./configure --with-zlib=<zlib_directory> --with-ssl-dir=<openssl_directory> --with-baslr
checking for gcc... gcc
…
…
checking if gcc supports link flag -baslr... no
checking whether linker supports -baslr... no
…
…
# grep '^LDFLAGS' Makefile
LDFLAGS=-L. -Lopenbsd-compat/ -L/<openssl_directory> -L/<zlib_directory>  -Wl,-blibpath:/usr/lib:/lib 
LDFLAGS_NOPIE=-L. -Lopenbsd-compat/ -L/<openssl_directory> -L/<zlib_directory> -Wl,-blibpath:/usr/lib:/lib

3. ibm-clang compiler (Supports -baslr flag)

# ./configure --with-zlib=<zlib_directory> --with-ssl-dir=<openssl_directory> --with-baslr
checking for ibm-clang... ibm-clang
…
…
checking if ibm-clang supports link flag -baslr... yes
checking whether linker supports -baslr... yes
…
…
# grep '^LDFLAGS' Makefile
LDFLAGS=-L. -Lopenbsd-compat/ -L/<openssl_directory> -L/<zlib_directory> -fstack-protector-strong -baslr -Wl,-blibpath:/usr/lib:/lib 
LDFLAGS_NOPIE=-L. -Lopenbsd-compat/ -L/<openssl_directory> -L/<zlib_directory> -fstack-protector-strong -baslr -Wl,-blibpath:/usr/lib:/lib 

[AkankshaP15]

@daztucker, Please let me know if there are any comments.

[daztucker]

this part is unnecessary, since OSSH_CHECK_LDFLAG_LINK already provides all of this information in its output, and adds it to LDFLAGS if it's supported (see m4/openssh.m4).

[AkankshaP15]

Okay. We will address it.

[daztucker]

is there any reason this can't be part of the rest of the use_toolchain_hardening --with-hardening flags and be on by default when supported?

[AkankshaP15]

-baslr is linker/loader specific option for AIX (similar to pie for other OS). Hence, we are handling it under aix target specific case instead.

Since the existing code is built without ASLR, we wish to keep this behavior as is and enable it when explicitly specified.

[daztucker]

-baslr is linker/loader specific option for AIX (similar to pie for other OS). Hence, we are handling it under aix target specific case instead.

If it's not supported, the OSSH_CHECK_LDFLAG_LINK check will fail and the flag won't be added.

Since the existing code is built without ASLR, we wish to keep this behavior as is and enable it when explicitly specified.

Why? What's the point of having a security feature that's off by default? Now if it was problematic or very slow that might be a good reason, but is it?

[AkankshaP15]

I have updated configure.ac in the latest commit to drop redundant -baslr linker check.
@daztucker, Please let me know if there are any comments.