-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Undefined behaviour in telfhash causes different results in big-endian machines. #1874
Labels
Comments
@HoundThe, FYI. |
Fixed in b2612f5 |
This issue was solved in https://github.com/trendmicro/tlsh in a different way. They simply changed the order of fields However, I think their solution is not general enough, as it only works if |
plusvic
added a commit
that referenced
this issue
Feb 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The test case below produces a different result in big-endian machines. Part of the issue was in the ELF module itself, but it was fixed in 32ae80d. However, after that fix I discovered another issue in the implementation of telfhash.
yara/tests/test-elf.c
Lines 263 to 270 in 32ae80d
The telfhash produced for that test case in big-endian machines is:
T174B021188204F00184540770331E0B111373086019509C464D0ACE88181266C09774FA
Notice that they are very similar, except for the third byte in the hash, where the nibbles are swapped:
The issue is related to this
union
yara/libyara/tlshc/tlsh_impl.h
Lines 63 to 71 in 32ae80d
Apparently the order of fields
q1ratio
andq2ratio
depend on the machine endianness, but the those fields are later read using the union'sqb
member, which causes a different value forqb
. This looks like telfhash is relying on undefined behaviour of the C compiler.Screenshots
If applicable, add screenshots to help explain your problem.
Please complete the following information:
The text was updated successfully, but these errors were encountered: