Bug 2007

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.)