On Пан, 24 чэр 2024, Gordon Messmer wrote:
Now that I've packaged the GEF gdb extension (package "gdb-gef" in
Rawhide) which provides the "got-audit" command, I wanted to ask again
whether there's interest in monitoring critical packages for signs of
GOT tampering.
The "got-audit" gdb command examines a running process to print a list
of symbols, and the file backing the area of memory where each symbol
points. For example:
accept@GLIBC_2.2.5 : /usr/lib64/libc.so.6
access@GLIBC_2.2.5 : /usr/lib64/libc.so.6
AES_encrypt@OPENSSL_3.0.0 : /usr/lib64/libcrypto.so.3
AES_set_encrypt_key@OPENSSL_3.0.0 : /usr/lib64/libcrypto.so.3
...
EVP_PKEY_set1_RSA@OPENSSL_3.0.0 : /usr/lib64/liblzma.so.5 ::
ERROR EVP_PKEY_set1_RSA not exported by /usr/lib64/liblzma.so.5
In addition to printing the mapping, the command will print an error
if it determines that two libraries are both exporting a matching
symbol (e.g., if EVP_PKEY_set1_RSA appeared in libcrypto.so and in
liblzma.so), and it will print an error if it determines that a symbol
has been resolved to a file that doesn't export that symbol (e.g., if
EVP_PKEY_set1_RSA points to liblzma.so, but liblzma.so doesn't export
a symbol of that name).
In the case of the xz-utils attack, the got-audit command would have
logged an error due to the latter check, as illustrated above.
(As a topic for later: the tirpc library exports functions with the
same name as functions that appear in libc, so the behavior of
erroring on duplicate symbols needs to be rationalized. Maybe an
exemption for libtirpc.so? Are there other libraries that do this?)
Most of alternative memory allocation libraries provide their own
free/malloc replacements to be used with LD_PRELOAD, e.g. jemalloc.
I have a proof-of-concept test implemented for the openssh package, in
this pull request:
https://src.fedoraproject.org/rpms/openssh/pull-request/73
If we are interested in building out protection from this class of
attack, there are a number of questions I have about the best way to
do that:
The current implementation compares the result to an expected result.
While I like the idea of keeping historical records, I'm not sure I
can justify the developer overhead of updating the expected result
file as it evolves due to updates in the program and in the libraries
it uses. It would be simpler to simply watch for errors in the
output.
If we only watch for errors in the output, it would be much easier to
convert this into a generic test and run it against more daemons.
The proof-of-concept only audits symbols in the binary, but shared
objects have their own set of dynamic symbols loaded from shared
libraries. The output is quite large if we log the full set, and more
importantly it will change much more often, but if we only look for
errors, we can use "got-audit --all" to also watch symbol resolution
within the shared objects.
But it's probably important to mention that if we only watch for
errors in the output, the test could very easily invisibly break. If
it stopped working properly and printed nothing, we might go on
thinking that we had mitigations in place when the test had actually
become a NOP.
Is this work interesting? Should I continue working on it?
Yes, it is definitely an interesting test. Thank you for investing your
time and resources into this.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
