Hey Guys,
“Log4jl has similar architecture as Apache Log4j 2 framework.”
Sorry if this is already been addressed. However, I haven’t been able to find any sign of a security statement from the community about the following Julia package which essentially is based on Apache’s Log4j 2 architecture.
Is there a security concern or a response from the Julia community related to this package? Has it been reviewed in context of the recent global zero day vulnerability announced by Apache?
That package hasn’t been updated in 6 years, isn’t in the General registry, and probably doesn’t work with any 1.x release of Julia, so it really doesn’t seem like much of a concern to anyone.
Thanks for your response. I agree it is likely a minor concern. However, should there be users running legacy versions in systems it might be worth considering a review. Also has the architectural approach which follows Apache’s Log4j2 design, been applied in other packages? I am quite new to Julia so don’t have a clear view. I did go through a number of repos myself and didn’t find any of concern.
Hi @Sascha_McDonald and welcome to the community! 
As you are new to Julia and the Julia ecosystem, let me give some insight on why I think your concern, although completely valid, is not as big a concern as you may think with respective to @pfitzseb 's great concise answer and Julia.
In the landscape of the Julia ecosystem, there is not one way to create a package in terms of architecture (syntax aside).
The closest you can get to where folks copy each other’s rudimentary architecture is with Invenia’s PkgTemplates.jl which I can assure you does nothing more than create a skeleton for you to add in your code for your package.
Furthermore, in terms of syntax and design styling, there is not one way either although I am a huge advocate for BlueStyle created by Invenia.
As @pfitzseb said, this has not been added to Julia’s General Registry (which is like npm in Node, or CRAN in R, or pip in Python).
Folks cannot easily install it nor is there any risk within the Julia ecosystem in that way.
Finally, in addition to the prior statement, there really is no way (well easy way I should say to qualify my statement) to find all the packages and users of this particular package.
There is no real group in Julia who have knowledge of everything and all the things users are doing and as such, no audits going to take place arbitrarily (to my knowledge).
I hope that can perhaps allay more directly your fears.
With respect to Log4js, the Julia ecosystem is quite secure.
Cheers and welcome to the community!
Feel free to post follow up questions!
~ tcp 
Thanks so much for your considered response. As part of security due diligence I felt it important to ask the question. Thanks again for your help. That’s exactly what I required. 
Log4shell boils down to the following:
- Logs are an integral part of an application. They document any important event and action that happens within their embedding app, including actions of the application’s users.
- This means that in some part of an app, user-provided input is logged, and that any user has the ability to control a portion of an application’s log.
- Log4j enabled a feature that let it parse and interpret logs that contain requests to remote servers. This was added as a way to create dynamic content in a log.
The above three points combined form a fatal combination from an app’s perspective:
Any user is most likely able to control some portion of an application’s log, and include an arbitrary call to any remote server, forcing the application to execute any data the remote server responds with.
Log4j Vulnerability CVE-2021-45046 Now a Critical 9.0 | WhiteSource
The third item above actually consists of two steps:
Refer to a more technical description of the vulnerability:
It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments.
We have:
${ some_danger_cmd } which is called message lookupsBoth of these are critical steps in vulnerability exploitation, and blocking either of them can mitigate the vulnerability.
In fact Apache’s mitigation and vulnerability remediation does the same thing.
Log4j 2.x mitigation
Implement one of the following mitigation techniques:
- Java 8 (or later) users should upgrade to release 2.16.0.
- Java 7 users should upgrade to release 2.12.2.
- Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.
Release Details
From version 2.16.0 (for Java 8), the message lookups feature has been completely removed. Lookups in configuration still work.
Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.
Log4jl.jl hasn’t been updated in a long time, and I haven’t reviewed its code in detail, so I can’t make a judgment.
But Log4jl.jl does not call Java directly, nor does it implement JNDI.
In principle, it can’t call a program at any remote address.
Although Log4jl.jl claims to have an architecture similar to Log4j, I think the architecture here is mainly the design of the API interface. Rather than having a similar internal implementation.
In general, I prefer that Log4jl.jl is not affected by CVE-2021-45046.
Looking through JuliaHub.com, I don’t see any references to Log4jl in any registered package. Unless you are explicitly using it for some reason, I would not be worry about it.
https://juliahub.com/ui/Search?q=Log4jl&type=symbols&t=module
More generally, I would look into your dependencies and their dependencies to see how well they are maintained. The Manifest.toml file of a project will help you find all the packages used by your code.
Your responses have offered a very helpful reference for others undertaking security audits post the Apache Log4j 2 vulnerability announcement that has been so enormously disruptive.
Access to community statements are just as important as a statement from a large commercial provider. It all helps speed up identifying and triaging potentially vulnerable systems.
A big thanks to the Julia Community!
Have a great festive season one and all!
Sascha
That package was an early attempt to provide a logging framework for Julia. Nowadays, Julia has a versatile standard logging api which is suited for majority of common use cases.
I’ll archive the project to avoid further misunderstandings. I’ve already archived it.