
On Linux, 'less' can probably get you owned - adamnemecek
http://seclists.org/fulldisclosure/2014/Nov/74
======
userbinator
_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._

This is a trend not uncommon in GNU software -- features added by someone who
at some point thought it was a good idea, but probably didn't even bother
using them much beyond an initial test to see that they are somewhat working.
Most users likely think of 'less' as nothing more than a bidirectional version
of 'more', and not as the "file viewer that attempts to do everything" that it
seems to actually be. It's also a little reminiscent of ShellShock.

~~~
fafner
lesspipe is not a GNU project...

~~~
TorKlingberg
Yes, the responsibility here lies squarely with the distros that set LESSOPEN
and LESSCLOSE.

------
viraptor
This is probably a good reminder of something else: using
selinux/apparmor/tomoyo/... can save you from many situations where you'd be
exploited otherwise. For example as a response to this you can set a policy on
lesspipe and all its children so that they cannot access the internet or write
outside of temp directories.

Whatever library is used by lesspipe - you're safe as long as the output
terminal and your kernel are safe.

~~~
jschwartzi
This should honestly be part of every modern Linux system. It would go a long
way toward creating the kind of reasonably secure system people are looking
for.

I would envision this to be useful if there were a pre-installed local
database of common use cases for each utility, and the user invoking the
utility could interactively decide whether to allow specific exceptions, with
a big fat warning.

Then, it doesn't matter whether someone exploits your tool, they're only ever
allowed to utilize the tool for its intended use cases.

~~~
x0x0
Yet when apple makes a sandbox for apps -- which is basically this design, yet
usable by people who don't understand software construction or libs -- people
shriek. A sandbox is a security boon for the vast majority of people. And I
think this is the only way to get reasonable security; we've been banging on
this "reduce bugs" plan for at least a decade with much less progress than one
would hope to show for it.

~~~
Perdition
People shriek because Apple isn't giving the device owner any option to get
around the security if they want to.

Apple aren't using that model just for security, but also so they can tightly
control the platform and restrict what the device owner can do on it.

~~~
janfoeh
> People shriek because Apple isn't giving the device owner any option to get
> around the security if they want to.

You are misinformed. Right click -> Open instead of double click overrides my
current signing requirements and executes the app anyway.

~~~
hueving
Where do I right click on my iPhone?

------
steakejjs
This research lcamtuf has been doing with AFL is really important.

One thing that it is proving (exactly as a lot of people expected) is, we
don't have any idea where security bugs (think the next heartbleed or
shellshock) are going to show up, we have no idea how good the software out
there is (meaning it is bad), and most of the time we don't even know what's
running on our own boxes.

If these basic things we use hundreds of times a day (less, strings) have huge
flaws, we have a lot of work ahead of us.

~~~
pjmlp
They will never go away while people insist in using C and its derivatives to
write userspace code.

~~~
gurkendoktor
Shellshock didn't have anything to do with C. gotofail looked like an SCM
merging bug, which could have happened in any language. Security issues in the
Rails world are often caused by libraries that do more than they should, just
like less does (YAML comes to mind).

Yes, it would be nice to get rid of one class of errors. But proper sandboxing
would get rid of them all.

~~~
diminoten
Yeah those are the famous ones, but what's much more likely is that you're not
going to necessarily be working on a project with as wide a footprint as any
of those, and you're probably not going to create a bug that's quite as
harmful as any of those either, but you're still going to cause memory-
management problems for your project if you start out writing C.

No one's saying it's impossible to write memory-safe C code, it's just
exponentially harder, and when you're not 100% sure of your use case and exact
performance needs, you're going to spend a _lot_ more time than you want to
making C do only what you want and nothing else.

------
Animats
Last month, it was "file", which turned out to have a parser for executables
which can be exploited via a buffer overflow.

Probably the best exploit in this line is crafting JPEG files which cause
buffer overflows in forensic tools and take over the machine being used for
forensics.

We need an effort to convert Linux userspace tools likely to be invoked as
root or during installs from C/C++ to something with subscript checking.

~~~
twinge
"strings" is also vulnerable: [http://lcamtuf.blogspot.com/2014/10/psa-dont-
run-strings-on-...](http://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-
on-untrusted-files.html)

