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

Bug Fix: Catch further encoding exception when verifying message #228

Closed
wants to merge 2 commits into from

Conversation

Boslx
Copy link

@Boslx Boslx commented Jun 6, 2024

When fuzzing with additional seeds, I noticed that vanetza::security::v3::SecuredMessage::signing_payload can throw an exception. For this reason, I assume that vanetza::asn1::encode_oer should never be called without proper exception handling. I have added further exception handlings in this pull request.

try {
encoded_signing_payload = msg.signing_payload();
} catch (...) {
confirm.report = VerificationReport::False_Signature;
Copy link
Owner

Choose a reason for hiding this comment

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

Maybe we should add a more descriptive report value, e.g. Corrupt_Message or Encoding_Failure?

Copy link
Author

@Boslx Boslx Jun 7, 2024

Choose a reason for hiding this comment

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

Corrupt_Message sounds good, I can do that. I have seen that in security::DelegatingSecurityEntity::decapsulate_packet:39, VerificationReport from the verify services is cast to DecapReport from SN-Decaps. Is it intentional that Unencrypted_Message and Decryption_Error are not included in VerificationReport? Decryption_Error is maybe another good candidate.

Unfortunately, I haven't found anything about this, but is it perhaps possible with asn1c to extract the indices and length of certain elements in the bytes to decode? That way, we could skip the entire encode step.

Copy link
Owner

Choose a reason for hiding this comment

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

Good catch regarding the report casting. For the sake of robustness, this cast should be replaced by a proper mapping function.

I am not aware of any smart way to get the length of asn1c data structures without actually calling the encoder. You can call the encoding stage with a "null sink" though, i.e. no actual bytes are written only the "written bytes" are tracked.

Copy link
Author

Choose a reason for hiding this comment

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

I have annotated the enums with values according to AUTOSAR SWS_V2xM_91000 so that the cast at least remains consistent. I hope it's okay that I added the None enum according to the AUTOSAR specification.

@Boslx Boslx closed this Sep 2, 2024
riebl added a commit that referenced this pull request Oct 21, 2024
Among others, this change avoids misalignments between VerificationReport
and DecapReport as pointed out by #228
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants