Malformed contractspecv0 in the conctract deployed on Testnet

[orbitlens]

Some time ago a weird contract WASM has been uploaded to Testnet. The included contract spec (contractspecv0) is malformed (or maybe there is an XDR version mismatch, build for the futurenet) -- I couldn't parse it with the latest JS Stellar SDK. It throws "attempt to read outside the boundary of the buffer" exception.

I wonder whether Stellar Core performs contract spec consistency checks on WASM upload (it should in theory). It's the only contract across Testnet and Pubnet with malformed metadata.

Transaction: https://stellar.expert/explorer/testnet/tx/bda62fd2cc6fb1c2ece0b77b312e8ce13b514bccdea506a1514a0babc5adedc5
WASM hash:
fb42e0ca34f78b1088f1f2b72f479765f584fff9b835b385d1071612c0d1e360
WASM code itself:
AGFzbQEAAAAAHhFjb250cmFjdGVudm1ldGF2MAAAAAAAAAAXAAAAAAB7DmNvbnRyYWN0bWV0YXYwAAAAAAAAAARuYW1lAAAACnNtb2tlLXRlc3QAAAAAAAAAAAAHdmVyc2lvbgAAAAAFMC4xLjAAAAAAAAAAAAAAC2Rlc2NyaXB0aW9uAAAAABtvZmZsaW5lIHNtb2tlLXRlc3QgY29udHJhY3QAAN8BDmNvbnRyYWN0c3BlY3YwAAAAAQAAAAAAAAA4SW5jcmVtZW50IHRoZSBpbnRlcm5hbCBjb3VudGVyIGFuZCByZXR1cm4gdGhlIG5ldyB2YWx1ZS4AAAAJaW5jcmVtZW50AAAAAAAAAQAAAA1hbW91bnQgdG8gYWRkAAAAAAAABHN0ZXAAAAAEAAAAAQAAAAQAAAAAAAAAD0dyZWV0IGEgY2FsbGVyLgAAAAAFaGVsbG8AAAAAAAACAAAAAAAAAAJ0bwAAAAAAEwAAAAAAAAAEbmFtZQAAABAAAAABAAAAEA==

I don't think it's directly exploitable, but may affect contracts discovery. So it would be nice to make sure that StellarCore validates the metadata spec.

[leighmcculloch]

Decode of the custom sections in that file to understand what it contains. Looks like an additional 8 bytes on the end that don't make up a complete ScSpecEntry, as if it was truncated for some reason.

