On Linux, 'less' can probably get you owned

http://seclists.org/fulldisclosure/2014/Nov/74

by adamnemecek • 12 years ago

302 130 12 years ago

fleitz• 12 years ago

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

Moral_• 12 years ago

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.

gear54rus• 12 years ago

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.

andreasvc• 12 years ago

And there is no need to get root to do serious damage, rm -r ~/* comes to mind.

orblivion• 12 years ago

So what's the point of root? To keep me out but let malicious people in?

danielweber3• 12 years ago

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.

jlgaddis3• 12 years ago

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

vezzy-fnord• 12 years ago

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

danielweber3• 12 years ago

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

userbinator3• 12 years ago

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.

alayne• 12 years ago

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.

jschwartzi3• 12 years ago

To be fair, the usefulness of a tool is often proportional to your power to also do really dumb things with it.

fafner• 12 years ago

lesspipe is not a GNU project...

TorKlingberg• 12 years ago

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

oblio• 12 years ago

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

mrmondo• 12 years ago

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

steakejjs• 12 years ago

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.

pjmlp6• 12 years ago

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

rquirk• 12 years ago

This is covered in the fuzzing project's FAQ https://fuzzing-project.org/faq.html

"if you start a new software project it is a good idea to avoid C right from the start. however ... most major software components we use today [are] written in C. Rewriting things from scratch is hard, compared to that finding bugs with fuzzing is the low hanging fruit."

While something like Go has good performance, writing low-level tools in interpreted languages (Python, Ruby, etc) means you would always have the performance overhead of firing up the interpreter for everything. A hypothetical non-C system would feel sluggish compared to what we have now.

gurkendoktor2• 12 years ago

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.

zurn• 12 years ago

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.

reubenbond• 12 years ago

Less really is more

jlgaddis3• 12 years ago

Indeed.

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

fidz• 12 years ago

Using Ubuntu 12.04

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

Or it just my system?

ars3• 12 years ago

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

Anthony-G• 12 years ago

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

Glyptodon• 12 years ago

Should this show when I run env or not?

jlgaddis3• 12 years ago

  $ env | grep ^LESS
  LESSOPEN=||/usr/bin/lesspipe.sh %s

  $ cat /etc/redhat-release 
  Red Hat Enterprise Linux Server release 6.6 (Santiago)

viraptor2• 12 years ago

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.

jschwartzi3• 12 years ago

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.

reirob3• 12 years ago

Absolutely agree! It's even more true for closed source software like Skype - to be able to prevent it from accessing to data it doesn't have to.

I know there are many alternatives to Skype, but there are people that have to use it from time to time for professional reasons.

I started doing this for Skype on Ubuntu 14.04 - but have to admit that I quickly ran out of steam. Need to pick up where I ended.

x0x04• 12 years ago

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.

hrktb• 12 years ago

I think this approach would still fail if the program is not behaving as expected by the user.

For instance, I didn't know until reading this article that 'less' on ubuntu went through lesspipe, but the people maintaining the tools know that. If for some legitimate use case lesspipe needed access to the internet, the local database could allow that behavior without any warning, but as a user I would still be dumbfounded that a 'less' command ends up generating network connections.

jfindley4• 12 years ago

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)

hobarrera• 12 years ago

basically all modern distros shipping SELinux as default.

No on ArchLinux, Gentoo, and apparently, not on Debian.

I also remember that the default settings were not sane on older versions of Fedora (this may have since changed): sshd would get killed by selinux because of some "violation". I never managed to understand what it was, and since sshd is kind of critical, I disabled SELinux so I could be sure not to lose access to that machine.

The added problem regarding SELinux is that most user's have no idea how it works, and there's no "short" explanation for it. Even after reading the entire wikipedia article, I'm left scratching my head wondering how it work or how one would use it.

OTOH, file modes, for example , are explained in a single paragraph, and is something extremely easy to understand.

username2232• 12 years ago

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.

userbinator3• 12 years ago

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

    less: somedir: is a directory

cbd1984• 12 years ago

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.

naner• 12 years ago

I believe that is the point of the linked email. Some distributions have less symlinked to something else (e.g. the lesspipe script) for convenience. Plain 'ol less isn't that much of a problem.

username2232• 12 years ago

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?

dllthomas• 12 years ago

My understanding is that the less codebase has the hooks (LESSOPEN and LESSCLOSE), and it's configurable (by presence or absence of the variables) whether they're used.

raverbashing• 12 years ago

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.

ars3• 12 years ago

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

lmm3• 12 years ago

More advanced is exactly the problem here.

If you use a simpler program like 'more' or 'pg', you won't have these kinds of vulnerabilities.

Animats3• 12 years ago

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• 12 years ago

"strings" is also vulnerable: http://lcamtuf.blogspot.com/2014/10/psa-dont-run-strings-on-...

Inspecting files is apparently hazardous.

MichaelGG2• 12 years ago

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.

Animats3• 12 years ago

You're right; it was "strings" last month, not "file".

jacquesm• 12 years ago

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?

MichaelGG2• 12 years ago

Or just unset LESSOPEN ?

edwintorok• 12 years ago

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.

fsniper• 12 years ago

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.

pmontra• 12 years ago

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.

zobzu• 12 years ago

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

guard-of-terra2• 12 years ago

That's why

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

Aissen• 12 years ago

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-terra2• 12 years ago

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

upofadown2• 12 years ago

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.

gwern2• 12 years ago

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!

upofadown2• 12 years ago

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

michaelcampbell• 12 years ago

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.

Sami_Lehtinen• 12 years ago

Using cat in terminal can get you owned.

On Linux, 'less' can probably get you owned

Related Stories