Inspecting files is apparently hazardous.

~~~
MichaelGG
No, writing general handling code in C is hazardous.. And after that, mixing
domains, especially for human convenience, is dangerous as parsing gets
complicated and leads to the unexpected.

Rust can solve the first problem. A sense of elegance or just good taste can
solve the second.

~~~
xorcist
This problem with LESSOPEN would exist even if less was written in Rust. The
same goes for the strings command.

~~~
Scramblejams
All the more reason to use memory safe languages as far up the stack as you
can go.

------
username223
The first time I accidentally ran "less" on a directory and it piped some
version of "ls" into itself, I was mildly annoyed. The thing's supposed to
page a text file on a terminal. Since then, I've had to think twice before
invoking it to avoid this "helpful" behavior, and I'm not surprised that it
came back to bite people.

~~~
cbd1984
> The first time I accidentally ran "less" on a directory and it piped some
> version of "ls" into itself, I was mildly annoyed.
    
    
        % less .
        . is a directory
        % less imadir
        imadir is a directory
    

My point is, that behavior is a configuration issue on your end, not inherent
to the less codebase.

~~~
username223
> My point is, that behavior is a configuration issue on your end, ...

On my end, and on every "end" where I ever log in. "less" works as a simple
pager on my own system, but now I need to remember to possibly fix it
everywhere else. "You can fix it in the config file" is not an excuse for
broken-by-design software.

> ... not inherent to the less codebase.

Well yes, it kind of is. "less" used to be a better replacement for "more."
Now it's something else, which should have a different name. Should "cat" be
changed to automatically uncompress files and concatenate archives?

~~~
lmm
> Well yes, it kind of is. "less" used to be a better replacement for "more."
> Now it's something else, which should have a different name. Should "cat" be
> changed to automatically uncompress files and concatenate archives?

"less" already means "pager with all the bells and whistles". If you just want
a simple pager, "more" is still there. How many fine gradations do you need?

~~~
ansible
Back in the old, old days, we all started using 'less' because 'more' did not
have the ability to scroll backwards through a file. Nor was it buffering pipe
input to enable similar functionality. It seems there has been a bit of
feature creep in the ensuing 25 years...

~~~
drummer32
Yup, cause apparenlty staying the same for 25 years is the new normal. Would
you discard more too if it added the ability to page back in a document?

~~~
ansible
No, but if the maintainers added the ability to play MP3s and file my taxes,
that is a cause for concern.

------
vezzy-fnord
This was also mentioned in one of the pages of The Fuzzing Project, linked on
HN just a short while ago as of this comment: [https://fuzzing-
project.org/background.html](https://fuzzing-project.org/background.html)

~~~
danielweber
I was idly wondering about "less" a month ago.
[https://news.ycombinator.com/item?id=8506813](https://news.ycombinator.com/item?id=8506813)
It looks like my answer is "yeah, people are looking at that."

------
mrmondo
That is bad default behaviour on Ubuntu's (and centos'?) behalf. I have
confirmed this is not the case in Debian.

------
fsniper
I think this is one side effect of development. We are trying to implement any
feature that would be _nice to have_ into every software.

LESSOPEN or LESSPIPE is a feature that is already achievable via manual means.
But automation is the king so it's a nice feature to have it in the software
implemented.

If we could just stop and move on whenever software is capable of doing what
they are intended for as smooth as possible, many of these issues would
diminish to exist.

------
fleitz
Am I missing something? Is lesspipe run as root? What could you execute via
lesspipe that you couldn't from the command line?

~~~
gear54rus
> Ultimately, I think that there's an expectation that running less on a
> downloaded file won't lead to RCE

When you use less, you do not expect any code to be executed, and this article
shows how this might be the case (through unexpected invocations of other
utilities which may have bugs in them).

There are many ways to go from normal shell to root shell after that.

~~~
danielweber
There's not a firm list, but certain commands should always be safe to run
against hostile input.

If I type "make" on a project I downloaded, arbitrary stuff gets run. I accept
that as part of make.

If I sha256sum a hostile file, that should never lead to RCE.

~~~
tedunangst
If you open a PDF, that should never lead to RCE, but that's not the world we
live in. Better for tools not to open PDFs when you don't expect that to
happen.

~~~
danielweber
It depends what's hiding in the word "open."

If I open a PDF in a full-featured reader, I'm slightly ill at ease. If I
sha256sum it or wc it, I should be (read: ought to be, in any sane world)
perfectly at ease. No matter how complicated the data structures in it, they
shouldn't affect those programs.

~~~
tedunangst
As per the link, I'm talking about less "opening" a PDF by shelling out to
pdftotext. "Hiding" is a good word for the behavior. :)

