PDA

Bekijk Volledige Versie : Portable OpenSSH: Dangerous AIX linker behavior (aixgcc.adv)



Damien Miller
30/04/03, 20:05
1. Systems affected:

Users of Portable OpenSSH prior to 3.6.1p2 on AIX are affected
if OpenSSH was compiled using a non-AIX compiler (e.g. gcc).

Please note that the IBM-supplied OpenSSH packages[1] are
not vulnerable.

2. Description:

The default behavior of the runtime linker on AIX is to search
the current directory for dynamic libraries before searching
system paths. This is done regardless of the executable's
set[ug]id status.

This behavior is insecure and extremely dangerous. It allows an
attacker to locally escalate their privilege level through the
use of replacement libraries.

Portable OpenSSH includes configure logic to override this
broken behavior, but only for the native compiler. gcc uses a
different command-line option (without changing the dangerous
default behavior).

3. Impact:

Privilege escalation by local users.

4. Short-term workaround:

Remove any set[ug]id bits from the installed binaries,
usually 'ssh-agent' and 'ssh-keysign'. Older versions of OpenSSH
may also install the 'ssh' binary as setuid.

Please note that removing the setuid bit from ssh-keysign will
disable hostbased authentication.

Portable OpenSSH 3.6.1p2 uses the correct compiler flags to
avoid the dangerous linker behavior.

5. Solution:

For the problem to be solved, the AIX linker must be changed to
only search system paths by default and never search the current
directory or user-specified paths for set[ug]id programs.

We consider this a serious flaw in IBM's linker, and urge
them to fix it immediately. IBM, are you listening?

6. Credits:

Thanks to Andreas Repp (IBM Deutschland GmbH) for bringing the
issue to our attention. Darren Tucker <dtucker@zip.com.au>
contributed the fix.

[1] http://oss.software.ibm.com/developerworks/projects/opensshi

Valdis.Kletnieks@vt.edu
30/04/03, 22:05
--==_Exmh_816324338P
Content-Type: text/plain; charset=us-ascii

On Wed, 30 Apr 2003 13:39:49 +1000, Damien Miller <djm@mindrot.org> said:
> 1. Systems affected:
>
> Users of Portable OpenSSH prior to 3.6.1p2 on AIX are affected
> if OpenSSH was compiled using a non-AIX compiler (e.g. gcc).

This is the same problem as I spotted in Sendmail 8.10. Basically,
somewhere, linking is being done with "-L. -lfoo" or similar (in sendmail's
case, it was -L../otherdir type stuff).

Workaround/fix: Link with "-bnolibpath -blibpath:/usr/local/lib:/usr/lib"
or similar.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech


--==_Exmh_816324338P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQE+sBFVcC3lWbTT17ARArHcAKCDu2hB3riPBiOAYAf+1A nQMmPvcgCeMCS4
vVg4msRDcdpI4ZhCMMwInjg=
=znrj
-----END PGP SIGNATURE-----

--==_Exmh_816324338P--

Darren Tucker
01/05/03, 17:35
Valdis.Kletnieks@vt.edu wrote:
> On Wed, 30 Apr 2003 13:39:49 +1000, Damien Miller <djm@mindrot.org> said:
> > 1. Systems affected:
> >
> > Users of Portable OpenSSH prior to 3.6.1p2 on AIX are affected
> > if OpenSSH was compiled using a non-AIX compiler (e.g. gcc).
>
> This is the same problem as I spotted in Sendmail 8.10. Basically,
> somewhere, linking is being done with "-L. -lfoo" or similar (in sendmail's
> case, it was -L../otherdir type stuff).

Yes, and your sendmail advisory was one of the sources of information I
used when preparing the fix.

> Workaround/fix: Link with "-bnolibpath -blibpath:/usr/local/lib:/usr/lib"
> or similar.

OpenSSH already specified -blibpath *EXCEPT* when CC=gcc (thus, binaries
compiled with xlc were safe). GCC doesn't understand -blibpath.

Configure now tries using -blibpath, -Wl,-blibpath and -Wl,-rpath (for
xlc, GCC + native ld and GCC + GNU ld respectively). If none of these
work it will abort.

--
Darren Tucker (dtucker at zip.com.au)
GPG Fingerprint D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Dan Harkless
01/05/03, 20:50
Valdis.Kletnieks@vt.edu writes:
> On Wed, 30 Apr 2003 13:39:49 +1000, Damien Miller <djm@mindrot.org> said:
> > 1. Systems affected:
> >
> > Users of Portable OpenSSH prior to 3.6.1p2 on AIX are affected
> > if OpenSSH was compiled using a non-AIX compiler (e.g. gcc).
>
> This is the same problem as I spotted in Sendmail 8.10.

Yeah, referring to my Bugtraq archives, I see you spotted that way back in
March 2000. Damien writes in his advisory:

We consider this a serious flaw in IBM's linker, and urge
them to fix it immediately. IBM, are you listening?

but if they haven't fixed it in the past 3 years, I don't think we should
hold our breaths for an immediate fix. Guess it's a case of "that's not a
bug, it's a feature", only in this case it's "that's not a _security_hole_,
it's a feature".

