4 ms·

With languages that output a single binary by default such as Rust and Go, we would have been screwed. No way to scan, no way to self-help update. ELF binaries

With languages that output a single binary by default such as Rust and Go, we would have been screwed. No way to scan, no way to self-help update. ELF binaries are just collections of another sort. You can scan for symbol names or assembled instructions common to a dependency, and you might be able to update with an LD_PRELOAD library that patches the symbol table. Just look at what game modders have accomplished without access to source code.

spockz 5y ago
Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tree from there. Problem solved. (Except for shaded dependencies…, but scanning for that should happen at build time anyway.)
- lazide 5y ago
  Good luck doing that on the custom software some vendor provided you 5 years ago and since has gone out of business.. and that’s a GOOD scenario for a lot of enterprise software. Sometimes it’s 20 years.
  - Too 5y ago
    Lesson learned. Never buy closed source. Imagine the vulnerability would have been in the vendor code instead of in the log4j jar. You’d. still need a way to fix and rebuild it. Note that this doesn’t have to mean a public MIT repo on GitHub. You can have more restrictive gray box licenses between your b2b partners only.
    - tormeh 5y ago
      If it's a 20 year old closed source application, there probably aren't any exploits in the wild. You can bet there are exploits for log4j.
  - hamilyon2 5y ago
    We need some sort of escrow for source code of closed-source product. Whenever there is practical need to have access to source code, it should be available.
  - spockz 5y ago
    Okay. Just like any other software that should be firewalled in to only connect to what it should connect to. Moreover, I think meta sploit already has this vulnerability built in so it should be trivial to test/fuzz the application.
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 ago
  The 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/

spockz 5y ago

Besides this, who actually scans the deployed binaries? Just check which version of the binary was deployed, backtrack to the source, and get the dependency tree from there. Problem solved. (Except for shaded dependencies…, but scanning for that should happen at build time anyway.)

lazide 5y ago
Good luck doing that on the custom software some vendor provided you 5 years ago and since has gone out of business.. and that’s a GOOD scenario for a lot of enterprise software. Sometimes it’s 20 years.
- Too 5y ago
  Lesson learned. Never buy closed source. Imagine the vulnerability would have been in the vendor code instead of in the log4j jar. You’d. still need a way to fix and rebuild it. Note that this doesn’t have to mean a public MIT repo on GitHub. You can have more restrictive gray box licenses between your b2b partners only.
  - tormeh 5y ago
    If it's a 20 year old closed source application, there probably aren't any exploits in the wild. You can bet there are exploits for log4j.
- hamilyon2 5y ago
  We need some sort of escrow for source code of closed-source product. Whenever there is practical need to have access to source code, it should be available.
- spockz 5y ago
  Okay. Just like any other software that should be firewalled in to only connect to what it should connect to. Moreover, I think meta sploit already has this vulnerability built in so it should be trivial to test/fuzz the application.

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 ago
The 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/