Tag Archives: security

Apache Log4j vulnerability (CVE-2021-44228)

On Thursday, December 9, 2021, the Apache Log4j project disclosed a critical security vulnerability which may result in remote code execution on systems running Log4j. The exploit has been aptly named Log4Shell (CVE-2021-44228).

Log4j is a logging component which runs under Java on many different platforms, and is useful not only for Java applications, but for other programs, as well. It is commonly bundled with unrelated software, simply as a means of providing a standard logging engine.

Arca Noae has completed a scan of our internal systems and has determined that we are not affected by this vulnerability. Further, ArcaOS has never included any Log4j components, and is also unaffected. However, because the exploitable feature in Log4j has existed for some time, it is possible that Java and other applications may have been installed under ArcaOS which utilize Log4j, and these systems may be at risk.

The feature used for the Log4Shell exploit is in the JNDI (Java Naming and Directory Interface) lookup class which was added to Log4j several years ago during the 2.0 beta cycle. Log4j versions through 2.3 required only Java versions up to 1.6, and so may be utilized by some OS/2-compatible applications.

Risk assessment

To determine whether any of your OS/2 systems may be at risk, start by searching all accessible volumes for log4j-*.jar. If any are found, determine the version of Log4j by examining the content of META-INF/MANIFEST.MF in the core jar file:

[c:\] unzip -c log4j-core.jar META-INF/MANIFEST.MF | less

Note the Implementation-Version line content.

Edge servers as well as firewalled systems running various applications may be at risk, as queries may be submitted to the Log4j engine from other applications and potentially from outside the network.

Mitigation

Although the exploit has been addressed in Log4j 2.16.0, because versions above 2.3 are not currently compatible with OS/2’s available Java Runtime Engine, it is necessary to mitigate the condition by removing the JndiLookup class from the classpath, e.g.:

[c:\] zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Additional information

Older (pre-2.0-beta9) versions of Log4j lack this lookup class, and do not appear to be at risk for Log4Shell (though some earlier security advisories may have been issued). Further research may be needed based upon the version(s) of Log4j which may be in use on these earlier systems. Also, this is not the only security advisory for Log4j 2.0-beta9 – 2.3. This notification is only related to CVE-2021-44228.

Links

https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://nakedsecurity.sophos.com/2021/12/10/log4shell-java-vulnerability-how-to-safeguard-your-servers/
https://www.kb.cert.org/vuls/id/930724

Adding Let’s Encrypt’s new root and intermediate certificates to Mozilla applications

On September 30, 2021, Let’s Encrypt’s DST Root CA X3 cross-sign expired, leaving many web browsers to report that sites using Let’s Encrypt SSL certificates were “untrusted” or “unknown.”

Let’s Encrypt did, in fact, implement a new root and intermediate certificates some time ago, but after the built-in certificate stores in the Mozilla applications shipped with all versions of ArcaOS 5.0 to date (5.0 through 5.0.6) were configured. Thus, these new certificates were not included in those builds, and as a result, the new root certificate is indeed unknown.

The fix is relatively simple, and a rather common procedure for all browsers and email clients. To bring your Firefox, Thunderbird, and SeaMonkey certificate stores up to date, and learn how to do this for other new certificates as they become available, we’ve added a new wiki page, here.

Edited to add links to further information (off-site):

Let’s Encrypt – Chain of Trust
Let’s Encrypt – DST Root CA X3 Expiration (September 2021)

Policy statement concerning Spectre and Meltdown exploits

Spectre and Meltdown are terms used to describe two potential exploits in a class of security attacks commonly termed “timing attacks” because they access data which may be sensitive in nature (passwords and other information) from areas of memory which may only be available at specific times (either moved elsewhere or removed entirely at other times). They belong to the more general class termed “side-channel attacks,” because they exploit the hardware itself, rather than breaking encryption or utilizing a software flaw. For more technical information regarding these exploits, please refer to the links section, below.

Arca Noae engineers are monitoring the situation, and while there is still much contradictory information crossing the internet at this time, we believe we have been able to assess at least some of the risk and provide some guidance to users of the OS/2 platform (OS/2 Warp, eComStation, and ArcaOS). As further reliable information becomes available, this post will be updated to reflect any change in Arca Noae’s position and any actions we may plan to take.

General information

