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.
Details
- Reviewers
Chia-hungDuan
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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.