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

Test malleability attacks #3925

Open
wants to merge 10 commits into
base: main
Choose a base branch
from
Open

Conversation

grarco
Copy link
Contributor

@grarco grarco commented Oct 16, 2024

Describe your changes

  • Adds property tests for malleability attacks on transactions
  • Improves test_wrapper_unknown_address
  • Removes old references to encrypted/decrypted txs

Checklist before merging

  • If this PR has some consensus breaking changes, I added the corresponding breaking:: labels
    • This will require 2 reviewers to approve the changes
  • If this PR requires changes to the docs or specs, a corresponding PR is opened in the namada-docs repo
    • Relevant PR if applies:
  • If this PR affects services such as namada-indexer or namada-masp-indexer, a corresponding PR is opened in that repo
    • Relevant PR if applies:

@grarco grarco force-pushed the grarco/test-malleability-attacks branch from d4e741b to 39972d5 Compare October 18, 2024 17:09
@grarco grarco marked this pull request as ready for review October 18, 2024 17:09
@grarco grarco added the testing label Oct 18, 2024
Copy link

codecov bot commented Oct 18, 2024

Codecov Report

Attention: Patch coverage is 95.58824% with 6 lines in your changes missing coverage. Please review.

Project coverage is 73.36%. Comparing base (a98a2ec) to head (39972d5).
Report is 17 commits behind head on main.

Files with missing lines Patch % Lines
crates/node/src/shell/process_proposal.rs 88.46% 6 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3925      +/-   ##
==========================================
+ Coverage   73.21%   73.36%   +0.15%     
==========================================
  Files         341      341              
  Lines      105280   105344      +64     
==========================================
+ Hits        77081    77289     +208     
+ Misses      28199    28055     -144     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

response.result.info,
expected_error
);
let mut runner = TestRunner::new(Config::default());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm doing this to avoid rerunning the setup for every iteration but I'm not completely familiar with the implications of instantiating a test runner over just calling protest!, in case I can switch to the latter

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why aren't you using the macros? I was a bit confused about the origin of TestRunner, I had never seen it being used manually

response.result.info,
expected_error
);
let mut runner = TestRunner::new(Config::default());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why aren't you using the macros? I was a bit confused about the origin of TestRunner, I had never seen it being used manually

Comment on lines +1777 to +1789
prop_compose! {
/// Generate an arbitrary signed inner tx that has been tampered with.
pub fn arb_tampered_inner_tx(signer: common::SecretKey)
(tx1 in arb_valid_signed_inner_tx(signer.clone()))(
tx2 in arb_valid_signed_inner_tx(signer.clone()),
mut tx in Just(tx1),
) -> Tx {
// TODO: tamper with the sections too once signature is updated
// Tamper with the header only for now
tx.header = tx2.header;
tx
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be interesting if we tampered with a tx section, particularly one that had meaningful tx data, such as a bond tx. the raw header hash would have changed, while the authorization stored in a section would have been for the previous hash

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants