Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible malleability attack on tx encrypted sections #1567

Closed
grarco opened this issue Jun 14, 2023 · 3 comments
Closed

Possible malleability attack on tx encrypted sections #1567

grarco opened this issue Jun 14, 2023 · 3 comments
Assignees
Labels

Comments

@grarco
Copy link
Collaborator

grarco commented Jun 14, 2023

About the commitment of the header to the sections. There are only the hashes of the code and data section in the header and other commitments are placed in the Data section if needed. This looks good but there might be room for an attack on the encrypted sections.

Fees are paid when the entire tx is included in the block: in the following block we decrypt the sections and do validation. If this validation fails we can avoid executing the transaction but the problem is that the wrapper’s signer has already paid the fees, suffering an economic damage.

@murisi
Copy link
Collaborator

murisi commented Jun 21, 2023

Agreed that the encrypted section can be modified by an attacker, and that this would be discovered too late. I believe this issue also applies to all other section types. For example, the ExtraData of a transaction is only fetched/validated during transaction WASM code execution (only occurring after decryption is complete). So if an attacker were to remove such a section, the wrapper fees would be taken before transaction tampering is detected. No?

@grarco
Copy link
Collaborator Author

grarco commented Jun 21, 2023

Yes, I think this issue applies to all of the sections that are included in transaction. If I recall correctly what you explained me, we "encrypt" all of the sections except for the signature on the Header. Except for this signature, I think all of the other sections need a commitment in the header to prevent tampering. Note that this doesn't have anything to do with the encryption per se, we'd need the commitment even if all of the sections were in plaintext.

In short, we just need a way to verify that the payload (sections) of a transaction is the intended one

@cwgoes
Copy link
Collaborator

cwgoes commented Jul 6, 2023

MERGED 🚀

@cwgoes cwgoes closed this as completed Jul 6, 2023
@murisi murisi mentioned this issue Sep 28, 2023
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants