https://spectrum.ieee.org/log4shell-log4j-still-stings [ ] IEEE.orgIEEE Xplore Digital LibraryIEEE StandardsMore Sites Sign InJoin IEEE The January 2023 issue of IEEE Spectrum is here! Download PDF | Close bar Log4Shell Still Has Sting In The Tail Share FOR THE TECHNOLOGY INSIDER Search: [ ] Explore by topic AerospaceArtificial IntelligenceBiomedicalComputingConsumer ElectronicsEnergyHistory of TechnologyRoboticsSemiconductorsSensors TelecommunicationsTransportation IEEE Spectrum FOR THE TECHNOLOGY INSIDER Topics AerospaceArtificial IntelligenceBiomedicalComputingConsumer ElectronicsEnergyHistory of TechnologyRoboticsSemiconductorsSensors TelecommunicationsTransportation Sections FeaturesNewsOpinionCareersDIYThe Big PictureEngineering Resources More Special ReportsCollectionsExplainersPodcastsVideosNewslettersTop Programming LanguagesRobots Guide For IEEE Members Current IssueMagazine ArchiveThe InstituteTI Archive For IEEE Members Current IssueMagazine ArchiveThe InstituteTI Archive IEEE Spectrum About UsContact UsReprints & PermissionsAdvertising Follow IEEE Spectrum Support IEEE Spectrum IEEE Spectrum is the flagship publication of the IEEE -- the world's largest professional organization devoted to engineering and applied sciences. Our articles, podcasts, and infographics inform our readers about developments in technology, engineering, and science. Join IEEE Subscribe About IEEEContact & SupportAccessibilityNondiscrimination PolicyTerms IEEE Privacy Policy (c) Copyright 2022 IEEE -- All rights reserved. A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. IEEE websites place cookies on your device to give you the best user experience. By using our websites, you agree to the placement of these cookies. To learn more, read our Privacy Policy. view privacy policy accept & close Enjoy more free content and benefits by creating an account Saving articles to read later requires an IEEE Spectrum account The Institute content is only available for members Downloading full PDF issues is exclusive for IEEE Members Access to Spectrum's Digital Edition is exclusive for IEEE Members Following topics is a feature exclusive for IEEE Members Adding your response to an article requires an IEEE Spectrum account Create an account to access more content and features on IEEE Spectrum, including the ability to save articles to read later, download Spectrum Collections, and participate in conversations with readers and editors. For more exclusive content and features, consider Joining IEEE. Join the world's largest professional organization devoted to engineering and applied sciences and get access to all of Spectrum's articles, archives, PDF downloads, and other benefits. Learn more - CREATE AN ACCOUNTSIGN IN JOIN IEEESIGN IN Close Access Thousands of Articles -- Completely Free Create an account and get exclusive content and features: Save articles, download collections, and talk to tech insiders -- all free! For full access and benefits, join IEEE as a paying member. CREATE AN ACCOUNTSIGN IN ComputingTopicTypeNews Log4Shell Still Has Sting In The Tail The cyber-vulnerability mounts a quiet comeback as organizations grow complacent Edd Gent 28 Dec 2022 4 min read blue zeros and ones in a random sequence Alamy log4jcybersecurityopen source The December holiday plans of IT workers were thrown into disarray last year after the disclosure of a major bug in the widely-used Log4j tool. The discovery led to months of feverish activity to patch the vulnerability, but a year on it has slipped off the radar. The threat hasn't gone away though, say security experts, and could make a resurgence if the industry isn't careful. When it was first revealed in early December 2021, the Log4Shell bug was described as one of the most severe security vulnerabilities ever. It targeted a popular tool for logging activity in Java software designed to help keep track of errors and diagnose performance issues. Its broad utility means Log4j has been embedded in thousands of software packages and was found in a wide variety of commercial services, including Amazon Web Services and the videogame Minecraft. What's more, the bug made it relatively simple for attackers to take complete control of vulnerable systems. This led to a mad scramble to plug the gaps. The Apache Software Foundation, which maintains the open-source tool, quickly released a patch, and organizations spent months scanning their systems and updating their software. But more than a year later, cybersecurity firm Tenable says 72 percent of organizations remain susceptible to Log4Shell. And worryingly, a large number of organizations that had fixed the bug have since reintroduced it to their systems by installing vulnerable software, says Bernard Montel, technical director and security strategist at Tenable. One day in December of this year saw the highest daily attacks since the Log4j vulnerability was discovered. "When they put it in place a plan for fixing it roughly a year ago, they thought they'd done it," he says. "They cleaned, they identified, they've scanned, they've patched their software and for them, they've done what they needed to do. They just forgot the fact that the attack surface is moving." Tenable estimates that the proportion of machines vulnerable to the exploit has dropped from one in ten last December to just 2.5 percent as of this October. But up to a third of these had already been fully patched, and have since been reinfected with Log4Shell. Part of the problem is that Log4j is buried deep in a lot of commonly used software libraries, says Montel. It's often not clear whether the utility is included in a particular tool, and even when it is, most developers aren't sufficiently security minded to check if it's the most up-to-date version, particularly given the pressure they are under to produce code quickly, he adds. Research from security firm Sonatype from a year ago found that 65 percent of downloads of Log4j were of vulnerable versions of the tool. At an organizational level, Montel also thinks that after the huge push to deal with the vulnerability in the early months it was almost inevitable that people would lose focus once they felt they'd remediated the problem. He thinks there are clear analogies to the Covid-19 pandemic, in which stringent measures like lockdowns rapidly got the virus under control, only for it to reappear when things relaxed again. "It [Log4j] is coming back," says Montel. "It's still there somewhere, so just observe the waves." A July report from the Department of Homeland Security's Cyber Safety Review Board assessed that the bug had become "endemic" and was likely to remain a problem for years if not decades. And data collected by security company Imperva has shown that while attacks exploiting the bug have fallen considerably since the first couple of months of 2022, there has been a steady increase since November, with 3 December of this year seeing the highest daily attacks since the vulnerability was discovered. One potential remedy: organizations could start requiring a Software Bill of Materials for all the code they use Imperva estimates that about 7 percent of those attacks are successful. But although there have been some high profile hacks--including ones by Chinese state-sponsored hackers in March and an Iranian attack on a US federal agency in November--so far, the bug hasn't lived up to the dire predictions made last year. "Although plenty of companies were impacted, it was largely less than anticipated," says Gabi Stapel threat research analyst at Imperva. What is has done though is bring to light how reliant many companies are on third-party and open source code over which they have little control or visibility. "Historically, companies have focused on the risk introduced by their immediate set of vendors and the critical software they rely on," says Stapel. "Organizations need to adopt a threat model that includes all parts of the supply chain." The cost and complexity of the response to Log4Shell has certainly driven an increasing focus on securing the software supply chain and boosting transparency, says Eric Goldstein, executive assistant director for cybersecurity at the Cybersecurity and Infrastructure Security Agency (CISA). "A host of new tools, companies, and products have emerged over the past year to help better understand software dependencies, and Log4j is often used as a primary motivation for innovation and adoption," he says. One potential remedy that CISA has been promoting is the Software Bill of Materials (SBOM). This is an inventory of all the components that make up a software application, which is designed to make it easier for developers to track any dependencies on potentially risky bits of code. The US government has signaled that these may soon become a requirement for software delivered to federal agencies. For the approach to really have an impact it needs to move further upstream though, says Brian Behlendorf, general manager at the Open Source Security Foundation (OSSF), so that even the original open-source software packages or libraries that developers assemble to create applications come with their own SBOMs. Doing so is likely to require new tools that simplify this process and bake them into existing software building tools though, says Behlendorf, because "getting developers to spend some extra effort can be a challenge". The industry as a whole also needs to coordinate better and be more proactive about securing the open source tools it relies on, he says. Individual projects simply don't have the finances or manpower to do things like code reviews, says Behlendorf. "There's just a disconnect between the value to be received by the ecosystem, and the ability to muster those kinds of resources," he says. "What we need are institutions who are able to aggregate demand for better scrutiny for these thing and channel resources into targeted, low-hanging fruit." That's why in May, the OSSF and the Linux Foundation unveiled an Open Source Software Security Mobilization Plan, which highlighted ten areas where a small amount of investment could dramatically reduce the risk of vulnerabilities like Log4Shell. These include things like better security education for developers, the establishment of an OSSF incident response team to help under-resourced open source teams react to vulnerabilities, and yearly code reviews of the 200 most critical open source software components. Bringing this to fruition will require considerable funding from both industry and government, says Behlendorf. But it would be a wise investment and without some kind of coordination, it won't be long until the next Log4j comes along, he says. From Your Site Articles * Google Tool Joins Ferocious Hunt for Log4j Bug > Related Articles Around the Web * Log4Shell - Wikipedia > * Mitigating Log4Shell and Other Log4j-Related Vulnerabilities | CISA > log4jcybersecurityopen source Edd Gent Edd Gent is a freelance science and technology writer based in Bangalore, India. His writing focuses on emerging technologies across computing, engineering, energy and bioscience. He's on Twitter at @EddytheGent and email at edd dot gent at outlook dot com. His PGP fingerprint is ABB8 6BB3 3E69 C4A7 EC91 611B 5C12 193D 5DFC C01B. His public key is here. DM for Signal info. The Conversation (0) A rectangular kitchen appliance with a metal housing, a glass door, and two dials on the righthand side. History of TechnologyTopicMagazineArticleTypeConsumer Electronics January 2023 Always Break Yolks: The Joy of Microwave Cooking 1h 6 min read A picture of a small industrial-looking humanoid robot with no head sitting on a yellow packing case RoboticsTopicTypeNews Video Friday: BRUCE 4h 3 min read An illustration of overlapping blue word bubbles with IEEE on one. The InstituteTopicTypeNews Notice to Membership 29 Dec 2022 1 min read Related Stories ComputingTopicMagazineTypeNewsJanuary 2023 Ownership of AI-Generated Code Hotly Disputed TelecommunicationsTopicTypeNews New Ethernet Cyberattack Crunches Critical Systems ComputingTopicNewsType Meet the Open Source PC That Fits in Your Pocket ComputingTopicMagazineTypeFeatureSpecial ReportsJanuary 2023 An IBM Quantum Computer Will Soon Pass the 1,000-Qubit Mark The Condor processor is just one quantum-computing advance slated for 2023 Charles Q. Choi 24 Dec 2022 4 min read This photo shows a woman working on a piece of apparatus that is suspended from the ceiling of the laboratory. A researcher at IBM's Thomas J. Watson Research Center examines some of the quantum hardware being constructed there. Connie Zhou/IBM IBM's Condor, the world's first universal quantum computer with more than 1,000 qubits, is set to debut in 2023. The year is also expected to see IBM launch Heron, the first of a new flock of modular quantum processors that the company says may help it produce quantum computers with more than 4,000 qubits by 2025. While quantum computers can, in theory, quickly find answers to problems that classical computers would take eons to solve, today's quantum hardware is still short on qubits, limiting its usefulness. Entanglement and other quantum states necessary for quantum computation are infamously fragile, being susceptible to heat and other disturbances, which makes scaling up the number of qubits a huge technical challenge. Nevertheless, IBM has steadily increased its qubit numbers. In 2016, it put the first quantum computer in the cloud anyone to experiment with--a device with 5 qubits, each a superconducting circuit cooled to near absolute zero. In 2019, the company created the 27-qubit Falcon; in 2020, the 65-qubit Hummingbird; in 2021, the 127-qubit Eagle, the first quantum processor with more than 100 qubits; and in 2022, the 433-qubit Osprey. This diagram shows the quantum processors that IBM expects to have ready in 2023 (Condor and Heron), in 2024 (Flamingo and Crossbill), and in 2025 (Kookaburra).IBM expects to build quantum computers of increasing complexity over the next few years, starting with those that use the Condor processor or multiple Heron processors in parallel.Carl De Torres/IBM Other quantum computers have more qubits than does IBM's 1,121-qubit Condor processor--for instance, D-Wave Systems unveiled a 5,000-qubit system in 2020. But D-Wave's computers are specialized machines for solving optimization problems, whereas Condor will be the world's largest general-purpose quantum processor. "A thousand qubits really pushes the envelope in terms of what we can really integrate," says Jerry Chow, IBM's director of quantum infrastructure. By separating the wires and other components needed for readout and control onto their own layers, a strategy that began with Eagle, the researchers say they can better protect qubits from disruption and incorporate larger numbers of them. "As we scale upwards, we're learning design rules like 'This can go over this; this can't go over this; this space can be used for this task,'" Chow says. Other quantum computers with more qubits exist, but Condor will be the world's largest general-purpose quantum processor. With only 133 qubits, Heron, the other quantum processor IBM plans for 2023, may seem modest compared with Condor. But IBM says its upgraded architecture and modular design herald a new strategy for developing powerful quantum computers. Whereas Condor uses a fixed-coupling architecture to connect its qubits, Heron will use a tunable-coupling architecture, which adds Josephson junctions between the superconducting loops that carry the qubits. This strategy reduces crosstalk between qubits, boosting processing speed and reducing errors. (Google is already using such an architecture with its 53-qubit Sycamore processor.) In addition, Heron processors are designed for real-time classical communication with one another. The classical nature of these links means their qubits cannot entangle across Heron chips for the kind of boosts in computing power for which quantum processors are known. Still, these classical links enable "circuit knitting" techniques in which quantum computers can get assistance from classical computers. For example, using a technique known as "entanglement forging," IBM researchers found they could simulate quantum systems such as molecules using only half as many qubits as is typically needed. This approach divides a quantum system into two halves, models each half separately on a quantum computer, and then uses classical computing to calculate the entanglement between both halves and knit the models together. IBM Quantum State of the Union 2022 While these classical links between processors are helpful, IBM intends eventually to replace them. In 2024, the company aims to launch Crossbill, a 408-qubit processor made from three microchips coupled together by short-range quantum communication links, and Flamingo, a 462-qubit module it plans on uniting by roughly 1-meter-long quantum communication links into a 1,386-qubit system. If these experiments in connectivity succeed, IBM aims to unveil its 1,386-qubit Kookaburra module in 2025, with short- and long-range quantum communication links combining three such modules into a 4,158-qubit system. IBM's methodical strategy of "aiming at step-by-step improvements is very reasonable, and it will likely lead to success over the long term," says Franco Nori, chief scientist at the Theoretical Quantum Physics Laboratory at the Riken research institute in Japan. IBM's quantum leaps in software In 2023, IBM also plans to improve its core software to help developers use quantum and classical computing in unison over the cloud. "We're laying the groundwork for what a quantum-centric supercomputer looks like," Chow says. "We don't see quantum processors as fully integrated but as loosely aggregated." This kind of framework will grant the flexibility needed to accommodate the constant upgrades that quantum hardware and software will likely experience, he explains. In 2023, IBM plans to begin prototyping quantum software applications. By 2025, the company expects to introduce such applications in machine learning, optimization problems, the natural sciences, and beyond. Researchers hope ultimately to use quantum error correction to compensate for the mistakes quantum processors are prone to make. These schemes spread quantum data across redundant qubits, requiring multiple physical qubits for each single useful logical qubit. Instead, IBM plans to incorporate error-mitigation schemes into its platform starting in 2024, to prevent these mistakes in the first place. But even if wrangling errors ends up demanding many more qubits, IBM should be in a good position with the likes of its 1,121-qubit Condor. From Your Site Articles * Quantum Error Correction - IEEE Spectrum > * IBM Unveils 433-Qubit Osprey Chip > * IBM's Target: a 4,000-Qubit Processor by 2025 > Related Articles Around the Web * CONDOR - IBM > * IBM Quantum roadmap to build quantum-centric supercomputers ... > * IBM's roadmap for scaling quantum technology | IBM Research Blog > Keep Reading |Show less