Pages:
Author

Topic: New Attack Vector - page 4. (Read 46611 times)

staff
Activity: 4242
Merit: 8672
July 17, 2013, 10:48:24 AM
#54
Oh, I get it - its the fStrictEncodings.
Thanks for explaining Wink
Yup. The chain is stuffed full of old violations too. You can rig it to always be strict and reindex the chain and watch it reject it if you're bored. Smiley
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 10:46:51 AM
#53
There is no risk for a hard fork at all right now, by the way. This is just local client policy about which transactions are relayed.
Are you sure?
From what I see, the only place where IsCanonicalSignature is called from is EvalScript - the same function the blockchain parser uses.
Code:
bool fSuccess = (!fStrictEncodings || (IsCanonicalSignature(vchSig) && IsCanonicalPubKey(vchPubKey)));
if (fSuccess)
    fSuccess = CheckSig(vchSig, vchPubKey, scriptCode, txTo, nIn, nHashType, flags);
Oh, I get it - its the fStrictEncodings.
Thanks for explaining Wink

Yeah, it would not have caused a hard fork - sorry for messing up.
I once analyzed the byte problem (I mentioned before) and then realized that fixing it would require a hard fork. And this mislead me. Wink
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 10:44:17 AM
#52
kokjo, what was the OpenSSL command/code you used to generate that signature?

There are reasons canonical checks were adopted (it will fix a variety of attacks and sharp edges in the protocol). However if your OpenSSL is generating non canonical sigs, we'd very much like to find out why.

Code:
ssl = ctypes.cdll.LoadLibrary(ctypes.util.find_library('ssl'))
NID_secp256k1 = 714 # from openssl/obj_mac.h

def check_result (val, func, args):
    if val == 0:
        raise ValueError
    else:
        return ctypes.c_void_p (val)

ssl.EC_KEY_new_by_curve_name.restype = ctypes.c_void_p
ssl.EC_KEY_new_by_curve_name.errcheck = check_result

...

    def __init__(self):
        self.k = ssl.EC_KEY_new_by_curve_name(NID_secp256k1)

...

    def sign(self, hash):
        sig_size = ssl.ECDSA_size(self.k)
        mb_sig = ctypes.create_string_buffer(sig_size)
        sig_size0 = ctypes.POINTER(ctypes.c_int)()
        assert 1 == ssl.ECDSA_sign(0, hash, len(hash), mb_sig, ctypes.byref(sig_size0), self.k)
        return mb_sig.raw
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 10:43:26 AM
#51
There is no risk for a hard fork at all right now, by the way. This is just local client policy about which transactions are relayed.
Are you sure?
From what I see, the only place where IsCanonicalSignature is called from is EvalScript - the same function the blockchain parser uses.
Code:
bool fSuccess = (!fStrictEncodings || (IsCanonicalSignature(vchSig) && IsCanonicalPubKey(vchPubKey)));
if (fSuccess)
    fSuccess = CheckSig(vchSig, vchPubKey, scriptCode, txTo, nIn, nHashType, flags);
staff
Activity: 4242
Merit: 8672
July 17, 2013, 10:42:37 AM
#50
As this thread politely explains, OpenSSL violates the ASN.1/DER standard and will accept encoding which are invalid in a multitude of ways.  Because of this any implementation of the Bitcoin protocol— no matter what library it used— have to be bug for bug compatible with OpenSSL.  Worse, the behavior creates malleability of signatures which create the attack describe in this thread and which actually turns out to be even somewhat worse than described here.

Malleability  was being actively employed on the network in order to double spend and dos attack.  To close the attacks a strict, canonical, valid encoding must be enforced. As a bonus, if the enforcement is eventually made a network rule alternative implementations will not have to emulate OpenSSL's signature handling bugs.

It's interesting to hear that it's _creating_ these signatures: IIRC, we did not need to change Bitcoin in any way to avoid creating signatures with non-canonical encoding, OpenSSL's weird behavior is on the decoding side. It would be useful to know how you're (ab)using OpenSSL to accomplish this and/or what version of it you're using. It would be concerning, indeed, if there were some way to get the reference software to produce such a thing— but it's certainly not done so on normal systems in the past.

