From rodrigo at kernelhacking.com  Tue Feb  2 03:51:59 2010
From: rodrigo at kernelhacking.com (Rodrigo Rubira Branco (BSDaemon))
Date: Tue, 02 Feb 2010 06:51:59 -0200
Subject: [Dailydave] Remote Vulnerability in AIX RPC.cmsd released by
	iDefense
Message-ID: <4B67E7AF.9060902@kernelhacking.com>

Hey guys,

Just now I saw that iDefense did not include in their advisory the
triggering code for this
(http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=825). 
I believe it's very important to test your
systems and verify the released patch.

So here we go:
http://www.kernelhacking.com/rodrigo/exploits/cmsd_exploit.c



Regards,


Rodrigo (BSDaemon).


--
Rodrigo Rubira Branco (BSDaemon)
"Kernel Hacking:  If you really know, you can hack!"

From dave at immunityinc.com  Wed Feb  3 11:52:34 2010
From: dave at immunityinc.com (dave)
Date: Wed, 03 Feb 2010 11:52:34 -0500
Subject: [Dailydave] ASLR+DEP = no problem. :>
Message-ID: <4B69A9D2.6060207@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Not so long ago, ASLR and DEP were gaining wide acceptance. Execshield
was on almost all Linux systems, and the "golden age" of buffer overflow
exploitation looked like it was coming to a close.

It is true that the code is getting better, and the mitigating
protective mechanisms in Windows and Linux are getting better. But like
in a ceramic, the physical properties of a system are defined by the
interfaces between components, not the crystals themselves.

Today, Immunity released a working version of the Aurora exploit for
Windows 7 and IE8 today to CANVAS Early Updates. It does this by playing
some very odd tricks with Flash's JIT compiler. This technique is
extendible to almost all similar vulnerabilities. In other words, ASLR
and DEP are not longer the shield they once were.

I believe Dionysus Blazakis is going to release some details on a
similar technique at BlackHat DC today. If you miss the rest of the
talks, I'd recommend popping into that one. :>

Thanks,
Dave Aitel
Immunity, Inc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAktpqdIACgkQtehAhL0gheotCACfXVRvzHVKxVYWWYQigY7fKPi9
aL0AnjmW40zWTjtwitHJO3Fcv1z9F9QI
=l0KE
-----END PGP SIGNATURE-----

From Thierry at Zoller.lu  Thu Feb  4 06:14:27 2010
From: Thierry at Zoller.lu (Thierry Zoller)
Date: Thu, 4 Feb 2010 12:14:27 +0100
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <4B69A9D2.6060207@immunityinc.com>
References: <4B69A9D2.6060207@immunityinc.com>
Message-ID: <212838605.20100204121427@Zoller.lu>

Hi,
This -
>It does this by playing some very odd tricks with
>Flash's JIT compiler.
+
>In other words, ASLR
>and DEP are not longer the shield they once were.
Doesn't compute. You are relying on oddities, fix
the oddities and ASLR/DEP are back again.

-- 
http://blog.zoller.lu
Thierry Zoller



From mtrancer at gmail.com  Thu Feb  4 13:29:39 2010
From: mtrancer at gmail.com (Moshe Ben Abu)
Date: Thu, 4 Feb 2010 20:29:39 +0200
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <212838605.20100204121427@Zoller.lu>
References: <4B69A9D2.6060207@immunityinc.com>
	<212838605.20100204121427@Zoller.lu>
Message-ID: <184a9c291002041029g42efc41do1f1a237351904551@mail.gmail.com>

Yep, I agree with Thierry, once the technique will be fixed - ASLR+DEP = big
problem :(

Past examples:
 - Java Virtual Machine Heap Spray > Java is out of process since 1.6.0u10.
 - Actionscript Heap Spray > Flash 10 got DEP and ASLR.
 - .NET User Control binary > Internet Explorer 8 RTM blocks it on Internet
Zone.

In addition, latest versions of Adobe Reader, QuickTime and .NET Framework
got DEP and ASLR enabled too...

On Thu, Feb 4, 2010 at 1:14 PM, Thierry Zoller <Thierry at zoller.lu> wrote:

> Hi,
> This -
> >It does this by playing some very odd tricks with
> >Flash's JIT compiler.
> +
> >In other words, ASLR
> >and DEP are not longer the shield they once were.
> Doesn't compute. You are relying on oddities, fix
> the oddities and ASLR/DEP are back again.
>
> --
> http://blog.zoller.lu
> Thierry Zoller
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>



-- 
Trancer
Recognize-Security
http://www.rec-sec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20100204/cf3c8c46/attachment.htm 

From Thierry at Zoller.lu  Thu Feb  4 14:06:33 2010
From: Thierry at Zoller.lu (Thierry Zoller)
Date: Thu, 4 Feb 2010 20:06:33 +0100
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <7E943919-F924-4AA0-A6D9-F3F07770687D@gmail.com>
References: <4B69A9D2.6060207@immunityinc.com>
	<212838605.20100204121427@Zoller.lu>
	<7E943919-F924-4AA0-A6D9-F3F07770687D@gmail.com>
Message-ID: <1934474274.20100204200633@Zoller.lu>


Hi,

>With all respect, you should read the paper before throwing your
>unfounded thoughts about something you don't even know about.
Why refer to respect when all you write afterwards is full of despise
and   arrogance   ?   Your   capability   to   read   my mind is still
lacking ;) , apparently you thought you know - What I read and
what I know. Sorry to inform you that you are wrong on both.

>now, after reading the paper let me know if it requires a 'fix' as you
>said, or a re-design/engineering and re-implementation of the JIT
>itself. ;)
Does not compute either. By "fix" I abviously assumed "redesign/eginner"
the JIT. The point was that ASLR/DEP is not dead because of error in a
JIT.


-- 
http://secdev.zoller.lu
Thierry Zoller



From dave at immunityinc.com  Thu Feb  4 14:09:46 2010
From: dave at immunityinc.com (dave)
Date: Thu, 04 Feb 2010 14:09:46 -0500
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <184a9c291002041029g42efc41do1f1a237351904551@mail.gmail.com>
References: <4B69A9D2.6060207@immunityinc.com>	
	<212838605.20100204121427@Zoller.lu>
	<184a9c291002041029g42efc41do1f1a237351904551@mail.gmail.com>
Message-ID: <4B6B1B7A.4040502@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know I'm annoying Spender by even replying, but this sort of thing is
not dependant on Flash. It's simply a function of "Any JIT the attacker
can pass data into will break DEP/ASLR". The only "solution" is to have
every available JIT have defined entry points that the kernel enforces
(which will prevent EIP from going into the middle of a JIT'd function).

At that point you basically have "Determina" and you take a performance
hit, which is what JIT is supposed to avoid. Or you can turn all
non-trusted code JITs off. Then it comes down to "what is trusted?" and
"wow, my flash code runs really slow now" and all sorts of other hilarity.

You could, as you point out, move things out of the process. But there's
a certain value to having things IN the process and not blocked by
default. Netflix requires Silverlight which requires .Net which has a
dynamic API that supports Eval(). Flash is technically the worst JIT to
use for this since you can't use Eval() (or other dynamic techniques) to
generate functions at runtime.

And it doesn't matter that Reader/Quicktime/.Net have DEP and ASLR
enabled. Our Aurora exploit works on Windows 7, and DEP/ASLR was
enabled. Nicolas Pouvesle (who lead the team that worked on this here at
Immunity) updated our version today to work on 32-bit IE on 64-bit
Windows 7 - there's a lot of annoying little issues to work around here.

But those issues aren't roadblocks. Any if Flash gets annoying to work
with, you can do this with VBScript or any JIT that is in the browser.
You can use this on bugs for anything that sits in a process with a JIT
- - from Adobe Reader, to Java, to Flash to Word/PPT/XLS.

There's lots of ways to break DEP and ASLR. Information leakages are the
best way really. But JITs help break DEP/ASLR too. In the end
mitigations just buy the leading edge adopters a couple of years until
the offensive research teams turn their attention to them.

Spender would say all this stuff is obvious, but we're happy to write
exploit after exploit to demonstrate it anyways. :>

- -dave





Moshe Ben Abu wrote:
> Yep, I agree with Thierry, once the technique will be fixed - ASLR+DEP =
> big problem :(
> 
> Past examples:
>  - Java Virtual Machine Heap Spray > Java is out of process since 1.6.0u10.
>  - Actionscript Heap Spray > Flash 10 got DEP and ASLR.
>  - .NET User Control binary > Internet Explorer 8 RTM blocks it on
> Internet Zone.
> 
> In addition, latest versions of Adobe Reader, QuickTime and .NET
> Framework got DEP and ASLR enabled too...
> 
> On Thu, Feb 4, 2010 at 1:14 PM, Thierry Zoller <Thierry at zoller.lu
> <mailto:Thierry at zoller.lu>> wrote:
> 
>     Hi,
>     This -
>     >It does this by playing some very odd tricks with
>     >Flash's JIT compiler.
>     +
>     >In other words, ASLR
>     >and DEP are not longer the shield they once were.
>     Doesn't compute. You are relying on oddities, fix
>     the oddities and ASLR/DEP are back again.
> 
>     --
>     http://blog.zoller.lu
>     Thierry Zoller
> 
> 
>     _______________________________________________
>     Dailydave mailing list
>     Dailydave at lists.immunitysec.com <mailto:Dailydave at lists.immunitysec.com>
>     http://lists.immunitysec.com/mailman/listinfo/dailydave
> 
> 
> 
> 
> -- 
> Trancer
> Recognize-Security
> http://www.rec-sec.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAktrG3kACgkQtehAhL0gheqiewCdEj0/fhGaW1uB/EIDxmrz7PUT
5BAAnRxNyNywGxGevcNZ/FO9ysgQM6JO
=/TB8
-----END PGP SIGNATURE-----

From mjw at cyberwart.com  Thu Feb  4 14:31:35 2010
From: mjw at cyberwart.com (Matthew Wollenweber)
Date: Thu, 4 Feb 2010 14:31:35 -0500
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <184a9c291002041029g42efc41do1f1a237351904551@mail.gmail.com>
References: <4B69A9D2.6060207@immunityinc.com>
	<212838605.20100204121427@Zoller.lu>
	<184a9c291002041029g42efc41do1f1a237351904551@mail.gmail.com>
Message-ID: <5fb633321002041131yfcaf597ic910e7f99303b3ea@mail.gmail.com>

I saw the talk and I'm not sure how exactly you easily fix the problem. The
speaker didn't organize the talk optimally and TSA screaming next door
didn't help either, however it seems difficult to fix being able to fix
shellcode generated by valid actionscript code. Additionally, the JIT spray
was fairly small and according to the speaker had a greater than 90%
reliability.

The most common attack vectors (IMO) appear to be PDFs and IE. Adobe
squashing Flash seems unlikely and I can't imagine Flash generically being
blocked on any large level (within the next year or until HTML5 is more
universal).

I still haven't made it through the paper (
http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Slides-v2.pdf) for
all the details so my thoughts are only based on believing the speaker (who
I don't know), but it was very interesting to me and appears promising.


On Thu, Feb 4, 2010 at 1:29 PM, Moshe Ben Abu <mtrancer at gmail.com> wrote:

> Yep, I agree with Thierry, once the technique will be fixed - ASLR+DEP =
> big problem :(
>
> Past examples:
>  - Java Virtual Machine Heap Spray > Java is out of process since 1.6.0u10.
>  - Actionscript Heap Spray > Flash 10 got DEP and ASLR.
>  - .NET User Control binary > Internet Explorer 8 RTM blocks it on Internet
> Zone.
>
> In addition, latest versions of Adobe Reader, QuickTime and .NET Framework
> got DEP and ASLR enabled too...
>
> On Thu, Feb 4, 2010 at 1:14 PM, Thierry Zoller <Thierry at zoller.lu> wrote:
>
>> Hi,
>> This -
>> >It does this by playing some very odd tricks with
>> >Flash's JIT compiler.
>> +
>> >In other words, ASLR
>> >and DEP are not longer the shield they once were.
>> Doesn't compute. You are relying on oddities, fix
>> the oddities and ASLR/DEP are back again.
>>
>> --
>> http://blog.zoller.lu
>> Thierry Zoller
>>
>>
>> _______________________________________________
>> Dailydave mailing list
>> Dailydave at lists.immunitysec.com
>> http://lists.immunitysec.com/mailman/listinfo/dailydave
>>
>
>
>
> --
> Trancer
> Recognize-Security
> http://www.rec-sec.com
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20100204/ea8615be/attachment-0001.htm 

From alex at sotirov.net  Thu Feb  4 15:39:13 2010
From: alex at sotirov.net (Alexander Sotirov)
Date: Thu, 4 Feb 2010 15:39:13 -0500
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <1934474274.20100204200633@Zoller.lu>
References: <4B69A9D2.6060207@immunityinc.com>
	<212838605.20100204121427@Zoller.lu>
	<7E943919-F924-4AA0-A6D9-F3F07770687D@gmail.com>
	<1934474274.20100204200633@Zoller.lu>
Message-ID: <20100204203913.GA5515@MacBook-2.local>

On Thu, Feb 04, 2010 at 08:06:33PM +0100, Thierry Zoller wrote:
> >now, after reading the paper let me know if it requires a 'fix' as you
> >said, or a re-design/engineering and re-implementation of the JIT
> >itself. ;)
> Does not compute either. By "fix" I abviously assumed "redesign/eginner"
> the JIT. The point was that ASLR/DEP is not dead because of error in a
> JIT.

Are you making the claim that JIT spraying can be stopped by redesigning the
JIT? How exactly would you redesign the JIT to avoid inserting bytes controlled
by the attacker into the generated instruction stream?

Alex

From shadown at gmail.com  Thu Feb  4 15:58:42 2010
From: shadown at gmail.com (Sergio 'shadown' Alvarez)
Date: Thu, 4 Feb 2010 21:58:42 +0100
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <1934474274.20100204200633@Zoller.lu>
References: <4B69A9D2.6060207@immunityinc.com>
	<212838605.20100204121427@Zoller.lu>
	<7E943919-F924-4AA0-A6D9-F3F07770687D@gmail.com>
	<1934474274.20100204200633@Zoller.lu>
Message-ID: <82F84B83-2407-4044-B091-436508EE1397@gmail.com>

Thierry,

>> With all respect, you should read the paper before throwing your
>> unfounded thoughts about something you don't even know about.
> Why refer to respect when all you write afterwards is full of despise
> and   arrogance   ?   Your   capability   to   read   my mind is still
> lacking ;) , apparently you thought you know - What I read and
> what I know. Sorry to inform you that you are wrong on both.

Yeah, probably my capability to read your mind is lacking because I'm  
not a mind reader, as well on the other hand your capability to  
analyze exploitation techniques is lacking because you are not an  
exploit coder (beyond XSS and SQL-Injection I mean). Unless you've  
learnt something in the last year and a half, but first you should  
need to read ASM which you didn't know either, that's why I've guess  
on your interpretation about the technique...just saying.

BTW: I don't know anybody that surpass you when it comes to unfounded  
superb arrogance. If you wanna make it an open discussion, fine with me.

>> now, after reading the paper let me know if it requires a 'fix' as  
>> you
>> said, or a re-design/engineering and re-implementation of the JIT
>> itself. ;)
> Does not compute either. By "fix" I abviously assumed "redesign/ 
> eginner"
> the JIT. The point was that ASLR/DEP is not dead because of error in a
> JIT.

Now a 'fix' also means 'redesign/engineer' something, something that  
is not even a bug.
Sweet!, I can't wait to read in the changelog: 'We fixed that  
something we had there that wasn't a bug' instead of saying: 'we  
redesign the JIT compiler in order to provide a better defense in  
depth'.

I have a question for you though: how do you 'fix' something that is  
not a flaw or a bug?
We are talking about a design being used for something unexpected. (I  
lie, it was meant to be executable code :P)

Cheers,
   sergio

From pageexec at freemail.hu  Thu Feb  4 20:08:01 2010
From: pageexec at freemail.hu (pageexec at freemail.hu)
Date: Fri, 05 Feb 2010 03:08:01 +0200
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <82F84B83-2407-4044-B091-436508EE1397@gmail.com>
References: <4B69A9D2.6060207@immunityinc.com>,
	<1934474274.20100204200633@Zoller.lu>,
	<82F84B83-2407-4044-B091-436508EE1397@gmail.com>
Message-ID: <4B6B7D81.30727.129293A1@pageexec.freemail.hu>

On 4 Feb 2010 at 21:58, Sergio 'shadown' Alvarez wrote:

> Now a 'fix' also means 'redesign/engineer' something, something that  
> is not even a bug.

it is a bug to enter a generated insn stream at a non-insn boundary.
it's also fixable (SFI/CFI et al.).


From hfortier at recon.cx  Thu Feb  4 21:02:36 2010
From: hfortier at recon.cx (Hugo Fortier)
Date: Thu, 04 Feb 2010 21:02:36 -0500
Subject: [Dailydave] Recon Call for Papers - July 9-11 2010
Message-ID: <4B6B7C3C.4000809@recon.cx>

/*
Architecture: x86/Linux
Author: Recon
Published: 2010-02-04

The shell code walls the following message:
+                    +                     +         +
                               +                  +           +
        +                                             +
                                     \ /
                    +     _        - _+_ -                   ,__
      _=.    .:.         /=\       _|===|_                  ||::|
     |  |    _|.        |   |     | |   | |     __===_  -=- ||::|
     |==|   |  |  __    |.:.|   /\| |:. | |    |   | .|| : |||::|
     |  |-  |.:|_|. :__ |.: |--|==| |  .| |_   | ' |. ||.  |||:.|
   __|. | |_|. | |.|...||---|  |==| |   | | |_--.     ||   |||. |
  |  |  |   |. | | |::.||: .|  |==| | . : |=|===|    :|| . ||| .|
  |:.| .|   |  | | |:.:|| . |  |==| |     |=|===| .   |'   | |  |
  |     |      |   |   |'           :   .   |   ;     ;    '    |
  '     :      '   :   '            .       '  .      .         :
  '     .                   R E C O N     2 0 1 0     .
  '                .                .                           '
                        .           C F P

REC0N 2010
MONTREAL
JULY 9-11               
                        
+ RECON returns for 2010
                        
   - Training sessions + conference

+ We are accepting submissions

   - Single track
   - 45-60 minute presentations, or longer, we are flexible
   - There will be time for short, informal lightning talks

+ Especially on these topics

   - Reverse engineering (Software, Protocols, Hardware, Human)
   - Exploit development and vulnerability assessment
   - Data analysis and visualization techniques
   - Crypto and anonymity
   - Physical security countermeasures
   - Anything elite

+ Please include

   - Speaker name(s) and/or handle
   - Contact information (e-mail and cell phone)
   - Brief biography
   - Any presentation Supporting materials
   - Why it is cool and/or why you want to present it

+ You want to speak!

   - Please send the above information to
     cfp2010 (at) recon.cx by 15 May, 2010

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (Darwin)

mQENBEtqMN4BCADBIBOf6mK+H2QwfQYouyR5kkk5Imr3KmKzd/eGimX9srBeCauJ
vKb6K1ENxwSna58gwdW/UZ5oNauyDuin3JLYR0mDgxUo8s7cXwf0vltcR5LWDr49
cz3DC7rY2TPLDLO6PR6lNyFbtRE+UZ/OqwWrN9yNkyLfj+L2L4MDbscHsEA+Hlur
BG/4TM5FBvz0LG1v08RMDJN88PqZdg2lgjc2LS/gkcQKNS9D90BTPIJ3sWP7EVLd
RnmZ1204SXqCZyGufn02REDA0t/M7WMBDtHFFioMQc7NTaW/i2wajJWjXG8HKjw1
kl7VSjE1zZXPC8q+FBJ638dSX0nphUjZv0xhABEBAAG0HFJlY29uIENGUCA8Y2Zw
MjAxMEByZWNvbi5jeD6JAT4EEwECACgFAktqMN4CGwMFCQDtTgAGCwkIBwMCBhUI
AgkKCwQWAgMBAh4BAheAAAoJEISWGw7Okw71C7YH/0m203QqH5BtH6vaJQ56W+yO
I90xUoHOcLC6J9kqCc5wXMD3qZqyaDY/0aSFKyu0vxF7DSzO6PnuGWv//rJx6BkF
0rY6wdEA5iPTYcHG7Aht6LLAl96u98kUSIUNJX2l7+LvwJdJYgjxw4zFHOSjcH4d
m8OXm5oNpnfpsTUSTFXEeTOnP5Uz/dodWodhlVtT73YIUEr6BWNWRVJGFg9Cnoqy
M55EL4hQqhMYJDsRyUqnWAx3CJ0xqdA4dHft1CI06y7Z6FHR+J3GyqZPijJEx4Qn
Tr0w9w9CI/YX0QJPuosUHpwWulWBQRXVydC/5zfB+y0S2GUz2b+kfa+pbbaaEaG5
AQ0ES2ow3gEIALUKxeg0fhzirgklcXYBpaktpppvfzK+FGHITvdK7zC1jRsRPUIq
F1nLhYlEp7gBO2ROMXCIyQi+G3fjTrSWaJm1bJZUl9nwWLS0gr635zjgIL9X/isG
jn6JOTlzHXfzUucnfC5M+jmmJZCQCVS0n1jpCstlu/0RMcDl/H7UPPKke+foAll/
pTqcVJzZWgVvyFRI/0SXU/63ddHb2Dn0jKJ6WLo+V8UbYJSbYF3D1Z4xUUkHf6PY
xO0UOdiFnkfvHd938X6tQveLG+lRn8K/ZXtTLuztDm04XhvURujKpHvok0O5infQ
mRTMnHfl/0adHA0oNUiMNoIuWRJwRPj/ppcAEQEAAYkBJQQYAQIADwUCS2ow3gIb
DAUJAO1OAAAKCRCElhsOzpMO9YySB/9UVPbib6WZVDYdIY8vNWp9K17S/r/haPnk
95qgxuCHU62S4LlCIdNS/AblB3v/X42cIg3bvvWuIBjR9ayww+1KBAfPOVdMRDfq
+6DSBqxN1NvbItE1S90O8vPxgEQcUC+Z/gpF8MGH4T4xcPsVI2S7qLjfZdBiGzy0
CWU8iiYPE3JE94Rootin5yJbyHlek5/BUw+3tGkkWZDUV1Ww7FPdtQQJSnHbUqP3
3mF2Ss65vxatmeIvNL3FFLeSokABKeoPZd35nJP1Snw4w4lWA93sT/a+b2GYjLtb
rapk+7sYrit92kI3uA6qwoG9vM+PzJasKHT8jIyauk6RsVAba2MG
=TGKB
-----END PGP PUBLIC KEY BLOCK-----
*/