------
pmontra
I checked what I have on my Ubuntu 12.04.

$ env|grep LESS

LESS= -R

LESSOPEN=| /usr/share/source-highlight/src-hilite-lesspipe.sh %s

Safe, as long as source-highlight isn't buggy.

I also checked my .bashrc and found this

# make less more friendly for non-text input files, see lesspipe(1)

# NO! I don't want this!

# [ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

So yes, lesspipe was the default and for some reason I commented it out. I
vaguely remember at being annoyed about less showing me something different
from the actual binary content of the files.

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

I just ran less on a dir in Ubuntu Trusty (latest LTS) and got the expected
"<dir> is a directory" message.

------
reubenbond
Less really is more

~~~
fidz
Using Ubuntu 12.04

    
    
            md5sum /bin/less /bin/more 
            4be69e915a4b4514d3d06ee07dd56a68  /bin/less
            11fc84952b1f31a91b5b6ec29740e497  /bin/more
    
    

Or it just my system?

~~~
ars
/bin/more is in the util-linux package.

Less can pretend to be more if run that way, but debian also does ship the
real more command.

------
Glyptodon
Should this show when I run env or not?

~~~
jlgaddis

      $ env | grep ^LESS
      LESSOPEN=||/usr/bin/lesspipe.sh %s
    
      $ cat /etc/redhat-release 
      Red Hat Enterprise Linux Server release 6.6 (Santiago)

------
guard-of-terra
That's why

    
    
      alias less=/usr/share/vim/macros/less.sh

~~~
Aissen
I used to do that with vimpager (a better implementation of this shell
script). Unfortunately this cannot work as it doesn't process data as it
arrives, you need to wait for input to end. So it's only good for fast & short
commands.

~~~
guard-of-terra
Sure, but I have a separate alias for streams. alias -g even, zsh-style.

------
zobzu
but also vim. and irssi. and gpg. and a bunch of other day to day linux
programs nobody bothered to review very thoroughly.

Just any case anybody still believe its just java, flash, openssl and bash
that suffers bad vulns (oh oh oh).

------
Sami_Lehtinen
Using cat in terminal can get you owned.

------
jacquesm
rm /bin/less

Problem solved.

Any binary utility that I haven't used in a 6 month period can get lost. The
problem is that there are probably a hundred or so more issues like this
hiding in /bin/* and /usr/bin/* and wherever else executables are hiding.

Is there a way to retrofit 'can shell out' as a capability flag not unlike the
regular access permission bits?

~~~
edwintorok
You probably did use less in the past 6 months if you used Linux in the past 6
months. less is usually the default pager for things like 'man', 'git log',
etc.

But as pointed out in another comment the problem is not with 'less', but with
some distros configuring it to use 'lesspipe' as preprocessor.

------
upofadown
I checked on Debian Jessie and the /usr/bin/lesspipe script runs entirely off
the file extension. So there is no issue with less itself. If someone sends
me, say, a malicious doc file I would have to type "less blort.doc" to get
owned by catdoc. The only time i would ever type that is if I knew that less
would invoke catdoc, that I actually had catdoc installed on the machine and
for some reason I wanted to use catdoc to look at a doc file.

Less only installs a mailcap entry for "text/*". A mail reader that could not
handle plain text itself would not be much of a mail reader.

That also means that it is kind of stupid to have less display non-text
things. Still not a real security issue.

~~~
gwern
User continence works great until someone figures out how to get lesspipe
called automatically...

' _I_ would never run bash manually on unsanitized input from HTTP requests!'
[years pass] /shellshocked!

~~~
upofadown
Pretty sure that shellshock doesn't involve any manual invocation of bash....

~~~
gwern
You're right, it doesn't. Think a little harder.

