fix(nssa): audit 91 issue fix

[jonesmarvin8]

🎯 Purpose

The purpose of this PR is to address the security vulnerability highlighted in audit-issue 91. Specifically, a pair of malicious programs can be used to drain a victim's account; P1 injects a victim's account (and authorization) in a chained-call, P2 uses victim's account (with authorization) to call auth-transfer with victim's account as the sender. The fix ensures that a chained call can only propagate authorization that the caller's own program_output.pre_states already carry, never elevate beyond what the caller was authorized for.

⚙️ Approach

[X] - Updates authorized_accounts (in validate_state_diff.rs, line 268) to to get pre_states from program_output (validated by circuit logic) rather than unvalidated chained_call.
[X] - Add pair of test-program-methods: malicious_injector and malicious_launderer.
[X] - Add test to validate_state_diff using the malicious programs demonstrating the vulnerability has been patched.

🧪 How to Test

Run tests malicious_programs_cannot_drain_victim_without_signature and privacy_malicious_programs_cannot_drain_public_victim

• The test passes provided the victim's balance is unaffected by the execution.

🔗 Dependencies

N/A

🔜 Future Work

N/A

📋 PR Completion Checklist

• Complete PR description
• Implement the core functionality
• Add/update tests
• Add/update documentation and inline comments

[schouhy]

thanks very cool. Are private txs safe? Can we add a test that checks there's no vulnerability in a private transaction too?

[jonesmarvin8]

thanks very cool. Are private txs safe? Can we add a test that checks there's no vulnerability in a private transaction too?

The privacy txs are safe from this attack against public accounts. The individual inner proofs for each chained call proofs are generated, but the outer proof is rejected by the validator. I've added a similar test for privacy transaction using the malicious programms.

[schouhy]

LGTM thanks!

[Pravdyvy]

lgtm

[moudyellaz]

lgtm, left some comments. Thanks for the fix again

[moudyellaz]

One tiny writeup ask, totally optional. Could you add a sentence to the PR description or commit body spelling out the invariant the fix locks in? Something like "a chained call can only propagate authorization that the caller's own program_output.pre_states already carry, never elevate beyond what the caller was authorized for." It would save the next person who looks at this from having to re-derive the property from the diff. Really nice fix overall, thanks for taking this on.