Re: Extensions review

[drago01 <drago01 gmail com>]

On Mon, May 26, 2014 at 9:01 AM, Dodier-Lazaro, Steve
<s dodier-lazaro 12 ucl ac uk> wrote:
> You're right, Carlos. In an environment where all apps are contained, Shell
> extensions would be a very very neat entry point for malware. Jasper
> probably is the authority on this but I have serious doubts that anything
> can be done to secure Shell extensions. From the fact that extensions
> shouldn't do sync I/O, I understand that their code runs in the same
> thread(s) as the rest of the shell.

Yes that how extensions work they change any part of the shell's ui
code through monkey patching, there isn't any much of a defined api.


> This effectively prevents making only
> the extensions' API's memory pages executable to extension-running threads,
> for instance.

No you can't do that.

> It also doesn't make sense to sandbox something which is
> expected to have such a central access to your system.

That's correct.

> In other words, extension code is very dangerous and reviews should be very
> thorough. The problem is when it comes to security, an extension won't be
> bad because it looks bad or code like "myVariable = allUserData;
> update_to_evil_website(myVariable)". It'll be funky pointer arithmetic and
> variable contents that nobody really understands,

Well you can't really do pointer arithmetic in JS but any obfuscated
code or code
that the reviewer does not understand should not pass review.

> or shellcodes hidden
> inside an alleged Web API's application key, etc. It'll be subtle and you'll
> probably need to be very good at JS, know GJS very well and have good
> security credentials to spot it. Then beyond exploits within the code (of
> various degrees of clarity), you should look out for any processing of
> untrusted data: app windows, documents, absolutely anything coming from the
> Internet without authentication on an encrypted channel. How does it
> interact with the program? Are you absolutely certain that there is no bug
> or no quirky operation that could result in e.g. buffer overflows, strange
> operations on potentially-shellcode-containing variables, etc.?

You cannot be "absolutely certain" that the code does not trigger a
buffer overflow (or jump to an arbitrary heap address or whatever) you
cannot prove security for non trivial cases you can only
prove non security.

Also why would you try to run shell code if you can simply eval() a JS
string that you get from somewhere ... would be way easier.

But anyway hidding in an extension in a way to not get noticed by a
reviewer (i.e it has to look like legit code that does something
useful) is not as trivial as you might think.