Both log4shell and Shellshock are remote code execution vulnerabilities impacting an enormous range of systems. Shellshock is a vulnerability in bash (a very common Linux shell), which is an application, while log4shell is a vulnerability in the log4j library. For multiple reasons, the log4j security issue poses a bigger challenge in terms of mitigating the threat.
To detect Shellshock, it was enough to check the local system whether a vulnerable version of bash was installed; bash itself is usually not shipped with third-party dependencies.
The log4shell security issue is much harder to detect, since log4j is a library, so detection requires checking all the direct and indirect (transitive / recursive) dependencies. Furthermore, the attack vector for log4shell is more common (logging unsanitized input) than Shellshock’s (passing unsanitized input to bash environment).
Log4shell is also harder to fix – since it is a library, several APIs were changed in newer versions, which means a software vendor might have to modify the first-party code directly interacting with log4j, and not just upgrade log4j itself.
Finally, newer versions of log4j require a newer version of Java (Java 8 vs. the legacy Java 6/7) which means the software vendor might have to upgrade the Java component as well, which may in turn cause incompatibilities with other Java-based software on the system.