[Build] Further security and symbol checking updates #2896
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of the ever-messier text parsing of the output of the readelf tool (which is clearly meant for human consumption not to be machine parseable), parse the ELF binaries directly. Add a small dependency-less ELF parser specific to the checks. This is slightly more secure, too, because it removes potential ambiguity due to misparsing and changes in the output format of `elfread`. It also allows for stricter and more specific ELF format checks in the future. This removes the build-time dependency for `readelf`.
I misunderstood the ELF specification for version symbols (verneed): The `vn_aux` pointer is relative to the main verneed record, not the start of the section. This caused many symbols to not be versioned properly in the return value of `elf.dyn_symbols`. This was discovered in bitcoin#21454. Fix it by correcting the offset computation.
xkb versions symbols (using the prefix `V`), as this library is used by bitcoin-qt, add it to the valid versions in `symbol-check.py`.
…bol-check.py The (ancient) versions specified here were deceptive. Entries older than MAX_VERSIONS['GLIBC'], which is 2.27, are ignored here. So reorganize the code to avoid confusion for other people reading this code.
ASLR is not currently working for the pivx-cli.exe binary. This is due to it not having a .reloc section, which is stripped by default by the mingw-w64 ld we use for gitian builds. A good summary of issues with ld and mingw-w64 is available in this thread: https://sourceware.org/bugzilla/show_bug.cgi?id=19011. All other Windows binaries that we distribute (pivxd, pivx-qt, pivx-tx and test_pivx) do not suffer this issue, and currently having working ASLR. This is due to them exporting (inadvertent or not) libsecp256k1 symbols, and, as a result, the .reloc section is not stripped by ld. This change is a temporary workaround, also the same one described here: https://www.kb.cert.org/vuls/id/307144/, that causes main() to be exported. Exporting a symbol will mean that the .reloc section is not stripped, and ASLR will function correctly.
Fuzzbawls
changed the title
Liquid369
approved these changes
Feb 6, 2024
Duddino
approved these changes
Feb 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While prepping for the upcoming release, I noticed some errors with gitian builds involving the security/symbol checking that gitian runs during it's build process.
This PR brings in further upstream updates to these scripts, as well as a windows-specific issue with the
pivx-cli.exebinary. During testing of this PR, I also noticed a Github Actions issue with the most recent macos-11 runner image version.Included here are either full or partial backports/cherry picks from the following upstream PRs: