4 ms·

Rewriting libc will change it's hash each time, which flies in the face of reproducible binaries. It seems like a messy hack and that there should be a more ele

by kardos 11y ago

Rewriting libc will change it's hash each time, which flies in the face of reproducible binaries. It seems like a messy hack and that there should be a more elegant way to achieve the same result without rewriting important libraries. Is it possible to reorder the symbols on the fly as the library is loaded?

RubyPinch 11y ago
just check the submodules, no? reproducible binaries doesn't really matter that much when you are compiling from source (you arn't proving that someone did or did not tamper with the binary provided, if no one is providing that binary in that situation)
csense 11y ago
With respect to reproducible builds, you could define a hash function which has deliberate collisions for binaries which are semantically equivalent. In this case, what you would do is sort the symbols to produce a new binary, then run the binary with sorted symbols through sha256. So you're no longer asking if your binary is byte-for-byte equal to someone else's binary, you're asking if your binary is byte-for-byte equal if their symbols were sorted. It complicates matters because you now have to do this custom reordering step before you hash (which means you can no longer do it easily with sha256sum or the type of program you might write in CS 101 that compares files byte-for-byte, you have to have trusted code which gets into the guts of the ELF format and reorder the symbols which increases the complexity and attack surface for reproducible binaries.)
- kardos 11y ago
  Yeah, you could make a smart symbol sorting hash program, increasing complexity. Now it's a hack on top of a hack. This rewriting also complicates mounting your libraries as read-only (ie, immutable system). If it's worth doing, surely the rest of the libraries would benefit as well. From a performance standpoint, it's pretty quick for libc, how slow will it be to do this for all libraries? We have ASLR; is there a fundamental reason why ASLR can't be modified/extended/repurposed to achieve the same goal?

by kardos 11y ago

RubyPinch 11y ago

just check the submodules, no? reproducible binaries doesn't really matter that much when you are compiling from source (you arn't proving that someone did or did not tamper with the binary provided, if no one is providing that binary in that situation)

csense 11y ago

With respect to reproducible builds, you could define a hash function which has deliberate collisions for binaries which are semantically equivalent. In this case, what you would do is sort the symbols to produce a new binary, then run the binary with sorted symbols through sha256. So you're no longer asking if your binary is byte-for-byte equal to someone else's binary, you're asking if your binary is byte-for-byte equal if their symbols were sorted. It complicates matters because you now have to do this custom reordering step before you hash (which means you can no longer do it easily with sha256sum or the type of program you might write in CS 101 that compares files byte-for-byte, you have to have trusted code which gets into the guts of the ELF format and reorder the symbols which increases the complexity and attack surface for reproducible binaries.)

kardos 11y ago
Yeah, you could make a smart symbol sorting hash program, increasing complexity. Now it's a hack on top of a hack. This rewriting also complicates mounting your libraries as read-only (ie, immutable system). If it's worth doing, surely the rest of the libraries would benefit as well. From a performance standpoint, it's pretty quick for libc, how slow will it be to do this for all libraries? We have ASLR; is there a fundamental reason why ASLR can't be modified/extended/repurposed to achieve the same goal?