This Week In Security: Cisco, Mitel, And AI False Flags

There’s a trend recently, of big-name security appliances getting used in state-sponsored attacks. It looks like Cisco is the latest victim, based on a report by their own Talos Intelligence.

This particular attack has a couple of components, and abuses a couple of vulnerabilities, though the odd thing about this one is that the initial access is still unknown. The first part of the infection is Line Dancer, a memory-only element that disables the system log, leaks the system config, captures packets and more. A couple of the more devious steps are taken, like replacing the crash dump process with a reboot, to keep the in-memory malware secret. And finally, the resident installs a backdoor in the VPN service.

There is a second element, Line Runner, that uses a vulnerability to arbitrary code from disk on startup, and then installs itself onto the device. That one is a long term command and control element, and seems to only get installed on targeted devices. The Talos blog makes a rather vague mention of a 32-byte token that gets pattern-matched, to determine an extra infection step. It may be that Line Runner only gets permanently installed on certain units, or some other particularly fun action is taken.

Fixes for the vulnerabilities that allowed for persistence are available, but again, the initial vector is still unknown. There’s a vulnerability that just got fixed, that could have been such a vulnerability. CVE-2024-20295 allows an authenticated user with read-only privileges perform a command injection as root. Proof of Concept code is out in the wild for this one, but so far there’s no evidence it was used in any attacks, including the one above. Continue reading “This Week In Security: Cisco, Mitel, And AI False Flags”

Microsoft Updates MS-DOS GitHub Repo To 4.0

We’re not 100% sure which phase of Microsoft’s “Embrace, Extend, and Extinguish” gameplan this represents, but just yesterday the Redmond software giant decided to grace us with the source code for MS-DOS v4.0.

To be clear, the GitHub repository itself has been around for several years, and previously contained the source and binaries for MS-DOS v1.25 and v2.0 under the MIT license. This latest update adds the source code for v4.0 (no binaries this time), which originally hit the market back in 1988. We can’t help but notice that DOS v3.0 didn’t get invited to the party — perhaps it was decided that it wasn’t historically significant enough to include.

That said, readers with sufficiently gray beards may recall that DOS 4.0 wasn’t particularly well received back in the day. It was the sort of thing where you either stuck with something in the 3.x line if you had older hardware, or waited it out and jumped to the greatly improved v5 when it was released. Modern equivalents would probably be the response to Windows Vista, Windows 8, and maybe even Windows 11. Hey, at least Microsoft keeps some things consistent.

It’s interesting that they would preserve what’s arguably the least popular version of MS-DOS in this way, but then again there’s something to be said for having a historical record on what not to do for future generations. If you’re waiting to take a look at what was under the hood in the final MS-DOS 6.22 release, sit tight. At this rate we should be seeing it sometime in the 2030s.

Mining And Refining: Uranium And Plutonium

When I was a kid we used to go to a place we just called “The Book Barn.” It was pretty descriptive, as it was just a barn filled with old books. It smelled pretty much like you’d expect a barn filled with old books to smell, and it was a fantastic place to browse — all of the charm of an old library with none of the organization. On one visit I found a stack of old magazines, including a couple of Popular Mechanics from the late 1940s. The cover art always looked like pulp science fiction, with a pipe-smoking father coming home from work to his suburban home in a flying car.

But the issue that caught my eye had a cover showing a couple of rugged men in a Jeep, bouncing around the desert with a Geiger counter. “Build your own uranium detector,” the caption implored, suggesting that the next gold rush was underway and that anyone could get in on the action. The world was a much more optimistic place back then, looking forward as it was to a nuclear-powered future with electricity “too cheap to meter.” The fact that sudden death in an expanding ball of radioactive plasma was potentially the other side of that coin never seemed to matter that much; one tends to abstract away realities that are too big to comprehend.

Things are more complicated now, but uranium remains important. Not only is it needed to build new nuclear weapons and maintain the existing stockpile, it’s also an important part of the mix of non-fossil-fuel electricity options we’re going to need going forward. And getting it out of the ground and turned into useful materials, including its radioactive offspring plutonium, is anything but easy.

Continue reading “Mining And Refining: Uranium And Plutonium”

New JEDEC DDR5 Memory Specification: Up To 8800 MT/s, Anti-Rowhammer Features

Rapid row activations (yellow rows) may change the values of bits stored in victim row (purple row).
Row hammer” by DsimicOwn work. Licensed under CC BY-SA 4.0 via Wikimedia Commons.

As DDR SDRAM increases in density and speed, so too do new challenges and opportunities appear. In the recent DDR5 update by JEDEC – as reported by Anandtech – we see not only a big speed increase from the previous maximum of 6800 Mbps to 8800 Mbps, but also the deprecation of Partial Array Self Refresh (PASR) due to security concerns, and the introduction of Per-Row Activation Counting (PRAC), which should help with row hammer-related (security) implications.