$ echo 'AGFzbQEAAAAAHhFjb250cmFjdGVudm1ldGF2MAAAAAAAAAAXAAAAAAB7DmNvbnRyYWN0bWV0YXYwAAAAAAAAAARuYW1lAAAACnNtb2tlLXRlc3QAAAAAAAAAAAAHdmVyc2lvbgAAAAAFMC4xLjAAAAAAAAAAAAAAC2Rlc2NyaXB0aW9uAAAAABtvZmZsaW5lIHNtb2tlLXRlc3QgY29udHJhY3QAAN8BDmNvbnRyYWN0c3BlY3YwAAAAAQAAAAAAAAA4SW5jcmVtZW50IHRoZSBpbnRlcm5hbCBjb3VudGVyIGFuZCByZXR1cm4gdGhlIG5ldyB2YWx1ZS4AAAAJaW5jcmVtZW50AAAAAAAAAQAAAA1hbW91bnQgdG8gYWRkAAAAAAAABHN0ZXAAAAAEAAAAAQAAAAQAAAAAAAAAD0dyZWV0IGEgY2FsbGVyLgAAAAAFaGVsbG8AAAAAAAACAAAAAAAAAAJ0bwAAAAAAEwAAAAAAAAAEbmFtZQAAABAAAAABAAAAEA==' | base64 -d > c.wasm
$ wasm-cs --version
wasm-cs 1.0.0
$ stellar-xdr version
stellar-xdr 28.0.0 (d0f1330e43c3a2c0c616da30698b24140d4eea72)
xdr: 9c9c145953e80990d6ff1ae3a6a973a0ce6d0694
features: <none>
$ wasm-cs c.wasm ls
contractenvmetav0 (12 bytes)
contractmetav0 (108 bytes)
contractspecv0 (208 bytes)
$ wasm-cs c.wasm read contractenvmetav0 -f binary | stellar-xdr decode --type ScEnvMetaEntry --input stream
{"sc_env_meta_kind_interface_version":{"protocol":23,"pre_release":0}}
$ wasm-cs c.wasm read contractmetav0 -f binary | stellar-xdr decode --type ScMetaEntry --input stream
{"sc_meta_v0":{"key":"name","val":"smoke-test"}}
{"sc_meta_v0":{"key":"version","val":"0.1.0"}}
{"sc_meta_v0":{"key":"description","val":"offline smoke-test contract"}}
$ wasm-cs c.wasm read contractspecv0 -f binary | stellar-xdr decode --type ScSpecEntry --input stream
{"udt_struct_v0":{"doc":"","lib":"Increment the internal counter and return the new value.","name":"increment","fields":[{"doc":"amount to add","name":"step","type":"u32"}]}}
{"udt_struct_v0":{"doc":"\\0\\0\\0\\0","lib":"Greet a caller.","name":"hello","fields":[{"doc":"","name":"to","type":"address"},{"doc":"","name":"name","type":"string"}]}}
error: error decoding XDR: failed to fill whole buffer
$ wasm-cs c.wasm read contractspecv0
Length: 208 (0xd0) bytes
0000:   00 00 00 01  00 00 00 00  00 00 00 38  49 6e 63 72   ...........8Incr
0010:   65 6d 65 6e  74 20 74 68  65 20 69 6e  74 65 72 6e   ement the intern
0020:   61 6c 20 63  6f 75 6e 74  65 72 20 61  6e 64 20 72   al counter and r
0030:   65 74 75 72  6e 20 74 68  65 20 6e 65  77 20 76 61   eturn the new va
0040:   6c 75 65 2e  00 00 00 09  69 6e 63 72  65 6d 65 6e   lue.....incremen
0050:   74 00 00 00  00 00 00 01  00 00 00 0d  61 6d 6f 75   t...........amou
0060:   6e 74 20 74  6f 20 61 64  64 00 00 00  00 00 00 04   nt to add.......
0070:   73 74 65 70  00 00 00 04  00 00 00 01  00 00 00 04   step............
0080:   00 00 00 00  00 00 00 0f  47 72 65 65  74 20 61 20   ........Greet a
0090:   63 61 6c 6c  65 72 2e 00  00 00 00 05  68 65 6c 6c   caller......hell
00a0:   6f 00 00 00  00 00 00 02  00 00 00 00  00 00 00 02   o...............
00b0:   74 6f 00 00  00 00 00 13  00 00 00 00  00 00 00 04   to..............
00c0:   6e 61 6d 65  00 00 00 10  00 00 00 01  00 00 00 10   name............

[leighmcculloch]

I wonder whether Stellar Core performs contract spec consistency checks on WASM upload

Soroban Env only checks the contents of contractenvmetav0 as that is the only custom section that is part of the protocol.

Stellar Core and the Soroban Env don't check the contractspecv0 and contractmetav0 custom sections because the specs are tied pretty closely to the Rust Soroban SDK, which is not part of the protocol, and by not being part of the protocol they can eventually be innovated on independent of nodes.

maybe there is an XDR version mismatch, build for the futurenet

I don't think that is what's happened here. It's not possible to upload contracts to testnet or mainnet that are built for a future protocol version released on futurenet because the soroban-sdk embeds the protocol version of the env it was built against into the contractenvmetav0 custom section and the Soroban Env checks it is less than or equal to the current protocol version.

Based on looking at #2007 (comment), it seems like the data was truncated for some reason.