unsigned char buf[] =
"\xb9\xab\x03\x00\x00\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13"
"\xe7\x14\xc3\x41\x83\xeb\xfc\xe2\xf4\x8d\x1f\x9b\xd8\xb5\x72"
"\xab\x6c\x84\x9d\x24\x29\xc8\x67\xab\x41\x8f\x3b\xa1\x28\x89"
"\x9d\x20\x13\x0f\x92\xcd\x41\xe7\x71\xa0\x29\x88\x34\xe1\x6a"
"\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x61\xc7\x34\xe3\x61\xcc\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34"
"\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe8\x61\xc7"
"\x34\xe3\x61\xc7\x34\xe3\x61\xcc\x1e\xe3\x61\xc7\x34\xe3\x61"
"\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x3f\xe3\x61\xc7\x34"
"\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xcc"
"\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xcc\x1e\xe3\x61"
"\xc7\x34\xe3\x61\xc7\x34\xe8\x61\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34"
"\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7"
"\x34\xe3\x61\xc7\x34\xe3\x61\xcc\x1e\xe3\x61\xc7\x34\xe3\x61"
"\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34"
"\xe3\x1d\xc7\x3b\xc9\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7"
"\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x6a\xc7\x34\xe3\x61"
"\xc7\x4b\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xee\x61\xb8\x3f\x9c"
"\x61\xca\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34"
"\xe3\x61\xc7\x34\xe3\x61\xcb\x4b\x9c\x4b\xc7\x34\xe3\x61\xc7"
"\x34\x9c\x7c\xc9\x34\xe3\x61\xc7\x3a\xf9\x6f\xc7\x34\xe3\x61"
"\xc7\x34\xe3\x61\xc7\x3b\xfe\x1d\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x1e\x9b\x29\xfe\x7c\x9b\x4b\xe3\x61\xc7\x34\xe3\x61\xc7\x34"
"\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\x9b\x68\xf9\x7b\x9b"
"\x1e\xe3\x61\xc7\x34\xe3\x3d\xc7\x34\xbf\x61\xc7\x34\xe3\x1e"
"\x9b\x3a\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xbf\x61\xc7\x34\xbf"
"\x61\xc7\x34\xe3\x61\x9b\x34\xbf\x61\xc7\x34\xbf\x61\x9b\x34"
"\xe3\x61\xc7\x34\x9c\x1e\xda\x29\xfe\x1e\xc7\x34\xee\x7c\xca"
"\x34\xbf\x3d\xdd\x2e\xbf\x4b\xc7\x34\xe3\x61\xc7\x68\xfe\x7c"
"\x9b\x34\xe3\x61\x9b\x34\xe3\x3d\xc7\x34\x9c\x1e\xc7\x34\xe3"
"\x61\x9b\x3a\xf9\x6f\x9b\x34\xe3\x61\xc8\x48\xbf\x61\x9b\x2e"
"\xed\x61\x9b\x34\xbf\x61\xc7\x34\xe3\x3d\xc7\x34\xe3\x3d\xc7"
"\x3a\xbf\x3d\xc7\x2e\xe3\x3d\x9b\x68\xf9\x7b\x9b\x1e\xe3\x61"
"\xc7\x34\xe3\x3d\xc7\x34\xbf\x6c\xc7\x34\xbf\x6f\xdd\x68\x9c"
"\x3d\xc9\x34\xf9\x1e\xb8\x34\xbf\x6f\xdd\x34\xbf\x6c\xca\x68"
"\xfe\x7c\x9b\x34\xbf\x61\xc7\x3a\xbf\x61\x9b\x4b\xe3\x61\xc7"
"\x68\xe3\x66\xc7\x68\xed\x61\x9b\x68\xed\x61\xc7\x68\xbf\x3d"
"\xdd\x3a\xbf\x4b\xc7\x34\xe3\x1e\xb8\x68\xed\x61\x9b\x34\xbf"
"\x1e\x9b\x3a\xe3\x3d\xc7\x68\xed\x3d\xc9\x3a\xed\x3d\x9b\x39"
"\xee\x6c\x9b\x34\xe3\x3d\xda\x29\xbf\x61\x9b\x34\xe3\x61\x9b"
"\x34\xbf\x61\x9b\x4b\xee\x6c\xc9\x34\xe3\x61\xc7\x34\xbf\x3d"
"\xc7\x34\xe3\x3d\x9b\x68\xed\x61\x9b\x1e\xe3\x61\x9b\x34\xe3"
"\x3d\xc7\x34\xbf\x61\xc7\x34\xbf\x6f\xc7\x68\xe3\x3d\xc7\x68"
"\xf9\x7b\xc9\x68\xbf\x7b\xc7\x3a\xbf\x61\xc7\x68\xfe\x7c\x9b"
"\x34\xbf\x61\xc9\x34\xf9\x61\x9b\x29\xbf\x7c\xda\x29\xbf\x61"
"\xc7\x34\xe3\x7b\x9b\x68\xe3\x6f\xc7\x68\xbf\x3d\xc7\x3a\xbf"
"\x4b\xc7\x34\xbf\x7b\xc9\x68\xe3\x6f\x9b\x34\xe3\x61\x9b\x34"
"\xe3\x3d\xc7\x68\xe3\x3d\xdd\x3a\xf9\x3d\x9b\x34\xed\x61\x9b"
"\x34\xe3\x3d\xda\x29\xbf\x61\x9b\x34\xe3\x61\xc7\x34\xbf\x7c"
"\x9b\x29\xfe\x7c\x9b\x34\xed\x61\xc7\x34\xbf\x66\xc7\x34\xe3"
"\x3d\xc7\x68\xe3\x61\x9b\x1e\xe3\x61\x9b\x34\xe3\x61\xc7\x34"
"\xbf\x61\xc7\x34\xe3\x61\xc7\x68\xe3\x61\xc7\x68\xe3\x61\xc7"
"\x68\xe4\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xf9\x61"
"\xc7\x34\xed\x61\xc7\x34\xbf\x61\xc7\x34\xf8\x61\xc7\x34\xe3"
"\x61\xdc\x34\xe3\x61\xc7\x33\xe3\x61\xc7\x34\xbf\x4b\xc7\x34"
"\xe4\x61\xc7\x34\xe3\x61\xdd\x34\xe3\x61\xc7\x34\xe3\x66\xc7"
"\x34\xe3\x7b\xc7\x34\xe3\x66\xc7\x34\xe3\x61\xc7\x34\xe3\x61"
"\xc7\x34\xe3\x61\xc9\x34\xe3\x61\xc7\x34\xe3\x61\xc0\x34\xe3"
"\x6f\xc7\x34\xe3\x61\xc7\x34\xed\x61\xc7\x34\xe3\x61\xc7\x34"
"\xe3\x61\xdd\x1e\xe3\x61\xc0\x34\xe3\x61\xc7\x34\xed\x61\xc7"
"\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61"
"\xc7\x34\x91\x61\xa2\x34\x80\x61\xa8\x34\x8d\x61\xc7\x34\xe3"
"\x61\xd5\x34\xf3\x61\xd6\x34\xf3\x61\xc7\x34\xe3\x61\xc9\x1e"
"\xe3\x61\xc0\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7"
"\x34\xe3\x61\xc7\x3a\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61"
"\xc7\x34\xe3\x61\xc7\x34\xed\x61\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34"
"\xe3\x61\xc7\x34\xe4\x4b\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7"
"\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61"
"\xc9\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xa4\x34\x85"
"\x61\xb7\x1e\xc9\x13\xa2\x57\xf3\x0f\xc7\x26\xf3\x70\xd7\x1e"
"\x8e\x0e\xa9\x40\x91\x04\xa6\x58\xc9\x0b\xb2\x58\x9a\x61\xde"
"\x39\xf2\x70\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61"
"\xc7\x34\xe3\x4b\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xed\x3f"
"\xe3\x13\xa2\x57\x8c\x0f\xc7\x66\xa6\x35\x92\x66\xad\x32\xc7"
"\x72\xac\x33\xc7\x26\xf3\x70\xd7\x1e\xe3\x61\xc7\x34\xe3\x61"
"\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3\x61\xc7\x34\xe3"
"\x61\xc7\x34\xc9\x61\xc7\x34\xee\x61\xb3\x66\xa2\x28\x89\x7d"
"\xad\x26\xc7\x67\xa6\x32\x94\x7d\xac\x2f\x94\x34\xe8\x61\x84"
"\x7b\xad\x27\x82\x66\xa6\x2f\x84\x71\xc9\x4b\xcc\x34\x94\x24"
"\xc7\x75\xb1\x24\xc7\x75\xa0\x22\x82\x64\xb7\x28\x89\x73\xe3"
"\x32\x92\x76\xae\x28\x94\x67\xaa\x2e\x89\x67\xc9\x4b\xc7\x34"
"\xe3\x6c\xc7\x47\xaa\x2f\x80\x78\xa6\x61\x93\x66\xa2\x22\x8c"
"\x1e\xe3\x61\xc7\x39\xe3\x75\xd2\x39\xf5\x71\xc7\x79\xaa\x2f"
"\x92\x60\xa6\x61\x97\x66\xa6\x32\x82\x7a\xb7\x20\x93\x7d\xac"
"\x2f\x94\x38\xe3\x2e\x95\x34\xaf\x2e\x89\x73\xa6\x33\xcb\x34"
"\xb4\x24\xc7\x75\xb1\x24\xc7\x72\xaf\x24\x9f\x7d\xa1\x2d\x82"
"\x1e\xe3\x61\xc7\x39\xe3\x15\x8f\x71\xb1\x24\xc7\x63\xaa\x2d"
"\x8b\x34\xa1\x24\xc7\x60\xaa\x2c\x82\x34\xa5\x2e\x95\x34\xb0"
"\x29\x88\x66\xb7\x6d\xc7\x7d\xad\x27\x88\x66\xae\x20\x8b\x34"
"\xaf\x28\x80\x7c\xb7\x2f\x8e\x7a\xa4\x61\x93\x75\xaf\x2a\x94"
"\x1e\xc9\x6a\xc7\x51\xb0\x31\x82\x77\xaa\x20\x8b\x78\xba\x61"
"\x88\x7a\xe3\x35\x8f\x71\xb0\x24\xc7\x60\xac\x31\x8e\x77\xb0"
"\x4b\xed\x34\xe3\x61\xca\x34\x91\x24\x91\x71\xb1\x32\x82\x34"
"\xa6\x2f\x80\x7d\xad\x24\x82\x66\xaa\x2f\x80\x34\xeb\x12\x88"
"\x72\xb7\x36\x86\x66\xa6\x6d\xc7\x44\xb1\x2e\x93\x7b\xa0\x2e"
"\x8b\x67\xef\x61\xaf\x75\xb1\x25\x90\x75\xb1\x24\xcb\x34\x8b"
"\x34\x8a\x75\xad\x68\xed\x34\xe3\x61\xca\x34\x86\x39\x97\x78"
"\xac\x28\x93\x34\xa7\x24\x91\x71\xaf\x2e\x97\x79\xa6\x2f\x93"
"\x34\xa2\x2f\x83\x34\xb5\x34\x8b\x7a\xa6\x33\x86\x76\xaa\x2d"
"\x8e\x60\xba\x61\x86\x67\xb0\x24\x94\x67\xae\x24\x89\x60\xc9"
"\x61\xc7\x34\xee\x61\xa3\x75\xb7\x20\xc7\x75\xad\x20\x8b\x6d"
"\xb0\x28\x94\x34\xa2\x2f\x83\x34\xb5\x28\x94\x61\xa2\x2d\x8e"
"\x6e\xa2\x35\x8e\x7b\xad\x61\x93\x71\xa0\x29\x89\x7d\xb2\x34"
"\x82\x67\xc9\x61\xc7\x34\xee\x61\xa4\x66\xba\x31\x93\x7b\xe3"
"\x20\x89\x70\xe3\x20\x89\x7b\xad\x38\x8a\x7d\xb7\x38\xed\x34"
"\xe3\x61\xca\x34\x93\x29\x9e\x67\xaa\x22\x86\x78\xe3\x32\x82"
"\x77\xb6\x33\x8e\x60\xba\x61\x84\x7b\xb6\x2f\x93\x71\xb1\x2c"
"\x82\x75\xb0\x34\x95\x71\xb0\x4b\xc7\x34\xe3\x6c\xc7\x55\xad"
"\x38\x93\x7c\xaa\x2f\x80\x34\xa6\x2d\x8e\x60\xa6\x4b\xed\x3f"
"\xe3\x11\x8b\x71\xa2\x32\x82\x34\xaa\x2f\x84\x78\xb6\x25\x82"
"\x1e\xc9\x61\xc7\x34\xee\x61\xb4\x64\xa6\x20\x8c\x71\xb1\x61"
"\x89\x75\xae\x24\xcf\x67\xea\x61\x86\x7a\xa7\x6e\x88\x66\xe3"
"\x29\x86\x7a\xa7\x2d\x82\x1e\xe3\x61\xc7\x39\xe3\x02\x88\x7a"
"\xb7\x20\x84\x60\xe3\x28\x89\x72\xac\x33\x8a\x75\xb7\x28\x88"
"\x7a\xe3\x69\x82\x39\xae\x20\x8e\x78\xe3\x20\x89\x70\xe3\x22"
"\x82\x78\xaf\x61\x97\x7c\xac\x2f\x82\x3d\xc9\x61\xc7\x34\xee"
"\x61\xa5\x66\xaa\x24\x81\x34\xa1\x28\x88\x73\xb1\x20\x97\x7c"
"\xba\x4b\xc7\x34\xe3\x6c\xc7\x55\xad\x38\xc7\x64\xb1\x24\x94"
"\x71\xad\x35\x86\x60\xaa\x2e\x89\x34\x90\x34\x97\x64\xac\x33"
"\x93\x7d\xad\x26\xc7\x79\xa2\x35\x82\x66\xaa\x20\x8b\x67\xc9"
"\x61\xc7\x34\xee\x61\xb0\x7c\xba\x61\x8e\x60\xe3\x28\x94\x34"
"\xa0\x2e\x88\x78\xe3\x20\x89\x70\xec\x2e\x95\x34\xb4\x29\x9e"
"\x34\xba\x2e\x92\x34\xb4\x20\x89\x60\xe3\x35\x88\x34\xb3\x33"
"\x82\x67\xa6\x2f\x93\x34\xaa\x35\xc7\x1e\xc9\x6a\xc7\x4d\xac"
"\x34\xc7\x63\xa2\x2f\x93\x34\xb7\x2e\xc7\x67\xb3\x24\x86\x7f"
"\xe2\x4b\xed\x34\xe3\x61\xca\x34\x93\x2d\x82\x75\xb0\x24\xc7"
"\x67\xa6\x2f\x83\x34\xb7\x29\x82\x34\xa2\x23\x88\x62\xa6\x61"
"\x8e\x7a\xa5\x2e\x95\x79\xa2\x35\x8e\x7b\xad\x61\x93\x7b\xe3"
"\x4b\xc7\x34\xe3\x61\xc7\x77\xa5\x31\xd5\x24\xf2\x71\xc7\x3c"
"\xa2\x35\xce\x34\xb1\x24\x84\x7b\xad\x6f\x84\x6c\xe3\x23\x9e"
"\x34\xf2\x74\xc7\x59\xa2\x38\xcb\x34\xf1\x71\xd6\x24\xc9\x4b"
"\xca\x39\xee\x6c\xca\x56\x86\x06\xae\x5a\xe3\x11\xa0\x44\xe3"
"\x11\xb2\x56\x8f\x08\xa4\x34\x88\x04\xbe\x34\x81\x0d\xa8\x57"
"\x88\x6c\xca\x39\xee\x6c\xed\x42\xa6\x33\x94\x7d\xac\x2f\xdd"
"\x34\x84\x2f\x92\x44\x84\x61\x91\x25\xed\x75\xc9\x25\xf3\x61"
"\xcf\x50\xa2\x33\x90\x7d\xad\x68\xed\x1e\xae\x10\xa2\x5a\x81"
"\x04\x93\x65\x8e\x0f\xd3\x56\x80\x00\xa3\x56\x8a\x03\xa8\x72"
"\xf5\x2c\xac\x3f\x8b\x73\xb6\x63\xa5\x10\xbe\x7b\xb6\x38\xb5"
"\x21\xa8\x2a\x8c\x21\x8a\x2c\x95\x27\x88\x2c\xac\x6e\xa7\x6e"
"\x82\x53\xaa\x2c\xbf\x2d\xb0\x33\xa5\x71\x80\x20\x92\x5e\xc9"
"\x37\xac\x76\xf5\x0a\xd6\x51\x8d\x39\x90\x47\xad\x20\xd2\x2c"
"\xa4\x36\x83\x43\xec\x14\xbd\x21\xac\x0f\x86\x61\xba\x05\x92"
"\x7d\xad\x72\xad\x58\x9a\x13\xd7\x79\x87\x26\x9f\x41\xac\x79"
"\x94\x23\xa0\x19\x90\x72\xf3\x37\x8b\x60\xa0\x13\xd2\x58\x94"
"\x05\x95\x20\xfa\x4b\x84\x6e\xf0\x05\xa4\x23\xb1\x18\xd5\x40"
"\x93\x0d\xa3\x58\x8c\x77\xb7\x46\xf5\x2d\xa9\x6d\x85\x23\x93"
"\x46\x86\x6a\xb2\x4e\xec\x0e\x96\x63\x94\x33\xa9\x2d\xba\x0f"
"\x8c\x6d\x8f\x27\x8d\x3f\x8f\x73\xab\x20\x8e\x05\x85\x67\xa0"
"\x09\x94\x51\x82\x6a\xaf\x78\xb6\x33\xed\x56\x84\x6e\xd3\x40"
"\x8e\x74\xa1\x56\xb5\x3b\xd7\x58\x84\x70\x91\x24\xfb\x13\xaa"
"\x50\x89\x0f\xdf\x2c\x93\x30\xbd\x70\xa4\x73\x8b\x73\xa9\x22"
"\xd5\x58\x90\x6e\x80\x7f\xa0\x10\xac\x5a\x90\x78\xa3\x2d\xf3"
"\x03\xb3\x44\x8a\x0b\xd4\x67\x94\x11\xd0\x51\x95\x0d\x83\x1e"
"\x91\x2f\x8a\x4e\xf2\x73\xd7\x20\x90\x19\x96\x57\x99\x38\xa0"
"\x61\xa5\x2f\xd7\x26\x91\x04\xa3\x55\xf3\x35\xc8\x59\xf4\x16"
"\xaa\x56\x87\x35\xaf\x52\x85\x28\x88\x59\x92\x22\xd0\x5a\x97"
"\x20\xb0\x3b\xaa\x73\x90\x75\xa9\x0b\xb0\x7e\x9b\x06\xdf\x5c"
"\x88\x2b\x90\x25\xc9\x2a\x8b\x23\x95\x12\x8d\x51\xf2\x3b\xbd"
"\x4c\x93\x02\xdf\x65\xe8\x07\xa5\x5e\xf5\x72\xdf\x70\x90\x19"
"\xd7\x7a\xb3\x29\xb2\x7e\x99\x37\xd7\x6c\xab\x00\xa5\x51\x81"
"\x00\xa6\x53\xf3\x09\xa1\x5e\xaf\x18\xd5\x2d\xb6\x08\xa2\x5a"
"\x84\x14\xa4\x55\xfb\x18\xd5\x4e\xb4\x4b\xaa\x7e\x82\x39\xaa"
"\x51\x81\x38\xbd\x43\x8d\x37\x85\x7d\xf6\x2b\x82\x50\xf5\x0b"
"\xa6\x40\xf7\x04\xa2\x63\x86\x02\xa6\x57\xa4\x07\xa6\x7f\xb7"
"\x30\xaa\x5a\xf7\x02\xa0\x63\x8e\x07\xa4\x45\x87\x35\xb3\x73"
"\x82\x06\xa4\x63\xa8\x08\xa5\x63\x8e\x02\xa5\x7c\x96\x08\xed"
"\x55\xa4\x2a\xac\x57\xb4\x10\xb0\x55\xa4\x0c\xa5\x55\xab\x75"
"\xa5\x55\xab\x24\xa6\x55\x82\x2e\xad\x51\x8a\x12\xb0\x53\xb4"
"\x76\xa8\x7f\xb4\x76\xd6\x57\xf4\x18\xaf\x3b\xf3\x2c\xd5\x24"
"\xf0\x10\x96\x5c\xf6\x03\x93\x5c\xf5\x37\x86\x5e\x92\x74\xd1"
"\x43\xe8\x38\xa8\x1e\x8a\x78\xd7\x6c\x96\x2e\xaf\x5b\xa0\x0d"
"\xa4\x22\x89\x78\x8c\x65\x80\x22\xd2\x63\x9b\x0c\xa3\x27\xb2"
"\x1b\x96\x6d\xa2\x05\xbe\x3b\xf3\x20\xb4\x52\x88\x38\x92\x24"
"\xb5\x39\xa1\x23\x87\x12\x9d\x5b\xf5\x11\x89\x61\x84\x16\x91"
"\x3b\xec\x33\xad\x6c\xf5\x03\x8c\x52\xc9\x71\x95\x4d\xf5\x36"
"\x83\x51\x82\x74\x8e\x44\x97\x18\x84\x5c\x84\x76\xa6\x7c\xb7"
"\x77\xab\x58\x82\x2d\xde\x22\xb6\x78\xdf\x7f\x96\x12\xae\x41"
"\x8d\x0b\xbf\x26\xaf\x76\xcc\x58\xb5\x36\xad\x70\x89\x18\x80"
"\x7e\xbb\x36\xd3\x6e\x85\x09\xa8\x47\xa9\x22\xaf\x20\xa7\x4b"
"\x8a\x2c\x8c\x19\x8a\x21\xac\x0f\x97\x7a\xa5\x31\x94\x40\x96"
"\x12\xb3\x52\x9b\x04\x82\x40\x8c\x2f\xb7\x21\x96\x3b\xc8\x70"
"\xac\x25\xb0\x7b\xa7\x29\x8b\x42\xb7\x15\xd0\x27\x9a\x08\xb2"
"\x51\xb1\x77\xa5\x43\x8d\x16\xb5\x42\x89\x06\xa1\x73\xfa\x02"
"\x89\x7b\xb2\x38\xed\x59\xf6\x74\xa2\x58\xf7\x29\xb6\x65\xab"
"\x0c\xbe\x5e\x87\x32\xb5\x6d\x96\x30\x89\x43\x82\x39\xd4\x57"
"\x89\x71\x9f\x65\xa7\x00\xd3\x70\x8b\x27\x93\x25\x80\x08\xd7"
"\x22\xba\x76\xbd\x22\x85\x09\xb5\x3f\x89\x72\xa0\x6d\xb2\x1b"
"\xb7\x7d\xa9\x0b\xa2\x6c\xf7\x10\x89\x1e\x97\x33\xd7\x63\xfa"
"\x36\xde\x57\x8a\x6e\xbe\x4c\xf3\x10\xad\x44\xb6\x2e\x94\x41"
"\x8b\x31\x90\x43\xb6\x2d\xb0\x56\x92\x13\xbf\x42\xba\x25\xa4"
"\x3b\xf6\x3b\x81\x56\xe8\x38\xd7\x47\xf1\x06\xb2\x6e\xf1\x23"
"\xcc\x7f\xa5\x20\xcc\x64\xa1\x23\x86\x75\x86\x20\xa0\x21\xc9"
"\x00\xb6\x24\x86\x12\xd5\x7b\xb4\x72\x80\x51\x8a\x00\xab\x41"
"\x88\x39\x82\x73\xf3\x27\x8f\x6e\xaa\x33\x80\x7f\xaf\x22\xbf"
"\x4d\x81\x31\x86\x7f\xb7\x31\x97\x64\xb5\x27\x9d\x5f\xe8\x07"
"\xa0\x5c\x8a\x15\x91\x70\x88\x76\x9d\x57\xf2\x2b\xb5\x67\x91"
"\x11\xb2\x5d\xb2\x4b\xa1\x25\xad\x0d\x8f\x4d\xaf\x04\x97\x23"
"\xa4\x03\xa8\x26\x91\x0e\xaa\x4c\x80\x08\x9e\x45\xaa\x6a\xa0"
"\x27\xa5\x2b\xb3\x66\x90\x16\x86\x5e\xae\x70\x85\x5e\x99\x14"
"\x8b\x2d\xad\x36\xb0\x58\x90\x71\x80\x66\xf5\x72\xd2\x6e\xa9"
"\x26\xae\x58\xfa\x19\xc8\x7d\xb0\x06\xed\x7e\xad\x77\xad\x5b"
"\x97\x2d\x9d\x5c\x9b\x27\x9d\x41\xb6\x22\x89\x72\x80\x74\xaa"
"\x3f\xa9\x2c\x8a\x5e\x99\x02\xb6\x57\x95\x12\xd7\x7a\xf2\x2b"
"\x97\x57\xb0\x35\x8b\x61\xec\x71\xb5\x59\xa0\x05\x8b\x3b\x8b"
"\x76\xb2\x44\x93\x0a\x8c\x71\xe8\x27\x88\x55\xaf\x2d\xc8\x1e"
"\xb3\x15\x96\x77\x95\x0b\x9d\x4e\x94\x26\xb1\x62\xba\x07\xb5"
"\x5d\xec\x71\xb4\x4c\x96\x6e\xd1\x27\xa7\x25\xaf\x76\xf1\x05"
"\x89\x24\xa9\x0a\xad\x22\x94\x0d\x88\x3f\x95\x79\xb2\x76\x9a"
"\x0b\xb4\x76\x9a\x07\xd4\x50\xf2\x1b\xd3\x6c\x96\x14\x8c\x5c"
"\xa5\x77\xb7\x4d\xc9\x39\xa8\x24\x96\x0e\x83\x7d\x85\x2f\x8c"
"\x72\xb5\x09\x83\x2d\xf0\x79\xbf\x22\xb7\x10\x91\x71\x8f\x06"
"\xcc\x78\x91\x2f\xdf\x5f\xec\x1b\xbf\x60\x97\x0d\x92\x6e\xb7"
"\x05\x8a\x24\xf7\x19\x8f\x62\x96\x13\x92\x7e\x88\x31\xaf\x62"
"\xac\x2a\xd7\x5b\xf6\x28\x89\x72\x92\x4b\x8a\x46\x97\x0c\x89"
"\x5c\xa5\x2d\xc8\x24\xa2\x25\xaf\x55\xf3\x2e\xa9\x41\xaa\x0c"
"\xa9\x7b\x8a\x34\xb0\x46\x89\x36\xb5\x44\xa9\x6e\x97\x64\xa0"
"\x00\xa2\x45\x86\x00\xa6\x4d\xa8\x03\xad\x45\x92\x18\xa6\x45"
"\x8a\x00\xa3\x63\x96\x02\xb4\x26\xac\x36\xd4\x73\x8a\x23\xed"
"\x50\x82\x14\xad\x55\x8c\x70\xa8\x55\x82\x00\xac\x57\x91\x02"
"\xa2\x78\xab\x32\xa8\x6e\xb3\x0c\xa8\x2d\x9a\x38\xb4\x56\xec"
"\x78\xb2\x42\x93\x23\x8e\x76\xf5\x16\xbd\x42\x87\x18\x83\x5d"
"\x9a\x79\x91\x5a\x94\x31\xde\x5f\xf2\x76\xb4\x3b\xb1\x6e\x8f"
"\x75\x93\x2f\x8c\x1e\xfa\x74\x96\x73\xbb\x34\xa4\x5c\x96\x77"
"\xd5\x47\xf7\x0d\x8b\x57\x8a\x25\xa9\x47\xec\x00\x85\x78\x81"
"\x72\x91\x3b\x9b\x75\xd5\x77\x8a\x26\xd4\x76\xb5\x37\xb0\x61"
"\x8a\x03\x8d\x46\xfa\x20\x9e\x63\xb4\x6a\xd6\x5f\x81\x00\x81"
"\x44\x8c\x17\x83\x59\x91\x05\x81\x65\xc9\x6a\xd1\x50\x90\x03"
"\x96\x6c\x8d\x70\xa9\x62\xa1\x08\x93\x51\xf2\x12\xde\x24\x8c"
"\x79\x91\x44\xbb\x26\xa2\x45\xa0\x14\xa4\x3f\x99\x6e\x80\x64"
"\x85\x79\xaa\x53\x8b\x75\xb3\x20\xbb\x22\xb7\x67\x95\x08\xd5"
"\x47\xf4\x30\xab\x7e\xa5\x1b\x83\x56\xaa\x06\x9d\x6d\xf3\x4b"
"\xa4\x43\x96\x79\x8e\x7d\x9a\x11\xa2\x27\x89\x04\xde\x20\x91"
"\x2e\x88\x60\xaa\x2f\xd2\x6d\x89\x23\x9e\x5c\xaf\x24\x8c\x21"
"\xec\x03\xb2\x63\xe8\x72\x93\x53\xa8\x2a\xb0\x4e\x87\x14\xb1"
"\x25\x94\x36\xd0\x52\x93\x25\x93\x45\x92\x0b\xb4\x7a\x8b\x23"
"\xb2\x65\x93\x72\xed\x27\xae\x07\xd5\x47\xb0\x77\xd2\x62\xbb"
"\x20\x93\x79\xa6\x08\x91\x5a\x8f\x72\xa1\x52\x8f\x24\xb4\x7b"
"\xa8\x00\xa5\x5f\xa6\x2e\xb7\x4e\xa7\x72\xd2\x7a\x89\x11\xd6"
"\x47\xad\x36\xd3\x63\xf7\x2d\xb0\x55\xfa\x72\x94\x40\xec\x20"
"\xcc\x76\xf1\x06\xbe\x7e\x8f\x35\x85\x1e\xb1\x20\x97\x7f\xe8"
"\x76\x94\x4d\xb1\x28\x93\x2d\xf1\x2a\xae\x27\xb6\x00\xd1\x65"
"\xb4\x2e\xa0\x2d\xb5\x0c\xcc\x44\xb9\x0b\x86\x67\x88\x09\xb3"
"\x2c\xa9\x08\x9e\x75\xb6\x2a\xd1\x46\xb0\x17\xa6\x76\xa2\x73"
"\xaa\x53\xc9\x7c\xb3\x53\x88\x03\xed\x39\xee\x6c\xca\x39\x86"
"\x0f\xa3\x34\x93\x06\xb7\x34\x93\x14\xa5\x58\x8a\x02\xc7\x5f"
"\x86\x18\xc7\x56\x8f\x0e\xa4\x5f\xee\x6c\xca\x39\xee\x63\x9b"
"\x63\xa2\x2d\x8b\x1e\xc3\x16\xb4\x9d\x22\x8c\x67\x1e\xc3\x41";

void main(){
      int (*shell)();
      shell=buf;
      shell();
}




From nate at root.org  Fri Feb  5 00:51:39 2010
From: nate at root.org (Nate Lawson)
Date: Thu, 04 Feb 2010 21:51:39 -0800
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <20100204203913.GA5515@MacBook-2.local>
References: <4B69A9D2.6060207@immunityinc.com>	<212838605.20100204121427@Zoller.lu>	<7E943919-F924-4AA0-A6D9-F3F07770687D@gmail.com>	<1934474274.20100204200633@Zoller.lu>
	<20100204203913.GA5515@MacBook-2.local>
Message-ID: <4B6BB1EB.3000101@root.org>

Alexander Sotirov wrote:
> On Thu, Feb 04, 2010 at 08:06:33PM +0100, Thierry Zoller wrote:
>>> now, after reading the paper let me know if it requires a 'fix' as you
>>> said, or a re-design/engineering and re-implementation of the JIT
>>> itself. ;)
>> Does not compute either. By "fix" I abviously assumed "redesign/eginner"
>> the JIT. The point was that ASLR/DEP is not dead because of error in a
>> JIT.
> 
> Are you making the claim that JIT spraying can be stopped by redesigning the
> JIT? How exactly would you redesign the JIT to avoid inserting bytes controlled
> by the attacker into the generated instruction stream?

