Author

Topic: New Attack Vector - page 5. (Read 46614 times)

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: jackjack on July 17, 2013, 09:21:58 AM

Returning

Code:

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

because of a too low fee is rather strange

that makes sense.
so blockchain.info does not use bitcoind - I was always wondering..

@kokjo your tx won't get mined.
it does not like the fact that the 44 ( field) in your sig is not the actual sig length minus 3.

Code:

if (vchSig[1] != vchSig.size()-3)
return error("Non-canonical signature: wrong length marker");

jackjack

legendary

Activity: 1176

Merit: 1280

May Bitcoin be touched by his Noodly Appendage

Quote from: piotr_n on July 17, 2013, 09:17:41 AM

Quote from: kokjo on July 17, 2013, 09:13:10 AM

0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb500000 0006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020 c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f01 00000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000

this one works for me as well, so its definitely a different issue than I had mentioned before.

maybe bitcoind just does not like your low 0.00000071 BTC fee?

Returning

Code:

because of a too low fee is rather strange

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: kokjo on July 17, 2013, 09:13:10 AM

this one works for me as well, so its definitely a different issue than I had mentioned before.

maybe bitcoind just does not like your low 0.00000071 BTC fee?

kokjo

legendary

Activity: 1050

Merit: 1000

You are WRONG!

Quote from: kjj on July 17, 2013, 08:43:47 AM

Would you mind posting the hex of the signed raw transaction?

I was just looking in script.spp, and this error is caused by an incorrect length. When you attach your hashtype, are you changing the total length?

0x30 0x02 0x02

~~Code:~~

0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb5000000006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f0100000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000

~~why would i change the length, are bitcoin in the business of messing with other people's standard?~~

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Re: New Attack Vector

July 17, 2013, 09:05:18 AM

#30

Quote from: kjj on July 17, 2013, 09:00:25 AM
Quote from: piotr_n on July 17, 2013, 08:50:47 AM
there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:
Code:
0x30 0x02 0x02

it is taken using this expression:
Code:
unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

This distinction is only meaningful when the signature is not canonical. When the signature is in the proper form, the last bye is the last byte.

Quote from: piotr_n on July 17, 2013, 08:50:47 AM
and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2

I'm having a hard time understan what you are talking about here. The SIGHASH values apply to signatures. The txout being redeemed has no bearing on them.

Check this - it's a real signature from tx 67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2:

Code:
3045022052538ceefdadef44696559b5b135e48218403f10120bcf592825b924af804821022100ed30a2a2218ad85438fd6a38f909b5ac55bc322033b63ddf17b3b9db11cd61800001

Following the format, the hashtype should be 00, while in fact it is 01.

kjj

legendary

Activity: 1302

Merit: 1026

Re: New Attack Vector

July 17, 2013, 09:00:25 AM

#29

Quote from: piotr_n on July 17, 2013, 08:50:47 AM
there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:
Code:
0x30 0x02 0x02

it is taken using this expression:
Code:
unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

This distinction is only meaningful when the signature is not canonical. When the signature is in the proper form, the last bye is the last byte.

Quote from: piotr_n on July 17, 2013, 08:50:47 AM
and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2

I'm having a hard time understanding what you are talking about here. The SIGHASH values apply to signatures. The txout being redeemed has no bearing on them.

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Re: New Attack Vector

July 17, 2013, 08:50:47 AM

#28

there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:
Code:
0x30 0x02 0x02

it is taken using this expression:
Code:
unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2

kjj

legendary

Activity: 1302

Merit: 1026

Re: New Attack Vector

July 17, 2013, 08:43:47 AM

#27

Would you mind posting the hex of the signed raw transaction?

I was just looking in script.spp, and this error is caused by an incorrect length. When you attach your hashtype, are you changing the total length?

0x30 0x02 0x02

kokjo

legendary

Activity: 1050

Merit: 1000

You are WRONG!

Re: New Attack Vector

July 17, 2013, 08:23:16 AM

#26

Quote from: kjj on July 17, 2013, 08:18:50 AM
What's funny is that this very thread explains why non-canonical signatures are bad, and why we stopped accepting them.

Just out of curiosity, is openssl giving you a padded signature under normal circumstances, or are you going out of your way to make it give you garbage?
nope not at all, i give it the key(generated by the satoshi client, btw) and the transaction hash, it gives me the signature and i append hashtype.

blockchain.info accepts but bitcoind rejects.

you people should really stop implementing features, and sit down create a standard and start fix bitcoin instead.

kokjo

legendary

Activity: 1050

Merit: 1000

You are WRONG!

Re: New Attack Vector

July 17, 2013, 08:19:37 AM

#25

blockchain.info accepts my transaction vis pushtx, but bitcoind does not find it aesthetically pleasing enough.

if bitcoin fails, the blame goes to the developers for not having a standard to implement, but making shit up as you go along.

kjj

legendary

Activity: 1302

