Tuesday, October 28, 2014

Thoughts on the First Steps of Wake's JS Interop

For the last several months I have been creating the language Wake, and now with hard work and help from friends its nearing feature completion as a usable language. However, there's a huge goal of the project that has yet to be realized -- compiling to multiple languages, and having smooth interoperability with them.

At the moment wake compiles to javascript, so that's where our interop features will begin. My original plan for Wake's js interop was to create a whole new compiler from scratch, written in wake, that compiled a file with a custom syntax, and spat out ordinary wake compiler artifacts:

wake-js-interop JQuery.wkjs -d bin/waketable -o bin/wakeobj/JQuery.o
creates files: bin/waktable/JQuery.table, bin/wakeobj/JQuery.o

There does have to be some "glue" code that sits between Wake world and real JQuery, so JQuery.o is the glue and JQuery.table describes its usage to the Wake compiler. JQuery.wkjs would usually look like simple wake, but other things would be very custom syntax.

every JQuery is:
    Object[] -- map(Object[] what, Object fn(Object) mapper) = "$.map(what, mapper)"
    JQElements -- find(Text selector) = "return $(selector)";

What are the problems with this approach? Well you take into account all of the semantics and file encoders and everything else that has already been written in the wake compiler, from inheritance to interfaces to providers to circular dependency relationships, its a ton of work to do. Meanwhile, the first step would be to code a clone of Yacc in wake which is its own difficulty. So last night I took a different approach and its a solid proof of concept! Simply create an abstract class in Wake

every Console is:

compile its table file (usage definitions) only:

wake Console.wk -d bin/waketable -t

and use the 'wake-js-gen' github project on the table file (in this case the last argument is saying that we're wrapping the singleton var named "console" but there are other options such as wrapping constructors)

wake-js-gen bin/waketable Console bin/wakeobj/Console.o console

and now you can console.log in js from wake!


In the immediate moment, I'll probably use this to create some simple wrappers for JQuery, Regexp, etc. so that we can code against them ASAP. But next, we have to come up with a strategy for making this more flexible. But I'm thinking about bringing in annotations for the task:

extern JQuery is:
// 'extern' instead of 'every' will tell the compiler not to create a .o file
// and that these abstract methods aren't abstract

    @Js("return $(selector)")
    JQElements -- find(Text selector);

    Object[] -- map(Object[], Object fn(Object));

This way your wake source code can be the master copy, and the tools can still be codegen-only, no validation or parsing. Not only does it make my job easier for the js generator, but it makes my job easier for every other language we support from here on, and it makes it easier for others to come by and create these generators themselves. What do you think? Is this a good interop strategy or a bad one?

Thursday, October 2, 2014

The Am I Vulnerable To Shellshock Checklist

There are a ton of people sharing a test to see if your shell is vulnerable to shell shock. However, exploiting the shellshock bug (unlike heartbleed) requires multiple failure points.

It is impossible to precisely define these failure points, and this has the internet in much more fear than is actually warranted. Are you concerned about your vulnerability to the shellshock bug? Perhaps after reading this checklist you will change your mind.

Disclaimer: This checklist is not comprehensive, and will not necessarily be up to date. This checklist attempts to be accurate for the vast majority of servers as of the time it is written. Use your own brains too.

1. Are you on a unix system?

This includes mac, freeBSD, solaris, and linux. If no, you are not vulnerable. Otherwise, proceed to step 2.

2. Are you on a server or a personal computer?

Only servers, or personal computers with server software installed, are likely to be vulnerable. If you don't know, you can probably call yourself safe. Otherwise proceed.

3. Are you using apache mod-cgi or restricted ssh sessions?

If you are using apache mod-cgi proceed to step 4. As for ssh, of course all ssh sessions are restricted except for root, but don't be concerned just yet. In this case the type of restricted ssh session we are referring to means that you have a file in ~/.ssh/authorized keys that limits a user with a key to a specific command. If you are using this on your server proceed to step 5. Otherwise go to step 6. Note that realistically anyone using mod-cgi should patch, just in case. It's really crazy not to if you are using mod-cgi at all.

4. Are you using bash scripts in your cgi bin?

If you use !#/bin/bash then you need to patch. If not, go to step 12.

5. Do any malicious parties have an authorized key to your server?

If so you are vulnerable. If not, you are vulnerable to non-malicious parties doing more than they are supposed to, which is another but less severe type of vulnerability. Patch before they do non-malicious things by breaking out of their session restrictions.

6. Congratulations, you have no mass-targetable vulnerabilities!

At this point you are only vulnerable to targeted attacks from parties that specifically dislike you. Remember that you have a lot to worry about should this be the case, and shellshock might not be the most important thing to patch. exec($_REQUEST(...)) comes to mind as something a bit more pressing than shellshock. Continue to step 7.

7. Do you have any open ports to custom apps?

Noncustom apps could have vulnerabilities too, but so far none have yet come up aside from the two mentioned. For this reason we'll look at custom apps only - web services, database services, etc. If you don't, you are probably completely safe from shellshock! Otherwise proceed to step 8.

8. Do your custom apps set any environment variables based on user input?

This is unlikely. In fact, github searches reveal that php codebases are about 10x more likely to be executing arbitrary user input as setting it in an environment variable. If your custom apps and the libraries they use aren't doing this, you are completely safe from shellshock exploits. Otherwise, keep going on to step 9.

9. Are there high restrictions to setting these environment variables?

Take a moment to reflect on the restrictions of your last answer. When users can set environment variables on your system, do they need to be on a certain IP? Do they need a password? These things might protect you adequately. If not, you may be surprised to hear that we still aren't at an exploit yet and you'll need to go to step 10.

10. Could your custom app run any system commands after setting these variables?

Defining this failure point is difficult and varies from app to app. Some apps like PHP may set an environment variable in a process only responsible for a single page load. Other apps might set it in a persistent daemon. Any processes spawned from these places will inherit the environment variables. Should such a process invoke a system command (even something harmless like `ls`), proceed to step 11. Otherwise, you are safe, but in dangerous waters since custom apps usually change over time.

11. Is your user's default shell bash?

This is either possible with a unix user's configuration, or with a symlink from /bin/sh to /bin/bash. If neither of these things have happened, go to step 12. Unfortunately, if bash is your default shell, you are vulnerable.

12. Are any of your invoked commands bash?

By this I mean, does /bin/sh every invoke the command 'bash ...'? Note that environments are inherited across processes, so you are equally vulnerable if sh launches a process that launches bash. If not, you are in severely dangerous waters but are technically probably safe for now. Congratulations for being right on the edge! To everyone else, you need to patch.

Its far worse than I thought!

thought noone ever. As you can see, the shellshock attack only has certain avenues of effective attacks, and severely limited avenues to targeted attacks. You likely have higher things to worry about, like updating your wordpress site and protection from XSS attacks. There are probably more websites storing passwords in cleartext than websites vulnerable to shellshock.

A blogger claimed to have found three thousand vulnerable servers, but never responded to my comment asking how many total servers had been scanned in the process. Until the answer comes out, we can only assume from the author's tone that it is "very low." The checklist here supports this.

I already made my disclaimer, this list might have some holes for niche servers. Anyone with critiques of my checklist are welcomed and I'll do my best to correct inaccuracies.