Re:Third High Severity CVE in Log4j Is Published
by junon on Saturday December 18, 2021 @06:10PM
(#29609593)
Please re-read my original comment. If the binary is stripped, no internal symbols would have been visible or even present in the file to be scanned. The jumps between subroutines happen directly, without a symbol jump table (because a jump table adds runtime overhead and is largely unnecessary, especially in statically linked executables).
[ Parent
| on HN ]
Re:Third High Severity CVE in Log4j Is Published
by ncmncm on Saturday December 18, 2021 @06:13PM
(#29609624)
You do not need internal symbols.
All the public entry points are spelled out exactly by name, and all the external symbol dependencies.
Re:Third High Severity CVE in Log4j Is Published
by junon on Saturday December 18, 2021 @06:30PM
(#29609762)
I addressed the point about symbol tables, and that's assuming the vulnerable code was pulled in via an external dependency or exported directly (flat function/subroutine) from an .SO.
That also assumes that the binary wasn't linked statically - in which case, there are no external symbols to even look for.
Lastly, please stop calling someone educating you "BS".
[dead]
Re:Third High Severity CVE in Log4j Is Published
by junon on Saturday December 18, 2021 @06:54PM
(#29609947)
Symbol table patching doesn't do anything if the functionality is internal... Do you know how programs are linked?
Re:Third High Severity CVE in Log4j Is Published
by nitrogen on Saturday December 18, 2021 @07:18PM
(#29610112)
We're all on the same team here, there's no need for this hostility back and forth.
Binary patching, JAR patching, disassembly, library interception, syscall interception, whatever, these are all tools that are on the table. You do what it takes to get the job done, knowing and weighing the pros and cons.
[dead]