> Basically, somewhere, linking is being done with "-L. -lfoo" or similar
> (in sendmail's case, it was -L../otherdir type stuff).

Right, Damien states in his advisory:

The default behavior of the runtime linker on AIX is to search
the current directory for dynamic libraries before searching
system paths.

but it's my understanding (don't currently have access to an AIX system to
double-check) that this is not default loader behavior, but rather occurs if
"-L." was specified when linking (not that that makes this much less of a
concern).

> Workaround/fix: Link with "-bnolibpath -blibpath:/usr/local/lib:/usr/lib"
> or similar.

On the other topic addressed by OpenSSH 3.6.1p2, the valid account
identification timing leak, I find it a bit disturbing that the 3.6.1p2
announcement said just:

Changes since OpenSSH 3.6.1p1:
============================

* Security: corrected linking problem on AIX/gcc. AIX users are
advised to upgrade immediately. For details, please refer to
separate advisory (aixgcc.adv).

* Corrected build problems on Irix

* Corrected build problem when building with AFS support

* Merged some changes from Openwall Linux

without mentioning what the Openwall changes were for and without a
"Security: " on that line.

Anyone subscribing to openssh-unix-announce but not Bugtraq would think
there was no need to upgrade to 3.6.1p2 if they weren't using AIX.

--
Dan Harkless
bugtraq@harkless.org
http://harkless.org/dan/

Darren Tucker
01/05/03, 22:50
Damien Miller wrote:
> 1. Systems affected:
> Users of Portable OpenSSH prior to 3.6.1p2 on AIX are affected
> if OpenSSH was compiled using a non-AIX compiler (e.g. gcc).

Hi All.

For the last year or so I've published OpenSSH binary packages for AIX at
[1].

I would like to advise all users of these packages that all versions up
to and including the 3.6.1p1 version *are* affected by this and have been
removed.

A patched version (3.6.1p1-1) is available which addresses this issue. I
urge all users of these packages to upgrade or apply the workaround
immediately.

-Daz.

[1] http://www.zip.com.au/~dtucker/openssh/

--
Darren Tucker (dtucker at zip.com.au)
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.

Damien Miller
01/05/03, 23:20
Valdis.Kletnieks@vt.edu wrote:
> On Wed, 30 Apr 2003 13:39:49 +1000, Damien Miller <djm@mindrot.org> said:
>
>>1. Systems affected:
>>
>> Users of Portable OpenSSH prior to 3.6.1p2 on AIX are affected
>> if OpenSSH was compiled using a non-AIX compiler (e.g. gcc).
>
>
> This is the same problem as I spotted in Sendmail 8.10. Basically,
> somewhere, linking is being done with "-L. -lfoo" or similar (in sendmail's
> case, it was -L../otherdir type stuff).
>
> Workaround/fix: Link with "-bnolibpath -blibpath:/usr/local/lib:/usr/lib"
> or similar.

This is what we have done for a long time, but those options only work
when using xlc as the linker, with gcc you need to specify different
options.

3.6.1p2 specifies these options correctly, but it illustrates the deeper
problem: the default is insecure and you need to add workarounds for
each additional interface to the linker.

I wouldn't be suprised if this affected binaries built with libtool or
other wrappers, though I haven't checked (we don't use them).

-d

Shiva Persaud
02/05/03, 00:50
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Taken from IBM's AIX vendor response (http://lists.insecure.org/lists/bugtraq/2000/Mar/0184.html) to this issue when discussed in 2000:


<BEGIN>
The AIX version 4 linker has always documented the -blibpath option as a
mechanism for removing build environment dependencies from a runtime
environment. Applications that gain privilege should always use this
option to remove library search paths that may not/should not exist on
customer machines.


The use of relative library paths is also highly discouraged. While
they can be useful, the -blibpath option should also be used to not only
avoid these types of security issues, but to remove the possibility of
finding (or not finding at all) the wrong relative directory, since
relative paths at runtime will be based upon the current working
directory.


These and any other AIX security vulnerabilities can be reported to
security-alert@austin.ibm.com.
</BEGIN>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQE+sWGWcnMXzUg7txIRAlPOAJ9MyLxzoesJAlE4z/rUTjUcBALV4gCfZjkW
bgslNWzYOTobFpw2Knr0V/0=
=+nIF
-----END PGP SIGNATURE-----


Shiva Persaud
AIX Security Developer





Damien Miller
<djm@mindrot.org> To: BUGTRAQ@securityfocus.com, <openssh-unix-dev@mindrot.org>,
<openssh-unix-announce@mindrot.org>
04/29/2003 10:39 cc:
PM Subject: Portable OpenSSH: Dangerous AIX linker behavior (aixgcc.adv)







2. Description:

The default behavior of the runtime linker on AIX is to search

the current directory for dynamic libraries before searching
system paths. This is done regardless of the executable's
set[ug]id status.

This behavior is insecure and extremely dangerous. It allows
an
attacker to locally escalate their privilege level through the

use of replacement libraries.

Portable OpenSSH includes configure logic to override this
broken behavior, but only for the native compiler. gcc uses a
different command-line option (without changing the dangerous
default behavior).