In any case, this was tested for months, deployed in the codebase as non-enforced for months prior to activation, announced widely. Bitcoin will not remain vulnerable to attack just so you can be lazy and produce sloppy inefficiently encoded signatures. If you are unwilling to take the effort to understand this and get it right it seems unlikely that you'll get the rest of the protocol right. Cryptographic distributed consensus systems may not be rocket surgery, but perhaps they're a little too complicated for some people— perhaps the kind of people whos first recourse is to start slinging insults at people for correcting a security vulnerability— to safely implement.

Piotr_n, this is not yet a network rule. Presumably someday it will be. Today this signature correctness is not enforced against blocks, just against free transactions. This means that miners can still perform the related malleability attacks but other users cannot, and it still means that alternative implementations must remain bug for bug compatible with OpenSSL's buggy validation. This is also why it's not a forking-anything to change.
legendary
Activity: 1072
Merit: 1181
July 17, 2013, 10:38:10 AM
#49
fix bitcoin, go make a standard and stick to it.

No offence, but all this work is being done to actually make it comply to the standard.

The problem was that even though OpenSSL always created transactions that were compliant, it accepts signatures in non-standard encodings. This is bad, as every alternate implementation is required to implement the rules exactly as OpenSSL is. We've known this issue for a while, brought it up several times on the development mailing list and on this forum, investigated who was creating such transactions and gotten them to upgrade, until the frequency of such transactions was low enough. Then finally we added a rule to make bitcoind not relay or mine such transaction - without making them invalid even.

In this case, if the signature created made by bitcoind is non-standard, then we have a serious bug in the signature creation code. AFAIK, no bitcoin(d/qt) ever has ever created signatures that are currently considered non-standard however. If you're creating them yourself, it's possible to create valid transactions that are being rejected now. I'm sure you prefer your bitcoin node to reject the transaction immediately over only have the network reject it with you wondering why it doesn't confirm.

There is no risk for a hard fork at all right now, by the way. This is just local client policy about which transactions are relayed.
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 10:37:03 AM
#48
Fuck you liar! sipa added the check only 11 months ago.
Don't talk to me like this - I only tried to help you, but I can swear as well.
11 months ago is long enough to cause a hard fork, if they revert the change now.
no its not. there already exist transactions that violates the beauty checks, and other clients accept these transactions too.
no. such transactions don't exist. not in the blockchain.
it doesn't matter what other clients accept - it only matters what miners accept, and 99% of them are already at satoshi 0.8.x
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 10:36:40 AM
#47
Is there a kokjo-coin available? Cheesy
No. But it will certainly come if the devs continue to behave like tards
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 10:35:19 AM
#46
Fuck you liar! sipa added the check only 11 months ago.
Don't talk to me like this - I only tried to help you, but I can swear as well.
11 months ago is long enough to cause a hard fork, if they revert the change now.
no its not. there already exist transactions that violates the beauty checks, and other clients accept these transactions too.
legendary
Activity: 1526
Merit: 1134
July 17, 2013, 10:32:50 AM
#45
kokjo, what was the OpenSSL command/code you used to generate that signature?

There are reasons canonical checks were adopted (it will fix a variety of attacks and sharp edges in the protocol). However if your OpenSSL is generating non canonical sigs, we'd very much like to find out why.
hero member
Activity: 886
Merit: 1013
July 17, 2013, 10:31:15 AM
#44
BITCOIN IS SHIT, it does not accept signatures from the most well know implementation of crypto algorithms: openssl.

Code:
ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

why the fuck is this stuff implemented the way it is?

bitcoin and especially the satoshi client is a stinking pile faulty patches on other patches of bad and stupidly written code!

All main developers is bad at coding, and should feel bad about it.

/rant over

Is there a kokjo-coin available? Cheesy
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 10:25:26 AM
#43
Fuck you liar! sipa added the check only 11 months ago.
Don't talk to me like this - I only tried to help you, but I can swear as well.
11 months ago is long enough to cause a hard fork, if they revert the change now.

