I have been investigating a class of potential vulnerabilites which involve building custom non-standard transactions with extra outputs containing malicious asset scriptPubKeys ==>
How to Sell Your Owner Admin Token and Keep It Too
note: all addresses refer to testnet6 using client develop2. Non-standard transactions were generated using custom-written scripts. quant3 and quant4 refer to two raven-qt clients in different VMs
Step 1) Generate and send a custom-built "issue asset" transaction with an extra output to piggy-back creation of a 2nd twin admin/owner token to a different address
Transaction ID#
99c165b966485c3485570027c5e5e458a33c765d50710a9150eea6682d283bd1
Illegal transaction creating assets Q3_MANU_ANO_FOO_SN_DA qty=10 meta=6/yes/no/0 and owner Q3_MANU_ANO_FOO_SN_DA! created by quant3 on quant4's rcv_address-5
-illegal because it moved the usual outputs to outputs 3&4, and inserted on output 2 a "6f" creation of another owner token with the same name created by quant3 on a different quant4 rcv_address-6
HEX_TRANSACTION = "0200000001ce6a6d635510dc4d881c72348d7dcd0a936c3cf9684d8558983b8142244aa3c40000000049483045022100ea017d68d35a9ee1018a6a50a4274f157e905702401822678e2286fcfab4bef402207e4bf8969bc95931cf75b993db0f935a545d85b261687a1b48813d098f837b3101feffffff02001417c6680000001976a91434e5abfd26fe3748eb7c077da4ed6a8409ae012788ac00653ba40b0000001976a9149e189b8e83e8fcc3403cf85f31349d46b709810888ac85450000"
Client quant4 receives on SEND_TO_ASSET_ADDRESS5 = "n2y7a4bhrGeETBUumhyS7REXYjK1ezXUb3" (admin/control token + qty=10 assets)
Client quant4 receives on SEND_TO_ASSET_ADDRESS6 = "myYgf8w73RMz1tMjuH82vr6H7935YUGtY9" (twin admin/control token only)
screenshot: "Screenshot of testnet6 Asset Explorer for Q3_MANU_ANO_FOO_SN_DA 2018-10-04.png"
Step 2) Client quant4 sent one of two twin admin/owner tokens Q3_MANU_ANO_FOO_SN_DA!
It was sent by quant4 from address "n2y7a4bhrGeETBUumhyS7REXYjK1ezXUb3") to client quant3 at address mi65Cst6Jbf5BcFjkpddKCpwnJByQkghBu
transaction ID #796ca578e0ed760d523a08a791f4d95016c4928d7c351cba7840fed2ab552129
screenshot: "Screenshot-2 of testnet6 develop2 client transferring 1-of-2 identical owner tokens named Q3_MANU_ANO_FOO_SN_DA! 2018-10-04.png"
Step 3) Client quant4 can still reissue Q3_MANU_ANO_FOO_SN_DA! after transferring away 1of2 twin control tokens. Example shown doing reissue with add qty=3 and change units=7
transaction ID #3beacc729fbd38dd2483b749797f9c0dd2ca38bc6b69b806809c294ed6cc68d0
screenshot: "Screenshot 2018-10-04- Reissue Q3_MANU_ANO_FOO_SN_DA! on q4 after transferring away twin, add qty=3 n change units=7.png"
Step 4) Client quant3 can now also reissue Q3_MANU_ANO_FOO_SN_DA! after receiving the twin admin/control token. Example shown doing reissue with add qty=20 and change units=8
transaction ID #890ba156a3ef20b26b3161aae5f70044d2f46e54dc7fc919f1b45f4e08b8d7e0
screenshot: "Screenshot from 2018-10-04 Reissue Q3_MANU_ANO_FOO_SN_DA! on q3 after receiving twin, add qty=20 n change units=8.png"
So it IS definitely possible to generate multiple admin/control tokens for a given asset name, and they are all capable of modifying metadata and doing asset reissues.
PS- Is it possible to piggy-back actual asset creations at additional addresses in addition to duplicating the admin/control token? It's not really necessary since you can always reissue assets for yourself. But if you want to keep control while selling it for non-reissuable assets or you just want to generate assets at multiple addresses for some odd reason, then Sure- Why Not?
Duplicating Admin/Owner Tokens AND Assets At Multiple Addresses
Transaction ID#
51fe447f1835bf4f7ae69a9c7a47a32c77ca832419cdb3bda3cc60b46a097dd1
Illegal transaction creating assets Q3_MANU_ANO_FANO_SN_DA qty=10 meta=6/yes/no/0 and owner Q3_MANU_ANO_FANO_SN_DA! created by quant3 on quant4's rcv_address-2
-illegal because it moved the usual outputs to outputs 4&5, and also included on outputs 2&3 a "71" asset script creating 5 assets Q3_MANU_ANO_FANO_SN_DA qty=10 meta=6/yes/no/0 and a "6f" asset owner script Q3_MANU_ANO_FANO_SN_DA! created by quant3 on quant4's rcv_address-3
HEX_TRANSACTION = "0200000001f4ecf6bf88c3c134f37d675ead2b3ff899ca6afbdf10d1bf04791f69e1062317000000004948304502210099af05ad06195a1ac05701f118789ee03db3deeecb85fafc367c529e86cdea52022062c73e7b6094ce826d3206125d5f84d5dcefa0ac8df91d5d01f913d01e94a0c401feffffff0200653ba40b0000001976a914ff885f50c48b7059882f626475c8cab23bf4712288ac001417c6680000001976a914ed68710570581d88169ee48ef0a4029918293a9f88ac85450000"
Client quant4 receives on SEND_TO_ASSET_ADDRESS2 = "mv6riDGGuNEbem5DYE4w7KPtjB9Fzbqsca" (legitimate asset and control tokens)
Client quant4 receives on SEND_TO_ASSET_ADDRESS3 = "msrjE6AFarwwoR9Husn73zh97DfcA64Zvd" (free piggy-back asset and control tokens)
screenshot "Screenshot of testnet6 Asset Explorer for Q3_MANU_ANO_FANO_SN_DA 2018-10-04.png"
PPS- Is it possible to achieve the BIG PRIZE of free assets with different names? Can we add piggy-back outputs for type 6f owner token creation and type 71 new asset issues using different names and different target addresses in order to create piggy-back assets free of charge?
The jury is still out on this one. The easy things don't work, but there are a few things left to try. It's probably best to patch for protection.
In Transaction ID# 72532cad0a9ad788719bd1b40ef997327d4257fd5ec2d3ee74c84515a2f745e6, I tried to create piggy-back asset issue Q3_MANU_ANO_FANO_DN_DAB & Q3_MANU_ANO_FANO_DN_DAB! on address "mpALEvPgvNJDuV426SzjEuyohe9x5LtYtc" in parallel with legitimate asset issue Q3_MANU_ANO_FANO_DN_DA & Q3_MANU_ANO_FANO_DN_DA! on address "n3VT8ihzcNXHSVb5LoxWXneQ91hgRYdKL8"
The develop2 client recognized and properly handled the legitimate assets and control tokens as expected if the piggy-back outputs were not present.
The piggy-back asset token and control tokens were each recognized in various menus, but the operations I attempted showed an error "Failed to get asset metadata".
I tried a number of other odd transactions containing only type 71 or only type 6f with varied results. Since a non-owner asset transfer does not require the owner token, nor does transfer of an admin token require a non-admin token in the transaction, it may be possible to transfer in the missing item from another location in order to complete the pair. Either way, this is a 2-input transaction require double-signature, so I would have to add more code to my custom transaction building scripts before trying this.
It is probably better to patch the code to prevent these types of transactions, rather than me spending more time on this.
It is worth mentioning that in many ways these issues are similar to the recent bitcoin core bug CVE-2018-17144 which also utilized conflicting outputs in the same transaction impacting the same UTXO. This class of potential vulnerabilities is effectively an asset-related version specific to Ravencoin and could potentially also be used to do double asset transfers.
The security challenges for Ravencoin are also somewhat more difficult compared to bitcoin because miners may not be particularly concerned with reducing the value of RVN if they can steal sufficiently valuable assets, thus increasing the risk of attack by miners.
screenshots.zip
I have been investigating a class of potential vulnerabilites which involve building custom non-standard transactions with extra outputs containing malicious asset scriptPubKeys ==>
How to Sell Your Owner Admin Token and Keep It Too
note: all addresses refer to testnet6 using client develop2. Non-standard transactions were generated using custom-written scripts. quant3 and quant4 refer to two raven-qt clients in different VMs
Step 1) Generate and send a custom-built "issue asset" transaction with an extra output to piggy-back creation of a 2nd twin admin/owner token to a different address
Step 2) Client quant4 sent one of two twin admin/owner tokens Q3_MANU_ANO_FOO_SN_DA!
Step 3) Client quant4 can still reissue Q3_MANU_ANO_FOO_SN_DA! after transferring away 1of2 twin control tokens. Example shown doing reissue with add qty=3 and change units=7
Step 4) Client quant3 can now also reissue Q3_MANU_ANO_FOO_SN_DA! after receiving the twin admin/control token. Example shown doing reissue with add qty=20 and change units=8
So it IS definitely possible to generate multiple admin/control tokens for a given asset name, and they are all capable of modifying metadata and doing asset reissues.
PS- Is it possible to piggy-back actual asset creations at additional addresses in addition to duplicating the admin/control token? It's not really necessary since you can always reissue assets for yourself. But if you want to keep control while selling it for non-reissuable assets or you just want to generate assets at multiple addresses for some odd reason, then Sure- Why Not?
Duplicating Admin/Owner Tokens AND Assets At Multiple Addresses
PPS- Is it possible to achieve the BIG PRIZE of free assets with different names? Can we add piggy-back outputs for type 6f owner token creation and type 71 new asset issues using different names and different target addresses in order to create piggy-back assets free of charge?
The jury is still out on this one. The easy things don't work, but there are a few things left to try. It's probably best to patch for protection.
The develop2 client recognized and properly handled the legitimate assets and control tokens as expected if the piggy-back outputs were not present.
The piggy-back asset token and control tokens were each recognized in various menus, but the operations I attempted showed an error "Failed to get asset metadata".
I tried a number of other odd transactions containing only type 71 or only type 6f with varied results. Since a non-owner asset transfer does not require the owner token, nor does transfer of an admin token require a non-admin token in the transaction, it may be possible to transfer in the missing item from another location in order to complete the pair. Either way, this is a 2-input transaction require double-signature, so I would have to add more code to my custom transaction building scripts before trying this.
It is probably better to patch the code to prevent these types of transactions, rather than me spending more time on this.
It is worth mentioning that in many ways these issues are similar to the recent bitcoin core bug CVE-2018-17144 which also utilized conflicting outputs in the same transaction impacting the same UTXO. This class of potential vulnerabilities is effectively an asset-related version specific to Ravencoin and could potentially also be used to do double asset transfers.
The security challenges for Ravencoin are also somewhat more difficult compared to bitcoin because miners may not be particularly concerned with reducing the value of RVN if they can steal sufficiently valuable assets, thus increasing the risk of attack by miners.
screenshots.zip