Call for testing: OpenSSH 6.8

Michael Felt aixtools at
Sat Feb 28 22:40:08 AEDT 2015

The 'user' way to address this is to modify LIBPATH variable - as I did
above, and that will work for a long time.

Starting with AIX 6.1 - this can be disabled by setting a security policy -
so that only programs and/or libraries can be executed from trusted

>From trustchk man page - three of the options for the -p (policy) flag

            Enables or disables Trusted Execution. Policies can only be
            activated when the TE option is set to ON.
            Sets the value of Trusted Execution path, and enables or
            it. The Trusted Execution path consists of a list of
            absolute paths, for example, the /usr/bin:/usr/sbin. When this
            policy is enabled, the files belonging to only these directory
            are allowed to be started. If an executable program that does
            belong to the TEP is to be loaded, the program is blocked.
            Sets the value of Trusted Library path, and enables or disables
            The Trusted Library Path consists of a list of colon-separated
            absolute paths, for example, the /usr/lib:/usr/ccs/lib. When
            policy is enabled, the libraries belonging to only these
            paths can be loaded. If a program tries to load a library that
            not belong to the TLP, the program is blocked.

As an example - default settings (TE=off, so all are ignored)
michael at x071:[/data/prj/openbsd/openssh/openssh]trustchk -p TE TEP TLP

re: the 'undesired behavior' of the AIX ld program. I would say it is
'still' there - and I agree with the premise that the default library
search path gets very messy. This is actually one of the reasons why I
started packaging tools myself (I did not like the state, nor the extra
libraries I needed to load, or overwrite 'AIX' ones (which broke other

To underline this issue - without any -blibpath variable the default (in
the binary LIBPATH would be:
                        ***Import File Strings***
INDEX  PATH                          BASE

1                                    libc.a
2                                    libcrypto.a

Coming from - what ld already has a default plus these arguments:
-L. -Lopenbsd-compat/ -L/opt/libressl/lib

I am guessing that this is the behavior of 'other' linkers when -R is used.

As a packager - I would like the option to be able to specify the -blibpath
- especially because I want to be able to package 'aixtools' as a
replacement package that can co-exist - because I do not expect to resolve
all possible dependencies of existing programs. Additionally, if I used a
position 'owned' by another package - an update of that package may
overwrite what I have done.

The is the reason for /opt and/or /opt/package as prefix - older default is
/usr/local; IBM AIX toolkit and others use /opt/freeware/*

>From my perspective - when using a different version of 'openSSL API' - for
it to work I will need a different blibpath so it gets found. That is much
better than that I would add as a MEMBER to

FYI: This is the IBM version on AIX 6.1
michael at x071:[/data/prj/openbsd/openssh/openssh]ar tv /usr/lib/libcrypto.a
rwxrwxr-x 435159/781431 2965832 May 01 06:57 2014
rwxrwxr-x 435159/781431 2253655 May 01 06:58 2014

I see not the most recent one - but the dual support, via dual members is
how that is working.
  openssl.base       C     F    Open Secure Socket Layer

just as you give a warning message for no use of compiler stack execution
protection - you could give a warning that a modified blibpath is being

re: stack execution protection, AIX has a hardware based mechanism that can
be set system-wide and/or at application level. See
This has it's start back in 2004/2005 with POWER4 iirc.

I shall address va_copy in a second note.

On Fri, Feb 27, 2015 at 7:04 PM, Darren Tucker <dtucker at> wrote:

> On Fri, Feb 27, 2015 at 9:19 AM, Michael Felt <aixtools at> wrote:
>> One problem coming directly is that the -L flag (-L/opt/libressl/lib is
>> not
>> being included in the -blibpath so the programs link, but do not run.
>> I am sure there is a way for me to modify the blibpath - BUT - I ask you
>> do
>> consider inserting an openssl-dir path when it is not
>> already in the blibpath variable.
> There's a reason why it isn't: where that directory is writeable by a
> non-root user it becomes a vector for local privilege escalation via
> OpenSSH's setuid binaries.
> Now that decision was made back in the day when OpenSSL's shared library
> support was still considered experimental.  Maybe we could check that the
> path is a) absolute and b) system-owned all the way down and add it to
> blibpath if both are true.
> --
> Darren Tucker (dtucker at
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.

More information about the openssh-unix-dev mailing list