Increasing transfer speeds is primarily a matter of timings within the limits set by the overall design of DDR5, while the changes to features like PASR and PRAC are more fundamental. PASR is mostly a power-saving feature, but can apparently be abused for nefarious means, which is why it’s now gone. As for PRAC, this directly addresses the issue of row hammer attacks. Back in the 2014-era of DDR3, row hammer was mostly regarded as a way to corrupt data in RAM, but later it was found to be also a way to compromise security and effect exploits like privilege escalation.

The way PRAC seeks to prevent this is by keeping track of how often a row is being accessed, with a certain limit after which neighboring memory cells get a chance to recover from the bleed-over that is at the core of row hammer attacks. All of which means that theoretically new DDR5 RAM and memory controllers should be even faster and more secure, which is good news all around.

A pair of hands holds a digital camera. "NUCA" is written in the hood above the lens and a black grip is on the right hand side of the device (left side of image). The camera body is off-white 3D printed plastic. The background is a pastel yellow.

AI Camera Only Takes Nudes

One of the cringier aspects of AI as we know it today has been the proliferation of deepfake technology to make nude photos of anyone you want. What if you took away the abstraction and put the faker and subject in the same space? That’s the question the NUCA camera was designed to explore. [via 404 Media]

[Mathias Vef] and [Benedikt Groß] designed the NUCA camera “with the intention of critiquing the current trajectory of AI image generation.” The camera itself is a fairly unassuming device, a 3D-printed digital camera (19.5 × 6 × 1.5 cm) with a 37 mm lens. When the camera shutter button is pressed, a nude image is generated of the subject.

The final image is generated using a mixture of the picture taken of the subject, pose data, and facial landmarks. The photo is run through a classifier which identifies features such as age, gender, body type, etc. and then uses those to generate a text prompt for Stable Diffusion. The original face of the subject is then stitched onto the nude image and aligned with the estimated pose. Many of the sample images on the project’s website show the bias toward certain beauty ideals from AI datasets.

Looking for more ways to use AI with cameras? How about this one that uses GPS to imagine a scene instead. Prefer to keep AI out of your endeavors to invade personal space? How about building your own TSA body scanner?

 

End-Of-Life For Z80 CPU And Peripherals Announced

In a Product Change Notification (PCN) published on April 15, Zilog (now owned by Littelfuse) announced the End of Life for a range of Z80 products, specifically virtually all of the Z84C00 range. This also includes the peripherals, such as the Z84C10 range of MPUs. These are currently already marked as EoL on stores like Mouser, with Littelfuse noting that the last orders with them can be placed until June 14th of 2024. After that you’ll have to try your luck with shady EBay sellers and a lucky box of old-new-stock found in the back of a warehouse.

What this effectively means is that after just under 48 years since its launch in 1976, the Zilog Z80 will no longer be available for sale as discrete components, which is likely to primarily impact hobbyists and people who are trying to keep retro systems going. This does not mean that it’s the end of the road for Z80, however, as the eZ80 will be produced for the foreseeable future.

These new chips will of course not come in easy to drop in DIPs, making the challenge of breadboarding your own Z80-based microcomputer that much tougher. Yet one thing that definitely won’t happen is any of us witnessing the end of the era of the Z80, 6502 and 8051 architectures.

Thanks to [Techokami] for the tip.

This Week In Security: Putty Keys, Libarchive, And Palo Alto

It may be time to rotate some keys. The venerable PuTTY was updated to 0.81 this week, and the major fix was a change to how ecdsa-sha2-nistp521 signatures are generated. The problem was reported on the oss-security mailing list, and it’s quite serious, though thankfully with a somewhat narrow coverage.

The PuTTY page on the vulnerability has the full details. To understand what’s going on, we need to briefly cover ECDSA, nonces, and elliptic curve crypto. All cryptography depends on one-way functions. In the case of RSA, it’s multiplying large primes together. The multiplication is easy, but given just the final result, it’s extremely difficult to find the two factors. DSA uses a similar problem, the discrete logarithm problem: raising a number to a given exponent, then doing modulo division.

Yet another cryptography primitive is the elliptic curve, which uses point multiplication as the one-way function. I’ve described it as a mathematical pinball, bouncing around inside the curve. It’s reasonably easy to compute the final point, but essentially impossible to trace the path back to the origin. Formally this is the Elliptic Curve Discrete Logarithm Problem, and it’s not considered to be quantum-resistant, either.

One of the complete schemes is ECDSA, which combines the DSA scheme with Elliptic Curves. Part of this calculation uses a nonce, denoted “k”, a number that is only used once. In ECDSA, k must be kept secret, and any repetition of different messages with the same nonce can lead to rapid exposure of the secret key.

And now we get to PuTTY, which was written for Windows back before that OS had any good cryptographic randomness routines. As we’ve already mentioned, re-use of k, the nonce, is disastrous for DSA. So, PuTTY did something clever, and took the private key and the contents of the message to be signed, hashed those values together using SHA-512, then used modulo division to reduce the bit-length to what was needed for the given k value. The problem is the 521-bit ECDSA, which takes a 521-bit k. That’s even shorter than the output of a SHA-512, so the resulting k value always started with nine 0 bits. Continue reading “This Week In Security: Putty Keys, Libarchive, And Palo Alto”