Thoughts on the security issues of Log4j, what they imply for the developer community in general, and the specific effect on RAD Studio developers.
Unless you live on a remote island with no Internet connection, you’ve certainly heard about the Log4j issues that affected so many applications and internet services over the last 10 days. The coincidental discovery of this critical bug in the context of Minecraft console messages (typing a message on the Minecraft game client could let someone execute code on a Minecraft server) due to the use of an extremely popular Java logging library called Log4j, caused every single IT company and every company using software applications to check if the issue was affecting the company’s software, hosted services, internal web sites, and any other use case scenario.
The list of affected software applications (there is one here, for example) is fairly impressive, because despite having lost some of the hype and marketing push, Java is and remains one of the world’s most popular languages, and the JVM one of the most popular runtime execution environments.
RAD Studio Native Code and No Java Dependency
Let me clarify once more: A web server or web service built in Delphi or C++Builder (or C++ in general) is not affected by the Log4j issue. The same is true, of course, for web applications built in ASP.NET, Python, or PHP. The issue is specific to software written in Java – and there is a lot of Java software out there, as linked above.
Getting back to Delphi and C++Builder, having compiled code helps with security, but it is not sufficient. It is also important to only choose libraries and components you can fully trust (at a minimum, requiring the source code to be included). Moreover, it is also important for a developer to write code with a specific focus on security. As was mentioned last week, copy-and-paste coding (while not directly responsible for the Log4j issue) is a coding style on the flip side of writing secure applications.
Contributing Back to Open Source
There is also another key issue that the Log4j problems made obvious: there are multi-million dollar projects managed by large corporations that rely on open source projects with no funding, managed by developers in their spare time (outside their regular jobs). The idea that you can use open-source to save costs without contributing back any time, resources, or money to the projects you leverage is becoming a huge problem in the industry.
This is also true of the Delphi and C++Builder ecosystem: Embarcadero has started funding and donating to a few open source libraries, but we should do more. We also encourage all business applications that significantly leverage open-source Delphi libraries and tools to contribute back to them – including through security assessments!
How many open-source projects do you use for your professional applications and when is the last time you donated to any of them?
Security is Multi-Faceted
Security is a continuum requiring multiple angles and each of the items below can help:
- Natively compiled applications
- No dependency on a runtime execution environment
- Use of vetted and trusted third party libraries and components
- Committing to contribute back to open-source projects you leverage
- Security focus when writing code (no copy-and-paste coding)
- Tooling to verify an application source code
- Secure storage of source code (to avoid source code injection)
- Secure build environment (to avoid binary code injection)
- Application executable signing
While not comprehensive, and one with a bias towards compiled code (we really think it matters), we hope this list and the overall reaction to the Log4j incident can help you and your organization rethink security and add more value to the role of developers – who are the cornerstone of any secure development scenario.
Happy coding with your Log4j-free RAD Studio 😉
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition
Hi Marco, the ELC (Delphi / RAD Studio License Server) is written in Java. It uses log4j v1.2.15
Sure it’s not affected to the cve-2021-xxx, but for exsample to older cve-2019-17571
in cve-2021-4104 you can read: …Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
So when we can get an new version of ELC without cve-* ?
Regarding the Open-source thing: When I was a developer in industry, my company actually had a rule against using ANY open source code for critical/key software functions. We would use some open source tools, but nothing that would leave us dangling if a critical bug should show up. Any functionality depending on open source should be no more important than “nice to have” and easy to amputate if it gets trapped. Don’t stake your business on anything you don’t have a contractual handle on!
I’ve been appalled at how easily some people pull huge lumps of open-source code into their project, of which they have no intention to investigate whether it is truly fit for purpose. Hundreds of megabytes of libraries just to get one ready-made utility that you’re too lazy to try to create yourself. “For free”, haha, until it turns around and bites you. OK, granted, no rules without exceptions. But the Open Source Gospel always sounded more like a risk than a temptation to me.
Oh and regarding Log4j, believe it or not, I never had the pleasure. Some people actually don’t write web apps, but good old-fashioned desktop software with – in the interest of security – little or no connectivity at all. It happens!
We are using Log4Delphi which is similar or based on Log4j 1.2.8, So can Log4J vulnerability can affect it?
Log4Delphi is a library not maintained by Embarcadero, you should check with the maintainers. But I doubt the same issue of the Java version applies to Delphi.