Bug 2007 - The literal string ${prefix}/bin appears in the user PATH under some circumstances
Summary: The literal string ${prefix}/bin appears in the user PATH under some circumst...
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Build system (show other bugs)
Version: 6.0p1
Hardware: All All
: P2 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_6_1
  Show dependency treegraph
 
Reported: 2012-05-13 04:20 AEST by Nix
Modified: 2015-08-11 23:02 AEST (History)
1 user (show)

See Also:


Attachments
Recursively expand ${bindir} (1.04 KB, patch)
2012-05-13 04:20 AEST, Nix
dtucker: ok+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nix 2012-05-13 04:20:56 AEST
Created attachment 2151 [details]
Recursively expand ${bindir}

I just noticed something strange in ssh sessions using OpenSSH 6.0p1 (and almost certainly earlier versions too). My PATH was set to this:

/home/nix/bin:/usr/bin:/bin:/usr/sbin:/sbin:${prefix}/bin:/usr/games

That ${prefix}/bin is probably a mistake. Worse yet, it's a relative path, so in theory a security hole if an attacker knew to create a directory with such a ludicrous name and fill it with typos for normal commands. (I'm not marking this as a security bug because the case in which it happens is quite unlikely: see below.)

It's coming from the code in configure.in which attempts to ensure that the installation prefix is in the user PATH... but it expands it only once, and assumes that is sufficient. The default expansion of ${bindir) contains no further variable references, but this need not be the case: you can specify (in config.site or on the command-line) a variant like ${prefix}/bin, which contains another variable, in which case you get the problem above, in a self-disguising fashion because the printout of the path at the end of configure expands it once more and things look reasonable, though they are not. This sort of multiple-reference was the default in the past and people with old config.sites are likely to have it as their default still. (You can even have repeated references to NONE in there, i.e. a ${bindir} containing a reference to a variable which itself contains a NONE, references to further variables, et seq ad nauseam.)

Most people don't do that, so most OpenSSH installations are not vulnerable: but it's probably worth fixing anyway.

Patch attached (which in theory might cause configure to hang if ${bindir} contains a loop of variable references, but every other configure script out there will also hang or violently misbehave in that situation, so don't do that then.)
Comment 1 Damien Miller 2012-07-06 11:39:29 AEST
Comment on attachment 2151 [details]
Recursively expand ${bindir}

looks okay to me, Darren?
Comment 2 Damien Miller 2012-07-06 11:49:45 AEST
patch applied - this will be in openssh-6.1. Thanks!
Comment 3 Damien Miller 2015-08-11 23:02:19 AEST
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1