Merit: 1026

Re: New Attack Vector

July 17, 2013, 08:18:50 AM

#24

Quote from: kokjo on July 17, 2013, 08:03:28 AM
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

What's funny is that this very thread explains why non-canonical signatures are bad, and why we stopped accepting them.

Just out of curiosity, is openssl giving you a padded signature under normal circumstances, or are you going out of your way to make it give you garbage?

kokjo

legendary

Activity: 1050

Merit: 1000

You are WRONG!

Re: New Attack Vector

July 17, 2013, 08:03:28 AM

#23

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

gmaxwell

staff

Activity: 4284

Merit: 8808

Re: New Attack Vector

October 04, 2012, 11:43:44 PM

#22

Quote from: ByteCoin on October 04, 2012, 09:40:39 PM
Now that this is well known, I have to point out the following:

Transaction malleability has been known and discussed many times— including padding and other encoding differences. Is there some reason that you believe the s-flip to have distinct implications from all of the other signature encoding differences?

The understood risk of this in prior discussions has primarily been that troublemakers could create confusion by changing the transaction ID of confirmed transactions to be something different than the transaction participants were expecting (so, e.g. they'd see two transactions doing the same thing, one which never confirms). There is a secondary risk that parasites could 'hijack' other people's transaction to pay the way to embed data in the blockchain for them.

Quote
I believe the originator wouldn't recognise the flipped transaction has spent his coins.

In the reference client the spent-ness of candidate inputs when drafting a transaction are checked with IsSpent(), the txid of the spending transaction should be irrelevant. Can you elaborate on what you're thinking here?

ByteCoin

sr. member

Activity: 416

Merit: 277

Re: New Attack Vector

October 04, 2012, 09:40:39 PM

#21

Quote from: Sergio_Demian_Lerner on October 04, 2012, 04:26:46 PM
For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.
Now that this is well known, I have to point out the following:

If some subset of clients rebroadcast transactions while flipping the sign of s then the transactions have different ids (because currently the signatures are included when hashing to find the transaction ID) and there may be some problems if the flipped version makes it into the block instead of the vanilla version as I believe the originator wouldn't recognise the flipped transaction has spent his coins.

ByteCoin

Sergio_Demian_Lerner

hero member

Activity: 555

Merit: 654

Re: New Attack Vector

October 04, 2012, 04:26:46 PM

#20

For the record, there is another possibility of signature malleability.

For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.

Sergio_Demian_Lerner

hero member

Activity: 555

Merit: 654

Re: New Attack Vector

August 22, 2012, 10:31:44 AM

#19

Thank you Sipa and Gavin, I'll keep researching on this..

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

Re: New Attack Vector

August 22, 2012, 09:22:50 AM

#18

Making transactions with non-DER-encoded (aka BER encoded) signatures non-standard has been on my TODO list for over a year now, but has never been the highest priority. That's the first step to making non-DER-encoded signatures completely illegal.

Note that if there is a core-dumping bug in OpenSSL's decoding code then it needs to get fixed in OpenSSL. Writing a BER decoder just for Bitcoin is a bad idea, it is much more likely our new code would have a crashing bug.

Pieter Wuille

legendary

Activity: 1072

Merit: 1181

Re: New Attack Vector

August 22, 2012, 09:21:31 AM

#17

Quote from: Sergio_Demian_Lerner on August 22, 2012, 08:46:33 AM
I'm re-investigating this past problem because I think there are some other possibilities for this attack vector.

Did Sipa implemented a patch back on MAY 2011 to check the uniqueness and correctness of signatures?

I don't see a IsValidSig() method in the source code.

Bet regards, Sergio.

No, this was never fixed. Doing it now would at first making transactions which use non-standard but valid encodings non-standard, and then fixing a policy for a transition point after which it becomes illegal.

Sergio_Demian_Lerner

hero member

Activity: 555

Merit: 654

Re: New Attack Vector

August 22, 2012, 08:46:33 AM

#16

I'm re-investigating this past problem because I think there are some other possibilities for this attack vector.

Did Sipa implemented a patch back on MAY 2011 to check the uniqueness and correctness of signatures?

I don't see a IsValidSig() method in the source code.

Bet regards, Sergio.

Enochian

full member

Activity: 327

Merit: 124

Re: New Attack Vector

May 18, 2011, 11:30:49 AM

#15

Quote from: Pieter Wuille on May 18, 2011, 11:09:28 AM
I don't like the idea of openssl segfaulting on garbage data.

Is there an easy way for checking (by looking at the bytes ourselves, not by passing it to openssl and request to encode it again) that the input is a valid DER-encoded signature?

Well, you know a valid bitcoin signature (r,s) is going to look like

<30><02><02><01>

where the r and s values are non-negative, and don't exceed 33 bytes including a possible padding zero byte.

One way to check would be to just create a little function

bool IsValidSig(char *sig, int siglen)

Containing an appropriate stack of if statements.