Posts Tagged ‘Red Hat’

Tech Giants Voltron Up Against AI Safety Threats

Monday, July 27th, 2026

With nearly constant news about AI-based security threats (both within and without), it’s notable that several tech giants have banded together to address the problem.

Nvidia and a host of tech giants on Monday launched a new artificial intelligence safety initiative focused on open models, as the fallout from a cyberattack committed by rogue OpenAI models continues.

Last week, it emerged that the target of the attack, startup Hugging Face, was unable to use leading U.S. frontier models to defend itself, with guardrails not distinguishing between aggressor and defender. Instead, it turned to a self-hosted, open-weight Chinese model, which was not bound by those same restrictions.

I’ve got to say, when I read “Hugging Face,” I don’t think of an emoji, I think of this:

I don’t think I want to collaborate with a company that wants to shove a chestburster egg down my throat.

In the wake of U.S. lawmakers increasingly weighing how to curb growing adoption of Chinese AI models, the most advanced of which are open weight, tech giants have launched an initiative aimed at building and sharing open AI tools.

Open models can be downloaded, modified and self-hosted, in contrast to closed models — including frontier systems built by Anthropic and OpenAI — which can only be accessed through specific infrastructure.

“The Open Secure AI Alliance will work to remediate and disclose vulnerabilities using open technologies,” Nvidia said in a statement. “The recent Hugging Face security incident delivered a clear reminder: cyber defenders need open, frontier agentic systems for self-defense.”

Alongside Nvidia, other members of the alliance include Microsoft, SpaceX, Palantir, and dozens of other tech companies from the U.S. and Europe.

So, that’s three leading tech companies…and Microsoft, which is probably responsible for more security holes than all the rest combined.

