FW: Proposal: safeEval

Thu Jun 21 01:52:49 UTC 2018

Thanks

How can we discuss your idea separately from the library?

I’m more thinking at the runtime level than at the “user land”. To be honest, I don’t care of “safeEval” on “user land”.

You talk about options and ACLs but the only hint as to what those might mean is the library

How would the idea work if not by tree filtering?  AdSAFE did that but writing AdSAFE was very different from writing vanilla JS.

Yeah, sorry. The purpose is to offer something like “opcode” filtering, but in a more expressive and user-friendly way.

Claude

From: Mike Samuel <mikesamuel at gmail.com> 
Sent: Wednesday, June 20, 2018 9:37 PM
To: doodad-js Admin <doodadjs at gmail.com>
Cc: Isiah Meadows <isiahmeadows at gmail.com>; es-discuss <es-discuss at mozilla.org>
Subject: Re: FW: Proposal: safeEval

How can we discuss your idea separately from the library?

You talk about options and ACLs but the only hint as to what those might mean is the library.

How would the idea work if not by tree filtering?  AdSAFE did that but writing AdSAFE was very different from writing vanilla JS.

On Wed, Jun 20, 2018, 9:12 PM doodad-js Admin <doodadjs at gmail.com <mailto:doodadjs at gmail.com> > wrote:

I don't want to propose you my library, I want to propose you the idea.

-----Original Message-----
From: impinball at gmail.com <mailto:impinball at gmail.com>  <impinball at gmail.com <mailto:impinball at gmail.com> > On Behalf Of Isiah Meadows
Sent: Wednesday, June 20, 2018 7:57 PM
To: Mike Samuel <mikesamuel at gmail.com <mailto:mikesamuel at gmail.com> >
Cc: doodad-js Admin <doodadjs at gmail.com <mailto:doodadjs at gmail.com> >; es-discuss <es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> >
Subject: Re: FW: Proposal: safeEval

Just a quick read, but that's a *terrible* set of ACLs, and I strongly dislike the idea in general. That utility is trivially broken in multiple ways (won't announce them on-list, but I've emailed Claude privately), and I'm pretty convinced the idea itself is broken.
Limiting syntax is incredibly ineffective for anything security-related, because there are an infinite number of ways to express something in JS, but only a finite number of ways you can realistically limit it without breaking it for normal users or just disabling scripting altogether. It also doesn't stop them from accessing various globals to screw with you.

To give a concrete example of why syntactic analysis is a bad idea for security, let's consider eBay's encounter with JSFuck [1] [2]. Because that literally uses only six seemingly benign characters, `[`, `]`, `!`, `+`, `(`, and `)`, you can only protect against it by disallowing calls, which make general use nearly impossible. It was difficult enough that eBay initially gave up [2], until it resulted in rampant, virtually untraceable fraud in the wild [3].

Now, if you disallow parentheses, you also have to ban assignment if any of your scripts has an ID [4], because attackers can use that to their advantage to accomplish the same objective. Claude has an option for that in his library, but it's not especially obvious you'd need it to prevent arbitrary code execution.

Frozen realms together with closures provide privilege separation through offering capabilities, which addresses who can read and/or write what. Capabilities are better than ACLs when it comes to security, because if you limit what they can try, they can't do what they can't try. They can't read what they can't even try to access.

If you want real security, focus on what people can try, not what they can do. And this is why I say this entire proposal is complete and utter crap.

[1]: https://github.com/aemkei/jsfuck
[2]: https://arstechnica.com/information-technology/2016/02/ebay-has-no-plans-to-fix-severe-bug-that-allows-malware-distribution/
[3]: https://news.softpedia.com/news/jsf-ebay-xss-bug-exploited-in-the-wild-despite-the-company-s-fix-500651.shtml
[4]: http://syllab.fr/projets/experiments/sixcharsjs/5chars.html

-----

Isiah Meadows
me at isiahmeadows.com <mailto:me at isiahmeadows.com> 
www.isiahmeadows.com <http://www.isiahmeadows.com> 

On Wed, Jun 20, 2018 at 3:51 PM, Mike Samuel <mikesamuel at gmail.com <mailto:mikesamuel at gmail.com> > wrote:
>
>
> On Wed, Jun 20, 2018 at 2:26 PM doodad-js Admin <doodadjs at gmail.com <mailto:doodadjs at gmail.com> > wrote:
>>
>>
>>
>> I was not aware of that proposal or didn’t pay attention.I think 
>> “safeEval” provides ACLs, while your proposal don’t.
>
>
> Neither the realms proposal nor the frozen realms proposal include ACLs.
>
> Where are the ACLs in safeeval?
> I see some privileges via options at L72-75:
> const preventAssignment = types.get(options, 'preventAssignment', 
> true), allowFunctions = types.get(options, 'allowFunctions', false), 
> // EXPERIMENTAL allowNew = types.get(options, 'allowNew', false), // 
> EXPERIMENTAL allowRegExp = types.get(options, 'allowRegExp', false); 
> // EXPERIMENTAL but, as I understand the term, ACLs are usually the 
> set of privileges available to a principal, the rows in an access 
> control matrix.
> How are you defining "principal?"
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> 
> https://mail.mozilla.org/listinfo/es-discuss
>

---
This email has been checked for viruses by AVG.
https://www.avg.com

 <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 

Virus-free.  <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avg.com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180620/2342a92c/attachment-0001.html>