On Linux, 'less' can probably get you owned

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

[oblio]

I'll be in the other camp. At least for directories, I like whatever magic distros do so that I get a file listing when using less on a directory, and can then less an actual file.

Features are nice - and ultimately in this scenario you'd just get owned 5 mins later when your archiving tool would get hacked directly, instead of through less.

The regular user won't use less to check the binary content for malware anyway...

[fafner]

lesspipe is not a GNU project...

[alayne]

This sounds more like a problem with gluing a bunch of "stuff" together with shell scripts that are not well thought out than a problem with less or GNU in general having untested features.

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

[jfindley]

This is a good point, and I fully endorse the sentiment, but please remember that for basically all modern distros shipping SELinux as default (not counting android), the default is for users to be unconfined.

This means that in a lot of cases, SELinux won't save you from this, unless you've decided to confine your users (which is by no means impossible - I do so - but requires a bit more knowledge of SELinux than "usual" SELinux tasks)

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

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

[zurn]

It's good to keep spreading awareness and AFL is cool. As for proving new things... fuzzing has been actively used for security research for 15+ years, and by now it's common knowledge that C/C++ programs are rarely safe against untrusted input.

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

Inspecting files is apparently hazardous.

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

[ars]

You may also want to try the 'most' command, which is like less but more advanced.

[raverbashing]

We need a less that does less than less today but more than more

This reminds me of an old program called list.com that could open anything as a text file. Any size whatsoever, any line size, etc.

[userbinator]

I suppose this would be the more straightforward and expected behaviour:

    less: somedir: is a directory

[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

[danielweber]

I was idly wondering about "less" a month ago. 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.

[Moral_]

>Is lesspipe run as root?

Not normally

>What could you execute via lesspipe that you couldn't from the command line?

Nothing, but running lesspipe on some file shouldn't lead to remote shell being opened to some guy in Russia.

[jlgaddis]

Imagine the case where someone sends you a malicious file and you open it with less.

[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

[jlgaddis]

Indeed.

  $ sha256 /usr/bin/less /usr/bin/more
  SHA256 (/usr/bin/less) = 9d517bcdf5bb22e756337ee450657de4d4edba779f7c17acfcaf7ba71f76bf59
  SHA256 (/usr/bin/more) = 9d517bcdf5bb22e756337ee450657de4d4edba779f7c17acfcaf7ba71f76bf59

[Anthony-G]

The `more` command is often provided by `util-linux` package.

Ubuntu 12.04:

    dpkg -S /bin/more /bin/less

    util-linux: /bin/more
    less: /bin/less

CentOS 5.10:

    rpm -qf /bin/more /usr/bin/less

    util-linux-2.13-0.59.el5_8
    less-436-9.el5

[fidz]

Using Ubuntu 12.04

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

Or it just my system?

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

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

[MichaelGG]

Or just unset LESSOPEN ?

[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!