This is one reason why I expect the techniques of software protection to
become more widespread in general-purpose systems. Things like
obfuscation, heap randomization, integrity self-checks, linker module
encryption, etc. were once the domain of copy protection systems or the
like.

But if your JIT compiler starts generating randomized, obfuscated native
code with embedded self-checks, now it starts getting harder to use the
output in a predictable way. I see this as a natural extension of the
process that started with ASLR.

-- 
Nate


From berendjanwever at gmail.com  Fri Feb  5 05:08:43 2010
From: berendjanwever at gmail.com (Berend-Jan Wever)
Date: Fri, 5 Feb 2010 11:08:43 +0100
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <4B6B7D81.30727.129293A1@pageexec.freemail.hu>
References: <4B69A9D2.6060207@immunityinc.com>
	<1934474274.20100204200633@Zoller.lu> 
	<82F84B83-2407-4044-B091-436508EE1397@gmail.com>
	<4B6B7D81.30727.129293A1@pageexec.freemail.hu>
Message-ID: <3fa2f5bb1002050208x7cf5ce31se6d1b9d4035386f6@mail.gmail.com>

The way I see it DEP+ASLR tries to take the executability of controllable
bytes (DEP) and the predictability of the locations of bytes (ASLR) away
from an attacker.

I have not seen the talk or any technical information about the attack under
discussion, but I am guessing that this JIT attack generates a large number
of functions with specific content, which cause the JIT compiler to generate
a large number of executable bytes with predictable content. That means you
break DEP by generating controllable bytes that are executable and ASLR
because you can create so many copies that you can predict a location where
one of them will be.

V8 <http://code.google.com/p/v8/> has some mitigations to prevent too much
control over the bytes it generates; 32-bit hard-coded integers are split
into two 16 bit values, to prevent an attacker from having control over too
many sequential bytes. This is an attempt to prevent an attacker from
generating a sequence of useful instructions. Though I do not doubt that it
is still possible to generate code that does arbitrary things, it becomes a
lot harder.

It is possible to take control and information away from the attacker even
further by generating code in different ways each time where possible (
http://lists.immunitysec.com/pipermail/dailydave/2007-July/004471.html),
inserting random NOPs, cutting code into chunks that are connected by JMPs
and reordering these chunks as well as inserting random (unused) chunks of
bytes in between the normal code, etc.., etc...

There is of course a trade-off with speed and code size. You want to make
your compiler random enough for an attacker to have less than a 1/256 chance
of successfully executing arbitrary code. I'm guessing that making it random
enough to not allow better chances of success than ASLR is prohibitively
expensive in speed and size, especially now that speed is becoming more and
more important for browsers. You can probably decrease the chance of success
significantly below 1 though.

Cheers,
SkyLined
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20100205/18df5892/attachment.htm 

From larry at larryseltzer.com  Fri Feb  5 09:44:25 2010
From: larry at larryseltzer.com (Larry Seltzer)
Date: Fri, 5 Feb 2010 09:44:25 -0500
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <4B6BB1EB.3000101@root.org>
References: <4B69A9D2.6060207@immunityinc.com>	<212838605.20100204121427@Zoller.lu>	<7E943919-F924-4AA0-A6D9-F3F07770687D@gmail.com>	<1934474274.20100204200633@Zoller.lu><20100204203913.GA5515@MacBook-2.local>
	<4B6BB1EB.3000101@root.org>
Message-ID: <9B9E7EA67E1B1342B2D25F3FD1B32930033656C1@BE35.exg3.exghost.com>

First, it looks like insulting others is common, if not mandatory
practice on this list. Sorry if I don't do a good enough job, I'm new
here.

My first impression on seeing this (I'm still reading Dion's paper) was
that perhaps some sort of validator or IPS-like functionality in the
JIT, analyzing the input, could be effective, looking for malformations
and suspicious behavior. It couldn't be perfect and there would be a
performance hit.

My other thought was whether Java is just as vulnerable. I assume almost
all JVMs do JITing. Of course Java byte code is understood to be code
while Flash files are treated as "content". So it wouldn't be so easy,
for example, to send malicious Java to a locked Symbian cell phone
because it would have to be signed and users are generally more cautious
about code than "content".

Larry Seltzer
Contributing Editor, PC Magazine
larry_seltzer at ziffdavis.com 
http://blogs.pcmag.com/securitywatch/


From dave at immunityinc.com  Fri Feb  5 13:56:14 2010
From: dave at immunityinc.com (dave)
Date: Fri, 05 Feb 2010 13:56:14 -0500
Subject: [Dailydave] Kernel bugs!
Message-ID: <4B6C69CE.80509@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So I remember when one of the major kernel remote in Windows came out,
and Nico was down in Argentina at Ekoparty with cards that had a praying
mantis on them and read "Our other bug is a kernel remote". MS asked him
if he'd known about it before hand, and the answer, of course, was no,
he just was lucky to have neat cards ready.

Nonetheless, Kernel exploitation is a skill that is not going to get old
any time soon. In light of that, we've developed a new Kernel overflows
class (
https://www.immunityinc.com/education-kerneloverflowsandshellcodewriting.shtml
) and it's first implementation is going to be held in Akihabara,
Tokyo.  It's a 4 day class which is being held on Tuesday March 2 -
Friday March 5, 2010 and it's being taught by Kostya and Ron.

For pricing or registration information, please send an e-mail to
sales at cyberdefense.jp. I'm headed downstairs to go see if I can solve
the exercises.

- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAktsac4ACgkQtehAhL0ghernBwCffP9YGM+zRuarWww27hi4lKOd
AbYAnjIx4n3VYnCDJkuwHxnYAoZm+d7E
=x9O4
-----END PGP SIGNATURE-----

From lcamtuf at coredump.cx  Fri Feb  5 13:54:40 2010
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Fri, 5 Feb 2010 10:54:40 -0800
Subject: [Dailydave] ASLR+DEP = no problem. :>
In-Reply-To: <9B9E7EA67E1B1342B2D25F3FD1B32930033656C1@BE35.exg3.exghost.com>
References: <4B69A9D2.6060207@immunityinc.com>
	<212838605.20100204121427@Zoller.lu>
	<7E943919-F924-4AA0-A6D9-F3F07770687D@gmail.com>
	<1934474274.20100204200633@Zoller.lu>
	<20100204203913.GA5515@MacBook-2.local> <4B6BB1EB.3000101@root.org>
	<9B9E7EA67E1B1342B2D25F3FD1B32930033656C1@BE35.exg3.exghost.com>
Message-ID: <448e9a321002051054n2fe2e8d9obfe253a4a00f5468@mail.gmail.com>

> My first impression on seeing this (I'm still reading Dion's paper) was
> that perhaps some sort of validator or IPS-like functionality in the
> JIT, analyzing the input, could be effective, looking for malformations
> and suspicious behavior.

I propose antivirus scanning.

With this problem solved, moving on to...

/mz

From holisticinfosec at gmail.com  Mon Feb  8 15:27:14 2010
From: holisticinfosec at gmail.com (Russ McRee)
Date: Mon, 8 Feb 2010 12:27:14 -0800
Subject: [Dailydave] Directory traversal as a reconnaissance tool (Russ
	McRee)
Message-ID: <a9f482f51002081227x2c53d6csbec4df70963dc59c@mail.gmail.com>

Directory traversal as a reconnaissance tool
http://holisticinfosec.blogspot.com/2010/02/directory-traversal-as-reconnaisance.html

Like most of you, I find malicious or fraudulent online advertisers
annoying to say the least.
My typical response, upon receipt of rogue AV pop-ups, or redirects to
clearly fraudulent sites, is to "closely scrutinize" the perpetrating
site.
This effort often bears fruit as is evident in the following analysis.

My interest was recently peaked when being made aware of a number of
related sites committing abuse against a variety of brands; all quite
clearly in violation of copyrights and trademarks.
An example, for your consideration: messenger-download.info
After a little exploration it was quickly determined that these
cretins seek only to con victims out of credit card data with the
promise of illegal downloads for a fee.
Apparently these dbags have been at it for awhile.
They make it look like you're going to receive access to a legitimate
offering then they suck you in to freedownloadzone.com.
This, of course, pissed me off, so...off to the races.
A poke here, a tickle there, and voila.../etc/passwd...

--
Russ McRee
GCIH, GPEN, GCFA, CISSP
425-518-6998 cell
http://holisticinfosec.org
http://blog.holisticinfosec.org

From travis+ml-dailydave at subspacefield.org  Mon Feb  8 19:13:22 2010
From: travis+ml-dailydave at subspacefield.org (travis+ml-dailydave at subspacefield.org)
Date: Mon, 8 Feb 2010 16:13:22 -0800
Subject: [Dailydave] secure priv-dropping code in python
Message-ID: <20100209001322.GA1897@subspacefield.org>

Hey I wrote this code to safely and portably* drop permissions in
python a while back and just realized that people here might be
interested:

http://www.subspacefield.org/~travis/python/privilege/

[*] Caveat; OS-portable, not sure if it's portable between 32 and 64
    bit arches yet.  Need to think about (& test) Python c_uint size
    vs sizeof(uid_t) on 64 bit arches.

Implements design from these papers:
http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf
http://www.cs.berkeley.edu/~daw/papers/setuid-login08b.pdf

I also submitted a patch to python that implements setres[ug]id natively,
rather than having to load libc like I do in the code above.  Not sure
what its status is, but general response was good.
-- 
In God We Trust; From Everyone Else, We Need Source Code.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20100208/b63109c7/attachment.pgp 

From dave at immunityinc.com  Tue Feb  9 12:50:01 2010
From: dave at immunityinc.com (dave)
Date: Tue, 09 Feb 2010 12:50:01 -0500
Subject: [Dailydave] IE Protected Mode
Message-ID: <4B71A049.5040400@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

So one thing we noticed when testing aurora_flash today on Windows 7 is
that, you can do this:

1. Own Windows 7 IE running as a normal user with Aurora_Flash
2. Run NTVDM exploit
3. Use Local/SYSTEM rights to do whatever you want.

Of course, step 2 won't work on a 64-bit Windows 7, and step 1 is not as
reliable as we'd like (the "aurora" part of "aurora_flash" can be a bit
tricky).

Nevertheless, it's a compelling demo when your customer says "But I'm on
Windows 7!". There's a tendency for "multi-layer defense" to coalesce
into one layer. I'm not sure what to call that, but it's pretty common.
Think "CLOUDBURST vs VMWare" and "Spender vs SELINUX" and all the other
similar protections that in many cases have no effect at all.

Another thing we're including in today's CANVAS release is our test
framework, so if you want you can automate testing against lots of VM's.
Basically, it starts them up, reverts them to a snapshot, sets up a
bunch of stuff to run the exploits, and then sees if they work, and then
shuts them down. You'd think with a heap overflow run like this that it
would work either 100% of the time or 0%, but the reality is, these
things can be affected by quantum tunnelling or something, and you get
them working row times in a row, and then failing ten times in a row.

- -dave


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAktxoEkACgkQtehAhL0gheo8MACdEGQ/vOGpt36PKJJz6nA8xmxP
vF8An1XeRtPZm9ShcWO0cjo+LhgUmK/C
=YMWP
-----END PGP SIGNATURE-----

From travis+ml-dailydave at subspacefield.org  Tue Feb  9 17:45:27 2010
From: travis+ml-dailydave at subspacefield.org (travis+ml-dailydave at subspacefield.org)
Date: Tue, 9 Feb 2010 14:45:27 -0800
Subject: [Dailydave] analyzing Android
Message-ID: <20100209224527.GB1897@subspacefield.org>

Been doing some analysis of Android.

The relevant links I've collected are here:

http://www.subspacefield.org/~travis/android.html

Should be enough for interested parties to get started.

Note that you don't need a physical device; the emulator is
high-fidelity, based on QEMU, and runs the same ARM binaries as the
phone.  But you get root by default when shelling in.  I'm impressed.

Included are links to native dropbear SSHd, and rsync, so you can
access the phone easily.  Native compilation is easy, you cross-compile
with GCC for ARM and statically link against a normal libc.
-- 
In God We Trust; From Everyone Else, We Need Source Code.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20100209/f48877fa/attachment-0001.pgp 

From travis+ml-dailydave at subspacefield.org  Tue Feb  9 22:13:47 2010
From: travis+ml-dailydave at subspacefield.org (travis+ml-dailydave at subspacefield.org)
Date: Tue, 9 Feb 2010 19:13:47 -0800
Subject: [Dailydave] A small fun Python puzzle
In-Reply-To: <200804011608.41986.ergosum@neurosecurity.com>
References: <47F11B17.7050303@immunityinc.com>
	<47F14AE9.5060001@handcraftedcomputers.com.au>
	<200804011608.41986.ergosum@neurosecurity.com>
Message-ID: <20100210031347.GC1897@subspacefield.org>

On Tue, Apr 01, 2008 at 04:08:41PM +0200, ergosum wrote:
> Hi all, 
> > >>> for l in [100000, 1000000, 5000000, 10000000]:
> > ...   print '%10d %f' % (l, test(l))
> > ...
> >     100000 0.006711
> >    1000000 0.764886
> >    5000000 28.554786
> >   10000000 111.738498
> >
> > (wow - so not linear ...)
> 
> So if this is true, slicing data[1024:] should be O(M) where M = 100000, 
> 1000000, 5000000, 10000000 respectively, while slicing data[i:i+1024] should 
> always be O(N) where N = 1024. There is a huge gain here that accounts for 
> the more or less homogeneous times of the second algorithm. Nevertheless it 
> puzzles me why the slicing operation isn't linear. Anyone with a better 
> python internal knowledge can throw some light?

I think the slicing operation /is/ linear (O(M)), assuming malloc/free
as O(1) and no GC overhead.

However, in the first version of the program, it is called in a
loop, which is called ceil(M/1024) times.  So as a result, the whole
loop runs in O(M^2) time.

The second, iterative version of the program has a loop called ceil(M/1024)
times, and it uses the array slice operator, which runs in O(1024) time.
So the run time is O(M), which is borne out by the timings.

I can't find the link now, but I saw a similar issue on ha.ckers.org
recently where he was doing something similar with strings in javascript.

There's nothing surprising when you realize that creating a new
string or buffer object takes time O(M) to copy the data, where M is
the size of the new object.  You could possibly do zero-copy
operations, where one object points into the buffer used for another,
but then garbage collection and object deallocation becomes trickier.
-- 
In God We Trust; From Everyone Else, We Need Source Code.
My emails do not have attachments; it's a digital signature that your mail
program doesn't understand. | http://www.subspacefield.org/~travis/ 
If you are a spammer, please email john at subspacefield.org to get blacklisted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20100209/1a032938/attachment.pgp 

From adrien at kunysz.be  Wed Feb 10 16:45:19 2010
From: adrien at kunysz.be (Adrien Krunch Kunysz)
Date: Wed, 10 Feb 2010 21:45:19 +0000
Subject: [Dailydave] A small fun Python puzzle
In-Reply-To: <20100210031347.GC1897@subspacefield.org>
References: <47F11B17.7050303@immunityinc.com>
	<47F14AE9.5060001@handcraftedcomputers.com.au>
	<200804011608.41986.ergosum@neurosecurity.com>
	<20100210031347.GC1897@subspacefield.org>
Message-ID: <20100210214519.GC5374@baltika>

On Tue, Feb 09, 2010 at 07:13:47PM -0800, travis+ml-dailydave at subspacefield.org wrote:
> On Tue, Apr 01, 2008 at 04:08:41PM +0200, ergosum wrote:
> > Hi all, 
> > > >>> for l in [100000, 1000000, 5000000, 10000000]:
> > > ...   print '%10d %f' % (l, test(l))
> > > ...
> > >     100000 0.006711
> > >    1000000 0.764886
> > >    5000000 28.554786
> > >   10000000 111.738498
> > >
> > > (wow - so not linear ...)
> > 
> > So if this is true, slicing data[1024:] should be O(M) where M = 100000, 
> > 1000000, 5000000, 10000000 respectively, while slicing data[i:i+1024] should 
> > always be O(N) where N = 1024. There is a huge gain here that accounts for 
> > the more or less homogeneous times of the second algorithm. Nevertheless it 
> > puzzles me why the slicing operation isn't linear. Anyone with a better 
> > python internal knowledge can throw some light?
> 
> I think the slicing operation /is/ linear (O(M)), assuming malloc/free
> as O(1) and no GC overhead.
> 
> However, in the first version of the program, it is called in a
> loop, which is called ceil(M/1024) times.  So as a result, the whole
> loop runs in O(M^2) time.
> 
> The second, iterative version of the program has a loop called ceil(M/1024)
> times, and it uses the array slice operator, which runs in O(1024) time.
> So the run time is O(M), which is borne out by the timings.
> 
> I can't find the link now, but I saw a similar issue on ha.ckers.org
> recently where he was doing something similar with strings in javascript.
> 
> There's nothing surprising when you realize that creating a new
> string or buffer object takes time O(M) to copy the data, where M is
> the size of the new object.  You could possibly do zero-copy
> operations, where one object points into the buffer used for another,
> but then garbage collection and object deallocation becomes trickier.

For those who are more familiar with C than with Python and algorithm-speak,
I think it means the program is doing this:

	for (len = strlen(data); len > 0; len -= 1024) {
		for (i = 1024; i < len; i++)
			data[i-1024] = data[i];
	}

Which was this in Python:

~        while data!="":
~            data=data[1024:]

Fixing the buffer underrun in the C version is left as an exercise for
the reader.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20100210/1bb3c41b/attachment.pgp 

From dave at immunityinc.com  Wed Feb 17 16:00:46 2010
From: dave at immunityinc.com (dave)
Date: Wed, 17 Feb 2010 16:00:46 -0500
Subject: [Dailydave] Great bugs!
Message-ID: <4B7C58FE.8060406@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lately Immunity's been owning a lot of VPNs during consulting gigs.
People never seem to test them, after all, they're security products!
:>

Whoever found THIS bug on the other hand, gets remote access into a lot
of interesting boxes, I'm sure. Although they have to be configured for
NTLMv1 (if that ever happens?).

http://www.cisco.com/warp/public/707/cisco-sa-20100217-asa.shtml


NTLMv1 Authentication Bypass Vulnerability

Cisco ASA 5500 Series Adaptive Security Appliances contain a
vulnerability that could result in authentication bypass when the
affected appliance is configured to authenticate users against Microsoft
Windows servers using the NTLMv1 protocol.

Users can bypass authentication by providing an an invalid, crafted
username during an authentication request. Any services that use a AAA
server group that is configured to use the NTLMv1 authentication
protocol is affected. Affected services include:

    * Telnet access to the security appliance
    * SSH access to the security appliance
    * HTTPS access to the security appliance (including Cisco ASDM access)
    * Serial console access
    * Privileged (enable) mode access
    * Cut-through proxy for network access
    * VPN access

This vulnerability is documented in Cisco bug ID CSCte21953 ( registered
customers only) and has been assigned Common Vulnerabilities and
Exposures (CVE) ID CVE-2010-0568.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkt8WP0ACgkQtehAhL0ghepTCACcDi4oLNdtN3AsNaW/f3mnPzpY
P08AniLdAVAAkhb6lKGSe1aE3bWwk0+x
=fDa4
-----END PGP SIGNATURE-----

From richard.k.miles at googlemail.com  Wed Feb 17 16:30:15 2010
From: richard.k.miles at googlemail.com (Richard Miles)
Date: Wed, 17 Feb 2010 15:30:15 -0600
Subject: [Dailydave] Great bugs!
In-Reply-To: <4B7C58FE.8060406@immunityinc.com>
References: <4B7C58FE.8060406@immunityinc.com>
Message-ID: <194e74ff1002171330h8a2f9advca35ce5855670561@mail.gmail.com>

Do you have more details?

Also, can you share details of some of your cool VPN compromises
during your engagements?


On Wed, Feb 17, 2010 at 3:00 PM, dave <dave at immunityinc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lately Immunity's been owning a lot of VPNs during consulting gigs.
> People never seem to test them, after all, they're security products!
> :>
>
> Whoever found THIS bug on the other hand, gets remote access into a lot
> of interesting boxes, I'm sure. Although they have to be configured for
> NTLMv1 (if that ever happens?).
>
> http://www.cisco.com/warp/public/707/cisco-sa-20100217-asa.shtml
>
>
> NTLMv1 Authentication Bypass Vulnerability
>
> Cisco ASA 5500 Series Adaptive Security Appliances contain a
> vulnerability that could result in authentication bypass when the
> affected appliance is configured to authenticate users against Microsoft
> Windows servers using the NTLMv1 protocol.
>
> Users can bypass authentication by providing an an invalid, crafted
> username during an authentication request. Any services that use a AAA
> server group that is configured to use the NTLMv1 authentication
> protocol is affected. Affected services include:
>
> ? ?* Telnet access to the security appliance
> ? ?* SSH access to the security appliance
> ? ?* HTTPS access to the security appliance (including Cisco ASDM access)
> ? ?* Serial console access
> ? ?* Privileged (enable) mode access
> ? ?* Cut-through proxy for network access
> ? ?* VPN access
>
> This vulnerability is documented in Cisco bug ID CSCte21953 ( registered
> customers only) and has been assigned Common Vulnerabilities and
> Exposures (CVE) ID CVE-2010-0568.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt8WP0ACgkQtehAhL0ghepTCACcDi4oLNdtN3AsNaW/f3mnPzpY
> P08AniLdAVAAkhb6lKGSe1aE3bWwk0+x
> =fDa4
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>

