Hi Hank (& Al & the rest...)

the situation has more horns than that. The main vulnerability and scenario is the wide usage of Apache web server, which has the vulnerability like "batteries included". There were several attempts to create linked executables for Windows (.exe) and Linux including a specific runtime as versioning became backward-incompatible. Then there were the half-VM containers, which also included a specific Java VM if needed. Just checking for installation of different typical Java runtimes falls short of a guarantee that Log4j will not run. Even "executing" a jar under windows via extension automatic might not be enough as the extension might be changed for a self-compiled runtime. Whopee!

The vulnerability mirrors dll-hell insofar as Java allows calling up specific jars, which are zipped compiled classes (think .vcx/vct with source memos blanked) loaded according to path settings of the OS if no explicit URI is provided, making it possible a later install/deinstall will change the actually loaded log4j.jar.

A global location for the .jar has the same problems as a "common" .dll, different package managers lure to static linking as less stony path from "apt-get update" and cousins.

Then there are other web servers written in Java, JeTTy probably most often used "tiny" alternative to Lasagne stuffed TomCat of the Garfield breed. IIRC there is a smaller logging implementation for JeTTY (as JeTTy is often run on much smaller devices down to ARM and less), but this can be replaced or redirected to Log4J if mainly used in specific context.

Even Windows servers might be endangered if they have a Java service running which logs with Log4J and is fed strings from "elsewhere" under foreign control. There are also Log4j similar implementations in other languages, which could be at risk if they also interpret unsanitized strings. No idea how "trans"compiled Java >> IL via the KVM runtime first created under Xamarin ages ago handles the scenario...

On top of that the behaviour of Log4j can be modified by command line switches...

I think the best answer is quite terse - perhaps referring to "official Microsoft Windows and DOTNET API" as this is about an ASP.NET solution, perhaps listing other bought or included toolkits / libraries if offered compensation for the effort of researching and listing.

my 0.00022 of any western denomination playing a large role in NATO budget
thomas

>Good point.
>One way to test: create a new VM that doesn't have Java installed. Does your app run fully? If so, there are no hidden vulnerabilities.
>
>If your app is hosted somewhere, then there's still a chance that other hosted apps are vulnerable, which in turn makes your app vulnerable.
>
>The vendor that hosts the big app for my day job has done their due diligence, found 2 instances and taken care of them. They have been doing this for 21 years so they know the drill and did it.
>
>Hank
>
>>If that's true of your app and all its dependencies you should not have anything to worry about. One of the main pain points of this situation is that Log4J is apparently a very common dependency.
>>
>>Re your original post: Companies are scrambling to determine if they're running vulnerable Log4J. Ultimately it's up to them to mitigate but they're trying to get help from vendors like you, even if it's just to rule your app out as a potential problem.
>>
>>You mainly want to avoid the situation where you tell them your app doesn't use Log4J, but it turns out it does, and someone gets hacked as a result.
>>
>>>My application does not use the Log4J. Neither does it use Java (it uses JavaScript but it is a different animal).
>>>The application is built on and uses the .NET framework.
>>>
>>>>That's not my understanding: https://en.wikipedia.org/wiki/Log4Shell
>>>>
>>>>As I read it, you are vulnerable if:
>>>>
>>>>- your device runs Java and includes a vulnerable version of the Log4J framework for logging
>>>>- your device can receive unsanitized requests which get logged by Log4J
>>>>
>>>>An attacker can thereby execute arbitrary commands in the context of the Log4J process running on the target device.
>>>>
>>>>Log4J is maintained by the Apache Software Foundation but this vulnerability is not limited to Apache servers running Java. It's basically Java-wide if Log4J is in use and can be reached by an attacker.
>>>>
>>>>>The problem exists in one component that is used by some Apache servers. Unless your app uses an Apache server, you have no exposure -- from what I've read.