In order to gain access to any information in privileged memory using one of these exploits, a user-level application must be launched on the specific machine to be compromised. This means that presently, an OS/2 executable must be used as the attack vector. As of this writing, we are not aware of any such code which executes on the OS/2 platform.

Browser-based attacks (running JavaScript) appear to require greater precision in a high-resolution timer than is currently available on OS/2, making such exploits more difficult than on other platforms, if not altogether impossible. It should also be noted that any such JavaScript-based attack would have to also be specifically designed to handle access to memory regions as managed by OS/2 (in other words, a malicious JavaScript program must be written for OS/2 and specifically to run in the OS/2 browser version in which it is running; a JavaScript program written for Windows or Linux will not work on OS/2). Realistically, the chance of this level of coding detail is extremely small.

Risks – virtual installations vs bare metal

By far, virtualized environments (running OS/2 as a guest under some other more vulnerable platform) are at the greatest risk, because the host system may rightly have access to the guest’s memory and virtualized processor. A host running a vulnerable operating system with an exploitable CPU which remains unpatched is the greatest concern. Arca Noae believes bare metal installations of OS/2-based operating systems are at much less risk.

Arca Noae’s current strategy

To date, we have not identified a need for a kernel patch to mitigate the risk of any hypothetical Spectre or Meltdown attack against OS/2-based systems. We continue to monitor the available information and will adjust our strategy as conditions require.

Arca Noae’s current recommendations

For virtualized and bare metal installations, Arca Noae recommends only running software obtained from trusted sources. Per stand practice, reasonable security precautions should be taken when accessing the internet, particularly when visiting unfamiliar or untrusted sites, and browser cache should be cleared regularly. The use of a NAT firewall is also encouraged (either a separate one, as built into a broadband router or at a minimum, a software firewall running on the local OS/2 system, such as InJoy Firewall).

Because a malicious application designed to utilize one of these exploits would have to be downloaded or copied to the target OS/2 system and then executed locally, normal malware protections remain the best first line of defense.

For virtualized installations, Arca Noae recommends applying to the host system whatever patches are made available and recommended by the developer of the host operating system.

Updates

2019-02-14: Security researchers apparently conclude in this whitepaper that Spectre cannot be entirely mitigated at the software level.

2019-10-07: Intel engineers have proposed (official/latest Intel PDF, here) a new memory type, speculative-access protected memory (SAPM), to mitigate a common factor in side-channel attacks which access cache/memory.

Links

Official information

Spectre CVEs:

CVE-2017-5753

CVE-2017-5715

Meltdown CVE:

CVE-2017-5754

Mozilla Security Blog

CERT: CPU hardware vulnerable to side-channel attacks

Intel: Facts about side-channel analysis and Intel products

AMD: An update on AMD processor security

A Note about Third-Party Components in ArcaOS

You may be aware of the recent massive Equifax security breach and the Company’s explanation surrounding a vulnerability in Apache Struts (CVE-2017-5638) disclosed by US CERT in early March 2017. Some reports have implied that the company has somehow blamed Apache Software Foundation for the breach, specifically by not moving quickly enough to address the security flaw. Apache has responded to these allegations clearly and concisely. In light of this incident, we thought this a good opportunity to help provide some clarity concerning third-party work and open source components, in general, as they pertain to ArcaOS and Arca Noae’s position regarding their fitness for use, and who is ultimately responsible to maintain his or her or, in the case of enterprise use, its own systems.

Arca Noae includes several components in ArcaOS developed by reputable third parties, including IBM, Apple, and others. Some of these components are open source, as well, meaning that the code for compiling these components into machine-readable form is freely available to the public. Open source software is often more secure than proprietary software, by nature of the fact that many (sometimes thousands) of developers around the world contribute to the code. This (often massive) group effort allows such projects to react quickly when flaws are discovered, and to work to constantly monitor and maintain the software. However, whether proprietary or open source, Arca Noae may have no control whatsoever over these components, inherent flaws, or as-yet-undisclosed security issues.

It is Arca Noae’s position that each ArcaOS licensee (whether an individual or an enterprise) bears the sole responsibility to consider his or her or its own interests and security. While we do what is within the realm of reasonable possibility to stay abreast of current trends and vulnerability disclosures (CVEs), we cannot guarantee that all issues will be identified and/or reported to our users by us. Thus, best practices dictate that each user remain vigilant and aware of the connected ecosystem in which we live and to take steps to mitigate his or her or its own risks.

