Linux 'less' can probably get you owned

Published
Credit
Risk
2014.11.24
Michal Zalewski
High
CWE
CVE
Local
Remote
N/A
N/A
Yes
No

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. Some other
folks have expressed their disbelief in the past:

https://twitter.com/solardiz/status/526008283690455040

But even ignoring the most suspect tools and grabbing something as
seemingly innocuous as cpio, a short spin with afl-fuzz (or, probably,
anything else) will immediately yield this:

http://lcamtuf.coredump.cx/afl/vulns/lesspipe-cpio-bad-write.cpio

It's a file with declared block length of 0xffffffff. That gets us
here, with the value populated to c_filesize (copyin.c, list_file()):

link_name = (char *) xmalloc ((unsigned int) file_hdr->c_filesize + 1);
link_name[file_hdr->c_filesize] = '\0';

...where we end up allocating a zero-byte buffer and then promptly
writing out of bounds (just under the buffer on 32-bit systems or
somewhere above it on 64-bit).

While it's a single bug in cpio, I have no doubt that many of the
other lesspipe programs are equally problematic or worse. In a thread
yesterday, people immediately started pointing out other issues, say:

http://seclists.org/oss-sec/2014/q4/773

The saving grace is that lesspipe scripts make most of their routing
decisions based on file extensions. Alas, many of these extensions
will be completely alien and meaningless to all but the most seasoned
users (.cpi, .raw, .r42, .ear, .zoo, .a). And there are some instances
of utilities being called on * (e.g., iconv, fileutils).

Ultimately, I think that there's an expectation that running less on a
downloaded file won't lead to RCE, and the lesspipe behavior in many
distros is almost certainly violating that. I'm also not sure if the
automation actually scratches any real itch - I doubt that people try
to run 'less' on CD images or 'ar' archives when knowingly working
with files of that sort.

At this point, my best advice would be for users to unset LESSOPEN and
LESSCLOSE if set by their distros.

/mz

------------------------
$ mkdir dir/
$ genisoimage -o empty.iso dir/ 2> /dev/null
$ time zzuf -qcs: isoinfo -i empty.iso
zzuf[s=48,r=0.004]: signal 11 (SIGSEGV)

real 0m0.210s
user 0m0.084s
sys 0m0.008s

:-)
------------------------

References:

http://cxsecurity.com/issue/WLB-2014110157
http://seclists.org/oss-sec/2014/q4/773
http://seclists.org/fulldisclosure/2014/Nov/74
https://twitter.com/solardiz/status/526008283690455040
http://lcamtuf.coredump.cx/afl/vulns/lesspipe-cpio-bad-write.cpio


See this note in RAW Version

 
Bugtraq RSS
Bugtraq
 
CVE RSS
CVEMAP
 
REDDIT
REDDIT
 
DIGG
DIGG
 
LinkedIn
LinkedIn


Copyright 2017, cxsecurity.com