3 ms·
This isn't how the real world works. Symbol patching is only effective if there's a symbol for it, which is often not the case (and probably wouldn't be the cas
by junon 5y ago
This isn't how the real world works. Symbol patching is only effective if there's a symbol for it, which is often not the case (and probably wouldn't be the case here) if the binary has been stripped[0].
> Just look at what game modders have accomplished without access to source code.
Game modding is usually done on Windows given the target market (up until recently of course) and thus usually means Windows PE's, which do not have debug symbols attached - ever. Windows debug symbol databases are emitted as PDB files and are almost always omitted from game releases.
This means modding has to do a sigscan[1] in most cases in order to find something interesting - especially in the case of ASLR[2]. Then whatever modding framework (or hack) can set itself up and hook into the game.
These techniques are NOT what we should be encouraging, and are certainly not common, even for vulnerability mitigation. Re-compilation and re-deployment should be the defacto mode of operation in production, especially for systems that have sensitive information. Relying on bin-patching is not something many security specialists would regard as a "good" mitigation.
[0] https://en.wikipedia.org/wiki/Strip_%28Unix%29 https://en.wikipedia.org/wiki/Strip_%28Unix%29
[1] https://wiki.alliedmods.net/Signature_Scanning https://wiki.alliedmods.net/Signature_Scanning
[2] https://en.wikipedia.org/wiki/Address_space_layout_randomization https://en.wikipedia.org/wiki/Address_space_layout_randomiza...
- ncmncm 5y agoThe original claims are garden-variety BS. Library .so files are not harder to scan than jar files. They just need different tools, which everyone has. And Java systems are not easier to patch than others.
- junon 5y ago> Library .so files are not harder to scan than jar files. Of course they are. You can trivially reverse engineer Java bytecode back to Java, with almost everything except generic annotations due to erasure, and a few other small things. Tools have been around for ages that do this[0], and while they're not perfect, they can re-generate nearly perfectly compilable source code. .so files are ELF files, which means while they have sections, those sections don't typically reveal much about the internals of the code. This means you need to convert machine code (assembly) back to a higher level language - which is not a trivial transformation. There are tools that do do this (e.g. hexrays[1]) but they are far from perfect, especially for optimized machine code. Java systems are very, very easy to crack, RE and patch. There are virtually no protections. JAR injection is still a valid means of patching a Java application. No, manifest files and integrity checks are not a security measure but an error detection measure, and are trivially bypassed. If you asked me to choose between patching this vulnerability in a .JAR vs a .SO, I would choose the .JAR any day of the week. [0] http://java-decompiler.github.io/ http://java-decompiler.github.io/ [1] https://hex-rays.com/ https://hex-rays.com/
- ncmncm 5y agoYou do not need to decompile any code to scan a .so for symbols used. So, more advocacy BS.
- junon 5y agoPlease 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).
- ncmncm 5y agoYou do not need internal symbols. All the public entry points are spelled out exactly by name, and all the external symbol dependencies.
- junon 5y agoI 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".
- deleted 5y ago[deleted]