This is an archive of the discontinued LLVM Phabricator instance.

[scudo] Add extra information when a header is corrupted.
AbandonedPublic

Authored by cferris on Jun 14 2023, 6:00 PM.

Details

Reviewers
Chia-hungDuan
Summary

When a header checksum doesn't match, it would be good to see the
two checksums to get an idea of how corrupted the header might
have become.

Diff Detail

Event Timeline

cferris created this revision.Jun 14 2023, 6:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 14 2023, 6:00 PM
cferris requested review of this revision.Jun 14 2023, 6:00 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 14 2023, 6:00 PM
Herald added a subscriber: Restricted Project. · View Herald Transcript
cferris updated this revision to Diff 531585.Jun 14 2023, 6:02 PM

Fix typo in report.h

Chia-hungDuan accepted this revision.Jun 14 2023, 6:30 PM

This is nice!

This revision is now accepted and ready to land.Jun 14 2023, 6:30 PM

To be fair, at this point, the process should be dead and the Cookie should no longer be relevant, but from a security perspective, I would be warry about echo'ing back the expected checksum.
I understand the rationale behind, but I could think about some circumstances (forked process, VM snapshots, etc), where that information could potentially be reused to craft a correct header.
It obviously would require the attacker to get their hands on the logs first.

Overall it might not be super realistic, but leaving that here for you to judge.

To be fair, at this point, the process should be dead and the Cookie should no longer be relevant, but from a security perspective, I would be warry about echo'ing back the expected checksum.
I understand the rationale behind, but I could think about some circumstances (forked process, VM snapshots, etc), where that information could potentially be reused to craft a correct header.
It obviously would require the attacker to get their hands on the logs first.

Overall it might not be super realistic, but leaving that here for you to judge.

This is a good point! I thought the process is dead and didn't think about the cases you mentioned. That does something should be evaluated as well.

This is a tough one. We are already seeing cases where this extra information would really help. I'm torn because on a normal Android build you can't see the log. However, you could get a beta version and see the log. On the other hand, I think there are devices where you could probably rebuild the platform and have total control. This could definitely make things a little easier to do an attack that modifies the header and then check to see how close you are.

I'll let this sit for a bit and think about if there is a different way to get this kind of information without giving away too much about the header checksum.

The intent was to try and figure out whether the header was completely corrupted or it might be a bit flip. But it's not clear if that information could be actionable, so I'm just going to remove this change.

cferris abandoned this revision.Jun 15 2023, 6:49 PM