You should have mined your ugly tx before this change - that would surely prevent it Smiley
legendary
Activity: 1232
Merit: 1094
July 17, 2013, 10:24:14 AM
#42
go make a standard and stick to it.

Oh, the irony Smiley.

You basically want openSSL to be the standard.  That makes it harder for clients to be sure they are compatible.  

With the "beauty" checks, a script parser can be sure that it covers every valid signature.
kjj
legendary
Activity: 1302
Merit: 1026
July 17, 2013, 10:22:35 AM
#41
Well, good luck with that, I guess.
so you are okay with that the developers is destroying bitcoin by trying to make it better?

Destroying?  Nonsense.

Leave your hyperbole at home and go read up on why non-canonical encodings are bad, and why the developers decided to mark them as non-standard.  (That the satoshi client refuses to emit anything it considers to be nonstandard should be obvious.)
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 10:20:11 AM
#40
Well, good luck with that, I guess.
so you are okay with that the developers is destroying bitcoin by trying to make it better?
this code if very old.
if they "fix" it now, it would surely create a hard fork soon - you don't really want it.
better change your code, adapting it to the beauty checks.
that is the reality all the new emerging bitcoin implementation will need to live in.
no altcoin can also be perfect from the first release, and they all are going to meet exactly the same issues.
Fuck you liar! sipa added the check only 11 months ago.

Source:
https://github.com/bitcoin/bitcoin/blame/master/src/script.cpp
https://github.com/bitcoin/bitcoin/commit/58bc86e37fda1aec270bccb3df6c20fbd2a6591c
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 10:14:04 AM
#39
Well, good luck with that, I guess.
so you are okay with that the developers is destroying bitcoin by trying to make it better?
this code if very old.
if they "fix" it now, it would surely create a hard fork soon - you don't really want it.
better change your code, adapting it to the beauty checks.
that is the reality all the new emerging bitcoin implementation will need to live in.
no altcoin can also be perfect from the first release, and they all are going to face similar issues in a future.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 10:11:37 AM
#38
Well, good luck with that, I guess.
so you are okay with that the developers is destroying bitcoin by trying to make it better?

prediction:
in a few years bitcoin will be worth nothing and a altcoin not based on the satoshi source with a solid standard will thrive.
because developers fucked bitcoin up, with all kind of insane checking and worse coding skills. bitcoin will nothing more then a bunch of dirty hacks.
kjj
legendary
Activity: 1302
Merit: 1026
July 17, 2013, 10:03:41 AM
#37
you don't have to tell my where my perfectly valid transaction fails bitcoind's beauty check, you need to remove the check from the satoshi client and stop adding useless crap to it.

the signature was generated with openssl, and is perfectly valid, my client and blockchain.org agrees.
The satoshi client should not be the protocol standard, of cource i could fix my transaction and give you people a free pass to fuck around more with bitcoin.

I will not allow this, and i object to the elitist culture among the main developers.

fix bitcoin, go make a standard and stick to it.

Well, good luck with that, I guess.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 09:58:03 AM
#36
you don't have to tell my where my perfectly valid transaction fails bitcoind's beauty check, you need to remove the check from the satoshi client and stop adding useless crap to it.

the signature was generated with openssl, and is perfectly valid, my client and blockchain.org agrees.
The satoshi client should not be the protocol standard, of cource i could fix my transaction and give you people a free pass to fuck around more with bitcoin.

I will not allow this, and i object to the elitist culture among the main developers.

fix bitcoin, go make a standard and stick to it.
kjj
legendary
Activity: 1302
Merit: 1026
July 17, 2013, 09:44:27 AM
#35
You have two bytes of padding in there.

You may want to look at the bitcoind code to see how it gets unpadded signatures.

Code:
6c - script length
49 - signature length - should be 47 once the padding is removed
30 - marker
44 - rs length
02 - marker
20 - R length
3ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 - R
02 - marker
20 - S length
14247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c5173 - S
00 - garbage - invalid
00 - garbage - invalid
01 - SIGHASH flag
21 - pubkey length
02 - pubkey is compressed and even
0c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95 - pubkey
Pages:
Jump to: