Et Tu, Red Hat?

Something odd happened to git.centos.org last week. That’s the repository where Red Hat has traditionally published the source code to everything that’s a part of Red Hat Enterprise Linux (RHEL) to fulfill the requirements of the GPL license. Last week, those packages just stopped flowing. Updates weren’t being published. And finally, Red Hat has published a clear answer to why:

Red Hat has decided to continue to use the Customer Portal to share source code with our partners and customers, while treating CentOS Stream as the venue for collaboration with the community.

Sounds innocuous, but what’s really going on here? Let’s have a look at the Red Hat family: RHEL, CentOS, and Fedora.

RHEL is the enterprise Linux distribution that is Red Hat’s bread and butter. Fedora is RHEL’s upstream distribution, where changes happen fast and things occasionally break. CentOS started off as a community repackaging of RHEL, as allowed under the GPL and other Open Source licenses, for people who liked the stability but didn’t need the software support that you’re paying for when you buy RHEL.

Red Hat took over the reigns of CentOS back in 2014, and then imposed the transition to CentOS Stream in 2020, to some consternation. This placed CentOS Stream between the upstream Fedora, and the downstream RHEL. Some people missed the stability of the old CentOS, and in response a handful of efforts spun up to fill the gap, like Alma Linux and Rocky Linux. These projects took the source from git.centos.org, and rebuilt them into usable community operating systems, staying closer to RHEL in the process.

Red Hat has published a longer statement elaborating on the growth of CentOS Stream, but it ends with an interesting statement: “Red Hat customers and partners can access RHEL sources via the customer and partner portals, in accordance with their subscription agreement.” What exactly is in that subscription agreement? Well according to Alma Linux, “the way we understand it today, Red Hat’s user interface agreements indicate that re-publishing sources acquired through the customer portal would be a violation of those agreements.” Continue reading “Et Tu, Red Hat?”

This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride

There’s a fun logic flaw in how multiple online services handle OAuth logins, that abuses Microsoft’s Azure Active Directory service to allow account takeovers. The problem is how a site handles the “Sign In With Microsoft” option, when there’s an existing account under the same email address. This is an irritating problem for an end-user, when a site offers multiple sign-in options. Trying to remember which option was used to set up an account is a struggle, so many services automatically merge accounts.

The problem is that the Microsoft Azure authentication information includes an email address, but Microsoft hasn’t done any verification that the account in question actually controls that address. And in fact, it’s trivial for the Azure admin to change that address at whim. So if the service accepts that email address as authoritative, and auto-merges the accounts, it’s a trivial account takeover. And it’s more than just a theoretical problem, as researchers at descope were able to demonstrate the attack, and have found multiple medium and large services that were vulnerable, as well as at least two authentication providers that themselves were vulnerable to this attack.

Microsoft has pushed updates to the Azure AD service to make the issue easier to avoid, though it seems that the unverified “email” field is still being sent on authentication transactions. There is a new flag, “RemoveUnverifiedEmailClaim” that eliminates the issue, and is enabled by default for new applications. Unfortunately this means that existing vulnerable applications will continue to be vulnerable until fixed on the application side. Continue reading “This Week In Security: NOAuth, MiniDLNA, And Ticket To Ride”

An Unexpected Upset In EV Charging Standards

Last November, Tesla open-sourced parts of its charging infrastructure, not-so-humbly unveiling it as the North American Charging Standard (NACS). It’s finally taking off with a number of manufacturers signing on.

Companies launching “standards” based on their previously proprietary technology in opposition to an established alternative usually leads to standards proliferation. However, with recent announcements from Ford, GM, and Rivian that they would begin supporting NACS in their vehicles, it seems a new dominant standard is supplanting CCS (and the all-but-dead CHAdeMO) in North America.

As Tesla already has the most extensive charging network on the continent and has begun opening it up for other EVs, it makes sense that other marques would want to support NACS, if nothing else to satiate customer demand for a dead-simple charging experience. Dongles are annoying enough for plugging in an external monitor. Having to mess with one while handling high-power electrical connections is less than ideal, to say the least.

If you want to add NACS to your own EV project, the standard is here. We’ve discussed some of the different standards before as well as work toward wirelessly charging EVs (besides the inductive charger on the EV1). It certainly seems like the time to get in on the ground floor of an EV charging empire with an army of Charglas.

Intel To Ship Quantum Chip

In a world of 32-bit and 64-bit processors, it might surprise you to learn that Intel is releasing a 12-bit chip. Oh, wait, we mean 12-qubit. That makes more sense. Code named Tunnel Falls, the chip uses tiny silicon spin quantum bits, which Intel says are more advantageous than other schemes for encoding qubits. There’s a video about the device below.

It is a “research chip” and will be available to universities that might not be able to produce their own hardware. You probably aren’t going to find them listed on your favorite online reseller. Besides, the chip isn’t going to be usable on a breadboard. It is still going to take a lot of support to get it running.

Intel claims the silicon qubit technology is a million times smaller than other qubit types. The size is on the order of a device transistor — 50 nanometers square — simplifying things and allowing denser devices. In silicon spin qubits, information resides in the up or down spin of a single electron.

Of course, even Intel isn’t suggesting that 12 qubits are enough for a game-changing quantum computer, but you do have to start somewhere. This chip may enable more researchers to test the technology and will undoubtedly help Intel accelerate its research to the next step.

There is a lot of talk that silicon is the way to go for scalable quantum computing. It makes you wonder if there’s anything silicon can’t do? You can access today’s limited quantum computers in the proverbial cloud.

Continue reading “Intel To Ship Quantum Chip”

This Week In Security: ACME.sh, Leaking LEDs, And Android Apps

Let’s Encrypt has made an enormous difference to the landscape of the web. The protocol used for authenticating and receiving certificates, ACME, has spawned quite a few clients of various flavors. Some are written in Rust, some in Python or Go, and a few in straight Bash shell script. One of those last ones, acme.sh, was doing something odd when talking to a particular “Certificate Authority”, HiCA. This pseudo-CA only supports acme.sh, and now we know why. The folks behind HiCA found an RCE exploit in acme.sh, and decided to use that exploit to do certificate issuance with more “flexability”. Oof.

The nuts and bolts here is that HiCA was working as a CA-in-the-Middle, wrapping other CA’s authentication services. Those services don’t support ACME authentication at all, and HiCA used the acme.sh vulnerability to put the authentication token in the place SSL.com expected to find it. So, just a good community member offering a service that ACME doesn’t quite support, right?

Well, maybe not so innocent. The way it appears this works, is that the end user sends a certificate request to HiCA. HiCA takes that information, and initiates a certificate request off to SSL.com. SSL.com sends back a challenge, and HiCA embeds that challenge in the RCE and sends it to the end user. The end user’s machine triggers the RCE, which pushes the challenge token to the well-known location, and bypasses the ACME protection against exactly this sort of CA-in-the-middle situation.

The last piece of the authentication process is that the signing server reaches out over HTTP to the domain being signed, and looks for the token to be there. Once found, it sends the signed certificates to HiCA, who then forward them on to the end user. And that’s the problem. HiCA has access to the key of every SSL cert they handled. This doesn’t allow encryption, but these keys could be used to impersonate or even launch MitM attacks against those domains. There’s no evidence that HiCA was actually capturing or using those keys, but this company was abusing an RCE to put itself in the position to have that ability.

The takeaway is twofold. First, as an end user, only use reputable CAs. And second, ACME clients need to be hardened against potentially malicious CAs. The fact that HiCA only supported the one ACME client was what led to this discovery, and should have been a warning flag to anyone using the service. Continue reading “This Week In Security: ACME.sh, Leaking LEDs, And Android Apps”

The FPGA board in question which was programmed to run the algorithm. (Source: iranintl)

Iran’s Military Quantum Claim: It’s Only 99.4% Ridiculous

When Iran recently announced a quantum processing algorithm (Google translation) that would help its military to detect water surface disturbances, the instant response from Western media was one of ridicule, based on the displayed hardware. The hardware in question was the Digilent ZedBoard Zynq-7000 hybrid SoC/FPGA development board, which can be yours for less than $600.

Seems absurd, and the claim about any realistic military use absolutely is. But buried deep, deep down, there may be a tiny kernel of truth: because quantum computers are inherently parallel, FPGAs can make a good fit for small-scale quantum simulations.

Does this mean that the Iranian Navy would be better off simulating quantum circuits on an FPGA board than on a GPU or even a used laptop? Probably not. Will this hardware serve the proposed military application in the forseeable future? Absolutely not! Was this a misleading and ridiculous photo op? Yup. 100%.

But is emulating qubits in FPGA fabric a real thing? Turns out it is! Let’s have a look.

Continue reading “Iran’s Military Quantum Claim: It’s Only 99.4% Ridiculous”

Raspberry Pi Pico W Now Supports Bluetooth

What’s the best kind of upgrade a piece of consumer technology can get? A free one that doesn’t require you to do anything other than accept a new version of the software it’s running.

That’s precisely what every current (and future) owner of the Raspberry Pi Pico W just got with the addition of Bluetooth support to SDK 1.5.1. This is possible because the CYW43439 radio chipset used on the wireless version of the Pi Pico has always had Bluetooth capabilities, they just weren’t officially accessible from the C or MicroPython environments until now. In a corresponding blog post, [Eben Upton] explains that part of the delay was due to difficulties in getting both WiFi and Bluetooth connections to work simultaneously over the three-pin SPI bus that links the two chips on the board.

One thing that struck us as particularly interesting here is the use of BlueKitchen’s BTStack to provide support for both Bluetooth Classic and Low Energy profiles. This library is released under a modified version of the BSD 3-Clause license that otherwise specifically forbids commercial usage. That would be a problem for anyone who wanted to sell a gadget built around the Pico W, so Raspberry Pi Ltd negotiated — and presumably paid for — a special dispensation so commercial use is in the clear.

We should note that technically Bluetooth support was available in a beta state previously, albeit without this new license agreement made with BlueKitchen. Though anyone with a keen eye knew Bluetooth support was coming well before that, our own [Elliot Williams] called it when he first set eyes on the Pi Pico W back in 2022.