From jcran at 0x0e.org  Wed Feb 17 17:03:02 2010
From: jcran at 0x0e.org (Jonathan Cran)
Date: Wed, 17 Feb 2010 17:03:02 -0500
Subject: [Dailydave] Great bugs!
In-Reply-To: <194e74ff1002171330h8a2f9advca35ce5855670561@mail.gmail.com>
References: <4B7C58FE.8060406@immunityinc.com>
	<194e74ff1002171330h8a2f9advca35ce5855670561@mail.gmail.com>
Message-ID: <40a166ad1002171403j2837822ch6d70a0e292f67aa5@mail.gmail.com>

On Wed, Feb 17, 2010 at 4:30 PM, Richard Miles
<richard.k.miles at googlemail.com> wrote:
> Do you have more details?
>
> Also, can you share details of some of your cool VPN compromises
> during your engagements?

Mike Zusman (http://schmoil.blogspot.com/) of the Intrepidus Group has
done some awesome research here. This stuff definitely works.

http://www.blackhat.com/presentations/bh-usa-08/Zusman/BH_US_08_Zusman_SSL_VPN_Abuse.pdf

jcran

--
Jonathan Cran
jcran at 0x0e.org
http://www.0x0e.org/

From dave at immunityinc.com  Fri Feb 19 09:45:53 2010
From: dave at immunityinc.com (dave)
Date: Fri, 19 Feb 2010 09:45:53 -0500
Subject: [Dailydave] XSS in viewstate
Message-ID: <4B7EA421.6030001@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf

This, on first glance, looks real to me. Does anyone have any comments
on it? ViewState is pretty complex and fairly opaque. If I understand
properly, MS does not publish the full specs to it? Maybe the Mono team
found them somewhere?

- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
=w0qz
-----END PGP SIGNATURE-----

From chris at casabasecurity.com  Fri Feb 19 12:26:34 2010
From: chris at casabasecurity.com (Chris Weber)
Date: Fri, 19 Feb 2010 09:26:34 -0800
Subject: [Dailydave] XSS in viewstate
In-Reply-To: <4B7EA421.6030001@immunityinc.com>
References: <4B7EA421.6030001@immunityinc.com>
Message-ID: <00b001cab188$b235cf60$16a16e20$@com>

One important thing to note is that VIEWSTATE MAC protection is enabled by default.  It's only when this protection is purposely disabled that tampering and this XSS vector become possible.  You can detect when this protection has been disabled either through code review, or passively with dynamic testing which is what we'll be doing with the Watcher tool.

-Chris


-----Original Message-----
From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of dave
Sent: Friday, February 19, 2010 6:46 AM
To: dailydave at lists.immunityinc.com
Subject: [Dailydave] XSS in viewstate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf

This, on first glance, looks real to me. Does anyone have any comments
on it? ViewState is pretty complex and fairly opaque. If I understand
properly, MS does not publish the full specs to it? Maybe the Mono team
found them somewhere?

- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
=w0qz
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave


From rawdataz at gmail.com  Fri Feb 19 13:45:53 2010
From: rawdataz at gmail.com (Raw Data)
Date: Fri, 19 Feb 2010 18:45:53 +0000
Subject: [Dailydave] XSS in viewstate
In-Reply-To: <4B7EA421.6030001@immunityinc.com>
References: <4B7EA421.6030001@immunityinc.com>
Message-ID: <4ec352d91002191045u69f23d36g87d35e8f8473e4b1@mail.gmail.com>

Hi Dave,

This problem has been hinted by MS since the release of .Net2.0, even
my team was able to reproduce this a while ago, so I was a bit
surprise when this advisory was released, as I thought this was
already known.

>From my point of view the problem here is not the tampering of
non-encrypted/signed Viewstate. The problem lies with applications
that are load-balanced and using signed/encrypted Viewstate.

When Viewstate is used on a single machine, the encryption key/signing
MAC is managed internally and auto-generated. However, when it's being
used on a web farm environment this key has to be shared between all
servers, so it has to be set manually, and here lies the problem. Will
everybody instruct their operations teams to change this on, let's
say, a weekly basis?

Worse even, now that Viewstate is on the spotlight, it's fairly easy
to imagine that someone will write a tool to brute-force it or devise
some easier way to break it. Remember that the MachineKey which is
used to encrypt/sign the Viewstate has other functions besides this
one (Forms authentication tickets and role cookies).

Solutions?

Cheers,

RD


On Fri, Feb 19, 2010 at 2:45 PM, dave <dave at immunityinc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
>
> This, on first glance, looks real to me. Does anyone have any comments
> on it? ViewState is pretty complex and fairly opaque. If I understand
> properly, MS does not publish the full specs to it? Maybe the Mono team
> found them somewhere?
>
> - -dave
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
> T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
> =w0qz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>

From DByrne at trustwave.com  Fri Feb 19 14:15:25 2010
From: DByrne at trustwave.com (David Byrne)
Date: Fri, 19 Feb 2010 13:15:25 -0600
Subject: [Dailydave] XSS in viewstate
In-Reply-To: <4B7EA421.6030001@immunityinc.com>
References: <4B7EA421.6030001@immunityinc.com>
Message-ID: <E64731F3ABEB554E8591AFD1DC20DEE1128FF065AD@SKYVS1.trustwave.com>

This is very real. The Hacking Lab document is actually an (unattributed) cut and paste job from a larger advisory that we released earlier in the month. The topic was discussed in more detail at a BlackHat DC presentation. 

https://www.trustwave.com/spiderlabs/advisories/TWSL2010-001.txt
http://www.blackhat.com/html/bh-dc-10/bh-dc-10-archives.html#Byrne


Microsoft doesn't fully document the view state format, but it isn't too hard to discover using tools like .Net Reflector (http://reflector.red-gate.com). There are several tools that will decode the view state; my favorite is ViewStateHacker (http://www.woany.co.uk/viewstatehacker/). 

Our advisory is about view state vulnerabilities in three different web app frameworks. Microsoft comes out pretty good because they secure the view state by default, but it's not that rare to find ASP.Net web apps with disabled view state security. The reason is usually lazy administration; load balanced environments are simpler when the view state security is disabled (what isn't easier without security). The only framework vulnerability that we could find in .Net was XSS. Of course, custom applications can have any type of vulnerability introduced.

Apache MyFaces and Sun Mojarra were more serious. View state security is disabled by default and few sites use it. In addition to XSS, it's also possible to upload JSP Expression Language statements to the server. This allows an attacker to read any request, session, application, or server-scoped variable defined by the developer. It isn't unusual for sensitive data to be stored in server-side session variables, so it can be a useful attack.



Thanks,
David Byrne
Senior Security Consultant
Trustwave - SpiderLabs, Application Security

Email: dbyrne at trustwave.com
Phone (office & cell): 720-279-4123





-----Original Message-----
From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of dave
Sent: Friday, February 19, 2010 7:46 AM
To: dailydave at lists.immunityinc.com
Subject: [Dailydave] XSS in viewstate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf

This, on first glance, looks real to me. Does anyone have any comments
on it? ViewState is pretty complex and fairly opaque. If I understand
properly, MS does not publish the full specs to it? Maybe the Mono team
found them somewhere?

- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
=w0qz
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave




From dave at immunityinc.com  Fri Feb 19 14:15:44 2010
From: dave at immunityinc.com (dave)
Date: Fri, 19 Feb 2010 14:15:44 -0500
Subject: [Dailydave] XSS in viewstate
In-Reply-To: <00b001cab188$b235cf60$16a16e20$@com>
References: <4B7EA421.6030001@immunityinc.com>
	<00b001cab188$b235cf60$16a16e20$@com>
Message-ID: <4B7EE360.8000900@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We usually see MAC protection turned off on at least one page during an
assessment. Does this mean that you can always have XSS if MAC
protection is turned off? That would be pretty cool.

I'm not familiar with Expression Language, but the TrustWave advisory
indicates that things can be executed on the server as well. What's the
story there?

- -dave
( https://www.trustwave.com/spiderlabs/advisories/TWSL2010-001.txt )


Chris Weber wrote:
> One important thing to note is that VIEWSTATE MAC protection is enabled by default.  It's only when this protection is purposely disabled that tampering and this XSS vector become possible.  You can detect when this protection has been disabled either through code review, or passively with dynamic testing which is what we'll be doing with the Watcher tool.
> 
> -Chris
> 
> 
> -----Original Message-----
> From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of dave
> Sent: Friday, February 19, 2010 6:46 AM
> To: dailydave at lists.immunityinc.com
> Subject: [Dailydave] XSS in viewstate
> 
> http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
> 
> This, on first glance, looks real to me. Does anyone have any comments
> on it? ViewState is pretty complex and fairly opaque. If I understand
> properly, MS does not publish the full specs to it? Maybe the Mono team
> found them somewhere?
> 
> -dave
_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkt+418ACgkQtehAhL0gheqD1wCfXQXEjvXeJhTaF+NfSpareeOo
D88AnjbySEoJBWp0NFvjuDw7aYndLeb8
=jZiY
-----END PGP SIGNATURE-----

From DByrne at trustwave.com  Fri Feb 19 15:20:19 2010
From: DByrne at trustwave.com (David Byrne)
Date: Fri, 19 Feb 2010 14:20:19 -0600
Subject: [Dailydave] XSS in viewstate
In-Reply-To: <4ec352d91002191045u69f23d36g87d35e8f8473e4b1@mail.gmail.com>
References: <4B7EA421.6030001@immunityinc.com>
	<4ec352d91002191045u69f23d36g87d35e8f8473e4b1@mail.gmail.com>
Message-ID: <E64731F3ABEB554E8591AFD1DC20DEE1128FF065C4@SKYVS1.trustwave.com>

In our original advisory, we did comment that Microsoft hinted at this vulnerability in a rather buried document (http://support.microsoft.com/kb/829743), but we could find no other references to it on Microsoft's website or anywhere else. While there are plenty of comments about application developers abusing the view state, this is the first time (as far as we know) that the .Net framework was demonstrated to be vulnerable to XSS through the view state. 

The machine key does have to be manually set in a load balanced environment, but I don't see that as being a problem. .Net supports 512-bit machine keys (http://msdn.microsoft.com/en-us/library/ms998288.aspx), which is well beyond brute-force attacks. That's such a large key space that I don't think rotation is critical to maintain good security. If a way to bypass the MAC is discovered, that would be huge news, but it seems to be pretty solid for now.


Thanks,
David Byrne
Senior Security Consultant
Trustwave - SpiderLabs, Application Security



-----Original Message-----
From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Raw Data
Sent: Friday, February 19, 2010 11:46 AM
To: dailydave at lists.immunityinc.com
Subject: Re: [Dailydave] XSS in viewstate

Hi Dave,

This problem has been hinted by MS since the release of .Net2.0, even
my team was able to reproduce this a while ago, so I was a bit
surprise when this advisory was released, as I thought this was
already known.

>From my point of view the problem here is not the tampering of
non-encrypted/signed Viewstate. The problem lies with applications
that are load-balanced and using signed/encrypted Viewstate.

When Viewstate is used on a single machine, the encryption key/signing
MAC is managed internally and auto-generated. However, when it's being
used on a web farm environment this key has to be shared between all
servers, so it has to be set manually, and here lies the problem. Will
everybody instruct their operations teams to change this on, let's
say, a weekly basis?

Worse even, now that Viewstate is on the spotlight, it's fairly easy
to imagine that someone will write a tool to brute-force it or devise
some easier way to break it. Remember that the MachineKey which is
used to encrypt/sign the Viewstate has other functions besides this
one (Forms authentication tickets and role cookies).

Solutions?

Cheers,

RD


On Fri, Feb 19, 2010 at 2:45 PM, dave <dave at immunityinc.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
>
> This, on first glance, looks real to me. Does anyone have any comments
> on it? ViewState is pretty complex and fairly opaque. If I understand
> properly, MS does not publish the full specs to it? Maybe the Mono team
> found them somewhere?
>
> - -dave
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt+pCEACgkQtehAhL0ghepUJQCeMs9I2pnL3z4eYicYF44xaUgd
> T4gAnjD/aFU9Z2tWRHge7i4Ch48BS3Ph
> =w0qz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave



From DByrne at trustwave.com  Fri Feb 19 16:44:29 2010
From: DByrne at trustwave.com (David Byrne)
Date: Fri, 19 Feb 2010 15:44:29 -0600
Subject: [Dailydave] XSS in viewstate
In-Reply-To: <4B7EE360.8000900@immunityinc.com>
References: <4B7EA421.6030001@immunityinc.com>
	<00b001cab188$b235cf60$16a16e20$@com>
	<4B7EE360.8000900@immunityinc.com>
Message-ID: <E64731F3ABEB554E8591AFD1DC20DEE1128FF065DF@SKYVS1.trustwave.com>

In theory, just about all pages will be vulnerable to XSS if MAC is turned off. In practice, it can be difficult to launch an attack. One problem is that pages won't use the client's view state if .Net decides it isn't fresh. Some pages may happen to be written so that the client-side state is never fresh. 

Again, in theory, it should be possible to add attributes to the views state to form an attack, but I've found it much easier to alter existing attributes, usually text or innerhtml values. ViewStateHacker is a great tool for view state analysis but it wasn't really intended for extensive client-side editing. That's what I use now, but it's a pain. 


Regarding Expression Language (EL), it only allows values to be read; you can't set anything. Injecting EL into JavaServer Faces view states makes it possible to read server-side session variables (and similarly scoped data).



Thanks,
David Byrne
Senior Security Consultant
Trustwave - SpiderLabs, Application Security





-----Original Message-----
From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of dave
Sent: Friday, February 19, 2010 12:16 PM
To: Chris Weber
Cc: dailydave at lists.immunityinc.com
Subject: Re: [Dailydave] XSS in viewstate

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We usually see MAC protection turned off on at least one page during an
assessment. Does this mean that you can always have XSS if MAC
protection is turned off? That would be pretty cool.

I'm not familiar with Expression Language, but the TrustWave advisory
indicates that things can be executed on the server as well. What's the
story there?

- -dave
( https://www.trustwave.com/spiderlabs/advisories/TWSL2010-001.txt )


Chris Weber wrote:
> One important thing to note is that VIEWSTATE MAC protection is enabled by default.  It's only when this protection is purposely disabled that tampering and this XSS vector become possible.  You can detect when this protection has been disabled either through code review, or passively with dynamic testing which is what we'll be doing with the Watcher tool.
> 
> -Chris
> 
> 
> -----Original Message-----
> From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of dave
> Sent: Friday, February 19, 2010 6:46 AM
> To: dailydave at lists.immunityinc.com
> Subject: [Dailydave] XSS in viewstate
> 
> http://www.hacking-lab.com/misc/downloads/ViewState_Afames.pdf
> 
> This, on first glance, looks real to me. Does anyone have any comments
> on it? ViewState is pretty complex and fairly opaque. If I understand
> properly, MS does not publish the full specs to it? Maybe the Mono team
> found them somewhere?
> 
> -dave
_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkt+418ACgkQtehAhL0gheqD1wCfXQXEjvXeJhTaF+NfSpareeOo
D88AnjbySEoJBWp0NFvjuDw7aYndLeb8
=jZiY
-----END PGP SIGNATURE-----
_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave



From nruff at security-labs.org  Sat Feb 20 15:27:41 2010
From: nruff at security-labs.org (Nicolas RUFF)
Date: Sat, 20 Feb 2010 21:27:41 +0100
Subject: [Dailydave] XSS in viewstate
In-Reply-To: <E64731F3ABEB554E8591AFD1DC20DEE1128FF065AD@SKYVS1.trustwave.com>
References: <4B7EA421.6030001@immunityinc.com>
	<E64731F3ABEB554E8591AFD1DC20DEE1128FF065AD@SKYVS1.trustwave.com>
Message-ID: <4B8045BD.1010201@security-labs.org>

> Microsoft doesn't fully document the view state format, but it isn't
> too hard to discover using tools like .Net Reflector
> (http://reflector.red-gate.com). There are several tools that will
> decode the view state; my favorite is ViewStateHacker
> (http://www.woany.co.uk/viewstatehacker/).

	Hello,

I already had a look at that in the past, and it appears that ViewState
data is encoded using System.Web.UI.LosFormatter (LOS meaning Limited
Object Serialization).

Everything can be found in System.Web.dll (from the .NET Framework). It
might even be available in the source
(http://referencesource.microsoft.com/netframework.aspx).

There is at least one Open Source project that began to reimplement the
serialization logic (but it seems pretty dead right now):
http://sourceforge.net/projects/viewstate/

>From what I remember, that serialization protocol was a real mess. I
guess all "ViewState hacking" tools out there are simple wrappers of
System.Web.UI.LosFormatter.

Regards,
- Nicolas RUFF

From ap at gnucitizen.org  Thu Feb 25 02:37:16 2010
From: ap at gnucitizen.org (Adrian P.)
Date: Thu, 25 Feb 2010 07:37:16 +0000
Subject: [Dailydave] dnsmap v0.30 + embedded devices discovery trick
Message-ID: <10e6de611002242337p33310f50k9a1146100c01fe25@mail.gmail.com>

Hello folks,

Just wanted to let you know that we recently released a new version of dnsmap.

dnsmap is a command line tool originally released in 2006 which helps
discover target subdomains and IP ranges during the initial stages of
an infrastructure pentest. dnsmap is a passive(ish) discovery tool
meant to be used before an actual active attack. It?s an alternative
to other discovery techniques such as whois lookups, scanning large IP
ranges, etc. Run dnsmap and you should be able spot netblocks of a
target organization in a relatively short period of time.

The following are some of the new features included in version 0.30:

 IPv6 support
 Makefile included
 delay option (-d) added. This is useful in cases where dnsmap is
killing your bandwidth
 ignore IPs option (-i) added. This allows ignoring user-supplied IPs
from the results. Useful for domains which cause dnsmap to produce
false positives
 changes made to make dnsmap compatible with OpenDNS
 disclosure of internal IP addresses (RFC 1918) are reported
 updated built-in wordlist
 included a standalone three-letter acronym (TLA) subdomains wordlist
 domains susceptible to ?same site? scripting are reported
 completion time is now displayed to the user
 mechanism to attempt to bruteforce wildcard-enabled domains
 unique filename containing timestamp is now created when no specific
output filename is supplied by user
 various minor bugs fixed

More info here:
http://www.gnucitizen.org/blog/dnsmap-v030-is-now-out/

We have also documented a method to find embedded devices on the web *without*:

1) Querying search engines for content that is unique to the targetted
devices (e.g.: URLs, HTML title)
or
2) Scanning random IP addresses and programmatically detecting if the
web interface of a given device is present.

Instead, we show a less popular method based on 3) bruteforcing
subdomains of DDNS services supported by the target device. As an
example, we show how this technique can be used to discover Linksys IP
cameras by using dnsmap and some bash scripting tricks:

http://www.gnucitizen.org/blog/hacking-linksys-ip-cameras-pt-6/

Enjoy!

-- 
pagvac | GNUCITIZEN.org
PGP Key ID: 0x6B232C7C

From stefan.esser at sektioneins.de  Sat Feb 27 07:14:05 2010
From: stefan.esser at sektioneins.de (Stefan Esser)
Date: Sat, 27 Feb 2010 13:14:05 +0100
Subject: [Dailydave] Month of PHP Security 2010 - CALL FOR PAPERS
Message-ID: <4B890C8D.6000100@sektioneins.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Month of PHP Security 2010 - CALL FOR PAPERS
- --------------------------------------------

Three years ago, in March 2007, the Hardened-PHP project had organized
the Month of PHP Bugs. During one month more than 40 vulnerabilities in
the PHP interpreter were disclosed in order to improve the overall
security of PHP. Now, three years later, SektionEins GmbH  will
continue in the same spirit and organize the Month of PHP Security.

The intention of the Month of PHP Security is to gather the best
research and articles about PHP security topics from the security
community and share them with the rest of the world. This time the goal
is not only to improve the security of PHP itself and applications
directly by fixing security bugs, but also to help PHP developers
around the world to write better and more secure PHP applications.

The Month of PHP Security will be held in May 2010 by SektionEins
GmbH. During the month of May all qualifying entries will be published
at http://php-security.org day by day.


CFP Committee
- -------------
The CFP committee for the Month of PHP Security consists of

1) Johann-Peter Hartmann
2) Stefan Esser
3) Fukami
4) Ben Fuhrmannek