Arca Noae welcomes reports from our users of disclosed and non-disclosed vulnerabilities. While we normally encourage our users to avail themselves of our Mantis ticketing system to report issues, those of a sensitive nature (such as an as-yet-undisclosed or little-known security flaw in a bundled component) should be reported through our contact page.

We would also like to take this opportunity to remind all of our ArcaOS licensees that ArcaOS does not utilize telemetry of any kind to communicate with us. We firmly believe that when a user licenses a copy of ArcaOS, his or her or its data should remain on the system as directed by the user, shared only by the user, and with the user’s full knowledge and consent.

The next exciting update to ArcaOS 5.0 is in the making, too. Watch the Arca Noae blog for a release announcement in the coming weeks.

ArcaOS

Have an enterprise Windows XP application and can’t upgrade Windows?

Talk to us about the possibility of wrapping that Windows XP (or 2000 or even NT 4) app and running it under Odin32. Similar to running an application in a container under Linux, the application itself is the only thing running in a Windows-compatibility environment, while the rest of the system is not subject to Windows security vulnerabilities on the LAN or on the internet. In this configuration, the only user training required is getting the system booted, authenticating to the network, and clicking the program object to start the same Windows application with which your users are already familiar.

Have a Windows application which requires LAN transport, but the version of Windows now in use is too outmoded for the latest file transport security? No problem. Applications running under Odin32 on ArcaOS which need to access network shares may do so using the integrated Samba 4 networking in ArcaOS, which appears to the application to be a local drive. All authentication, security, and transport encryption (if so configured) happens at the ArcaOS level, outside the Windows environment.

Maintain your critical applications on OS/2, DOS, or 16 or 32-bit Windows, on modern hardware or virtualized, while running on a secure, stable, maintained platform: ArcaOS 5.

Note: Any application accessing the public internet may be at risk. ArcaOS itself cannot defend a Windows application running under it against such exploits, if that application is vulnerable to attack.

NetDrive for OS/2

How’s your NetDrive?

NetDrive for OS/2 is an essential connectivity tool for OS/2 and derivative operating systems, including eComStation. This week, NetDrive 3.1.5 has been released, addressing a couple minor issues and enabling the use of the updated plugin for SFTP connections, now available from the Arca Noae store. NetDrive 3.1.5 is a free upgrade for existing NetDrive 3 licensees.

You may purchase new or additional licenses for NetDrive and a number of commercial plugins from our store.

Globally locked

EU-US Privacy Shield – Status Report

If you are a resident of the European Union and a customer of ours, chances are you have been watching (or at least are aware of) the situation regarding data transfer policy between the EU and the US.

On October 6, 2015, the Court of Justice of the European Union (the “CJEU”) invalidated the European Commission’s Decision on the EU-US Safe Harbor arrangement, determining that the Commission’s finding that Safe Harbor was adequate was, in fact, inadequate. More on this decision may be found here.

On February 2, the US and the EU reached an agreement in principle to construct a framework to replace Safe Harbor and to reconcile differences between the laws of both governments. That framework has been named the EU-US Privacy Shield. In response to the agreement, the US Department of Commerce released a fact sheet, which we are making available as a pdf, here.

As the new framework promises to have farther reaching implications for how personally identifiable data is handled by third parties, we have contacted both of our current payment processors (Stripe and PayPal) for their comments. While we are still awaiting comment from PayPal, Stripe has responded that they, too, are monitoring the situation, but have not yet made any changes to their policies or procedures, pending more concrete guidance.

We want you to know that we take the privacy concerns of our customers very seriously, and we will continue to monitor this and any other legislation which may have an impact on doing business with us, whether you are located within the US or anywhere in the world. We believe that our current privacy policy remains in accord with the spirit of the new EU-US Privacy Shield as we anticipate it, but we will keep you apprised of the situation and will make adjustments as necessary.

More information and commentary on the EU-US Privacy Shield may be found on these sites:

Digital Media, Technology & Privacy Alert >> Agreement on EU-U.S. Privacy Shield to Replace Safe Harbor Faces Hurdles, Kibel, Gary A, Partner (Digital Media, Technology & Privacy), Davis & Gilbert, LLP, February 4, 2016.

Article 29 Working Party Reacts to the U.S.-EU Privacy Shield Agreement, Tielemans, Jetty and Steinhardt, Ezra (Data Privacy and Cybersecurity group), Covington & Burling LLP, February 2, 2016.