News articles don’t seem to give the full membership list, so in a bit of irony, I asked Google’s AI.

  • Adobe
  • Cadence
  • Capital One
  • Cisco
  • Cloudera
  • CloudFlare
  • Cognition
  • Crowdstrike
  • Databricks
  • Dell Technologies
  • DoorDash
  • Elastic
  • Hewlett Packard Enterprise
  • Hugging Face
  • IBM
  • LangChain
  • The Linux Foundation
  • Microsoft
  • NAVER
  • NetApp
  • Nous Research
  • OpenClaw
  • Palantir Technologies
  • Palo Alto Networks
  • Red Hat (which is an IBM subsidiary)
  • Reflection AI
  • Salesforce
  • SAP
  • SK Telecom
  • ServiceNow
  • Siemens
  • Snowflake
  • SpaceXAI (xAI)
  • Synopsys
  • Thinking Machines Lab
  • TrendAI
  • A pretty extensive list of (mostly) American tech giants (NAVER and SK Telecom are South Korean companies, and SAP and Siemens are German). Hell, I’ve even worked for three companies on that list.

    Notable omissions? OpenAI, Google, and Anthropic, all of whom used closed rather than open AI models. Plus Apple, which made the conscious decision not to be a player in the AI space.

    That’s an awful lot of collective brainpower to address the problem, but I wonder if the very size will make it unwieldy.

    More sharing of open AI tools are probably in order.

    I’m not in the, “OMG, we have to shovel a zillion dollars into AI because China!” camp. The “China is an AI giant” crowd seems to have a lot of the same crowd that always overhype China, but their tech offerings always seem to have feet of clay. My working assumption is that AI will prove similar.

    AI may be untrustworthy to base core internal systems on, but it’s a champion at looking for security vulnerabilities. Companies used to worry about “script kiddies” getting access to their systems, but AI attack tools are script kiddies on steroids. They can spin up distributed resources to try every known attack and look for new ones. As I’ve noted before:

    Internet applications gain usefulness from widespread adoption and the number of other components they tie into and support. You know what creates new vulnerabilities? A larger user base and the number of other components they tie into and support, which creates more attack surfaces for malicious actors to exploit.

    The flaw isn’t the fault of Random Guy in Nebraska, the fault is the company adopting software that they can’t possibly test for all the use-cases they’re going to use it for. Surprise! Just about every high tech company in the world is in the same boat. Pretty much everyone uses a wide panoply of open source tools for their Internet applications, and no one can test all the permutations of how each component might be put to use.

    You can’t eliminate the risk, you can only minimize and mitigate it. You can use containerization strategies (Docker, Kubernetes, Container D, etc.) to minimize attack surfaces and limit contagion. You can run all your code through security scanning tools on your CI/CD platform of choice. You can do constant testing and keep rolling backups of everything to limit risk and speed recovery…

    But there still a good chance that the platform you’re using today is different than the platform you’ll be using ten years from now, and you’ll have to go through the same learning lessons discovering new vulnerabilities for the new platform all over again.

    AI gives malicious actors the capability to test all potential vulnerabilities in all components virtually simultaneously, and researchers have discovered a wide variety of ways to “jailbreak” AIs to carry out such attacks, no matter what guardrails have been put in place to prevent malicious use. Theoretically, IT should do preemptive pentesting (probably with their own AI tools) to find such vulnerabilities before they can be exploited, but they were already overworked before a lot of dim executive types decided they could get by with lower headcount thanks to all this magic AI they kept hearing about.

    Hopefully this grand alliance can provide quicker answers to The AI Menace, but it’s probably going to get worse before it gets better…

    Does Malicious Backdoor Compromise SSH?

    Monday, April 1st, 2024

    A newly discovered backdoor found in the xz liblzma library of XZ Utils, the XZ format compression utilities included in most Linux distributions, targets the RSA implementation of OpenSSH.

    For those outside of tech, that sentence was an unreadable jumble of acronyms. For those inside tech, a chill probably ran down their spine, as those technologies are everywhere. Anytime anyone buys something online, they’re going to be using SSH to create a secure channel to pass transaction information. [As a commenter noted, SSH is a command tool rather than Secure Socket Layer (SSL), which is used for encrypted transactions. Mental typo. My bad. – LP.] Depending on how many distros are using that library, the consequence range from “bad” to “really, really bad.”

    Details:

    A vulnerability (CVE-2024-3094) in XZ Utils, the XZ format compression utilities included in most Linux distributions, may “enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely,” Red Hat warns.

    The cause of the vulnerability is actually malicious code present in versions 5.6.0 (released in late February) and 5.6.1 (released on March 9) of the xz libraries, which was accidentally found by Andres Freund, a PostgreSQL developer and software engineer at Microsoft.

    “After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer: The upstream xz repository and the xz tarballs have been backdoored,” he shared via the oss-security mailing list.

    According to Red Hat, the malicious injection in the vulnerable versions of the libraries is obfuscated and only included in full in the download package.

    “The Git distribution lacks the M4 macro that triggers the build of the malicious code. The second-stage artifacts are present in the Git repository for the injection during the build time, in case the malicious M4 macro is present,” they added.

    “The resulting malicious build interferes with authentication in sshd via systemd.”

    I’m just going to note for the record that a whole lot of longtime Linux programmers absolutely hated the introduction of systemd. I don’t have deep enough Linux chops to take a side in this controversy, or know whether systemd was a significant factor in allowing the exploit to work.

    Moving on:

    The malicious script in the tarballs is obfuscated, as are the files containing the bulk of the exploit, so this is likely no accident.

    “Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system. Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the “fixes” [for errors caused by the injected code in v5.6.0],” Freund commented.

    One silver lining is that the problem doesn’t look to be as widespread as it could be.

    “Luckily xz 5.6.0 and 5.6.1 have not yet widely been integrated by Linux distributions, and where they have, mostly in pre-release versions.”

    Red Hat says that the vulnerable packages are present in Fedora 41 and Fedora Rawhide, and have urged users of those distros to immediately stop using them.

    “If you are using an affected distribution in a business setting, we encourage you to contact your information security team for next steps,” they said, and added that no versions of Red Hat Enterprise Linux (RHEL) are affected.

    Since Red Hat is usually the default for big E-commerce platforms, it looks like this exploit is merely “bad” rather than “really, really bad,” which means its not nearly as bad as, say, Log4J was. Your Amazons and eBays are probably safe from the exploit.

    The people who are likely going to be hurt by this exploit are mom and pop E-commerce sites using their webhost’s “build an E-commerce site using these easy tools” feature. The smaller the site, the more likely they’re using a free distro, some of which may have this vulnerability.

    Whatever the site, they should run an updated software composition analysis tool on stacks and build-chains to see if they’re vulnerable.

    More Tech Companies Cancelling San Francisco Conferences

    Sunday, September 17th, 2023

    As a hilly, historical, picturesque city on the coast, San Francisco used to be tourist hot-spot and convention destination. But with social justice turning San Francisco into a crime and feces ridden hellhole, even local tech giants have decided it’s time to hold their conferences elsewhere.

    First Red Hat and Meta (AKA Facebook) have cancelled San Francisco conventions.

    Two major tech companies decided to cancel their San Francisco Moscone Center conferences. Software company Red Hat and Bay Area’s Meta are no longer coming to the city in 2024.

    “It’s not something we are going to turn around quickly. There are certainly companies, organizations that are deciding not to hold their events in San Francisco. We will probably see more of that,” said Rufus Jeffris, Bay Area Council spokesperson.

    A financial hit that is no surprise for the San Francisco Travel Association. According to their projections:

    “2024 continues to be a particularly challenging year for conventions in San Francisco. Although 2023 is a robust convention year, 2024 is estimated to actualize about 60% of the average,” said Jeffris.

    Snip.

    We contacted Meta and Red Hat and have not gotten a response. Yet, the Bay Area Council says safety challenges don’t help San Francisco.

    “Some of the issues in San Francisco is working hard to address. Obviously some issues of safety or cleanliness in the streets. Social problems that we are seeing on the streets are frankly a result of not only the pandemic and the after effects of that but many decades of failed policies,” said Jeffris.

    You don’t say. Reminder: The last Republican mayor of San Francisco left office in 1964. Since then an unending stream of Democrats like Dianne Feinstein, Willie Brown and Gavin Newsom have lead the city.

    Now Google has joined Red Hat and Meta in pulling their conference out of the city.

    Google is moving a technology conference out of San Francisco, as the city struggles with high crime and rampant drug use.

    The company will host its Google Cloud Next conference in Las Vegas next year, SFGATE reported. Google held the conference at the city’s Moscone Center last week, as it had from 2017-2019, for the first time since the beginning of the COVID-19 pandemic. It had planned to host the 2024 iteration of the conference in San Francisco as well, but it canceled the booking in July. Google declined to give SFGATE a specific reason for pulling the conference out of San Francisco.

    The $1.7 trillion company’s decision comes as dozens of other businesses have scaled back their operations in San Francisco as the city deals with widespread crime, homelessness, and drug use. Between 2020 and 2022, homicides increased 40 percent, and fentanyl deaths have also spiked, resulting in a number of companies pulling events, headquarters, and office space out of San Francisco.

    Salesforce may be next: “Last week, Salesforce CEO Marc Benioff said his company may pull its massive “Dreamforce” conference out of the city next year, citing public safety concerns. Benioff said this year’s conference will inject $57 million into the downtown economy.”

    Social Justice Warriors seem less concerned about injecting money into the city than into their own bank accounts, or about enabling the city’s growing population of mentally ill transients to continue injecting drugs into their veins. San Francisco will continue to wither and die as long as they’re in charge.