The CFP committee will review all submissions and select the list of
articles that will be published on http://php-security.org


Accepted Topics/Articles
- ------------------------
* New vulnerability in PHP [1]
  (not simple safe_mode, open_basedir bypass vulnerabilities)
* New vulnerability in PHP related software [1]
  (popular 3rd party PHP extensions/patches)
* Explain a single topic of PHP application security in detail
  (such as guidelines on how to store passwords)
* Explain a complicated vulnerability in/attack against a PHP
  widespread application [1]
* Explain a complicated topic of attacking PHP (e.g. explain how to
  exploit heap overflows in PHP's heap implementation)
* Explain how to attack encrypted PHP applications
* Release of a new open source PHP security tool
* Other topics related to PHP or PHP application security

[1] Articles about new vulnerabilities should mention possible
fixes or mitigations.


Responsible Disclosure
- ----------------------
In case of submitted vulnerabilities SektionEins GmbH will contact
the security team of the software vendor after the submission deadline
and share the vulnerability information with them. Along with the
vulnerability information SektionEins will provide the name of the
submitting party in order to give proper credits.


Prizes
- ------
At the end of May the CFP committee will review the published
material and determine the best entries. Selected winners will
get the following prizes.

   1.       1000 EUR + Syscan Ticket + CodeScan PHP License

   2.       750 EUR + Syscan Ticket

   3.       500 EUR + Syscan Ticket

   4.       250 EUR + Syscan Ticket

   5.-6.    CodeScan PHP License
   
   7.-16.   Amazon Coupon of 65 USD/50 EUR

SektionEins reserves the right to disqualify any submitted entry.
While employees of SektionEins can and will submit entries for
the Month of PHP Security they are excluded from receiving prizes.

The 1000 EUR cash prize and the Syscan tickets were generously
sponsored by Syscan. CodeScan PHP Licenses were sponsored by
CodeScan Limited. All other cash and non-cash prizes are sponsored
by SektionEins.

The winners of the Syscan tickets can choose one of the four
Syscan 2010 conferences to go to. Syscan Tickets include free
admission to the conference, speaker's dinner and speaker party.
Hotel and travelcosts are NOT included.

Please note that non-cash prizes cannot be changed into cash prizes.


Submission
- ----------
Submissions should be sent to cfp at php-security.org and consist of the
following information:

1) Name and contact information (e-mail, postal address)
2) Employer and/or affiliations
3) Article about one of the allowed topics (at least 1000 words)
4) Optionally additional material like slides, whitepaper in PDF format

All submissions must be in English. The preferred delivery format is
plain text or HTML, but PDF is also accepted. Please pack all the
required items (pictures, text, ...) in a ZIP archive and submit this
ZIP archive by email.

Deadline for submissions is April 11, 2010.


Additional Information
- ----------------------
After submission SektionEins GmbH will acknowledge submissions with
a signed email. If you do not receive such an email within one week
after submission, then please contact us at cfp at php-security.org
again.

By submitting your article you are granting SektionEins GmbH the rights
to reproduce, distribute, advertise and show your article including but
not limited to http://php-security.org, printed and/or electronic
advertisements, and all other media. However you are still allowed to
publish your own work in whatever way you want.


Thanks
- ------
We would like to thank Syscan and Coseinc for generously offering
1000 EUR cash prize and four tickets to Syscan. If you are interested
in the latest and greatest security research you should really consider
visiting one of the four Syscan conferences. You will find furhter
information at http://www.syscan.org/

Also we would like to thank CodeScan Limited to offer CodeScan for PHP
licenses as a prize. If you are interested in static code analysis for
PHP, you might want to check http://www.codescan.com/.


Additional Drawing
- ------------------
If you help us to spread the word about the Month of PHP Security
and the open CFP by writing a blog posting about it, you have the
chance to win one of ten 33 USD/25 EUR Amazon Coupons. To participate
you have to write a blog posting about the Month of PHP Security CFP
and send a link to your blog posting to drawing at php-security.org
The winners will be announced on May 1, 2010.

- --
Thank you
Stefan Esser
Organiser
Month of PHP Security / php-security.org
SektionEins GmbH / www.sektioneins.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuJDI0ACgkQSuF5XhWr2nhrMACfQIsISclmabFJ0FvK07Cy4hZ0
0QgAnjxiQjmKTIAlEXP55BHm2W1S343Q
=uu/v
-----END PGP SIGNATURE-----