Supply Chain Attack: NPM Library Used By Facebook And Others Was Compromised

October 22, 2021 by Ryan Flowers 26 Comments

Here at Hackaday we love the good kinds of hacks, but now and then we need to bring up a less good kind. Today it was learned that the NPM package ua-parser-js was compromised, and any software using it as a library may have become victim of a supply chain attack. What is ua-parser-js and why does any of this matter?

In the early days of computing, programmers would write every bit of code they used themselves. Larger teams would work together to develop larger code bases, but it was all done in-house. These days software developers don’t write every piece of code. Instead they use libraries of code supplied by others.

For better or worse, repositories of code are now available to do even the smallest of functions so that a developer doesn’t have to write the function from scratch. One such registry is npm (Node Package Manager), who organize a collection of contributed libraries written in JavaScript. One only need to use npm to include a library in their code, and all of the functions of that code are available to the developer. One such example is ua-parser-js which is a User Agent Parser written in JavaScript. This library makes it easy for developers to find out the type of device and software being used to access a web page.

On October 22 2021, the developer of ua-parser-js found that attackers had uploaded a version of his software that contained malware for both Linux and Windows computers. The malicious versions were found to steal data (including passwords and Chrome cookies, perhaps much more) from computers or run a crypto-currency miner. This prompted GitHub to issue a Critical Severity Security Advisory.

What makes this compromise so dangerous is that ua-parser-js is considered to be part of a supply chain, and has been adopted even by Facebook for use in some of its customer facing software. The developer of ua-parser-js has already secured his GitHub account and uploaded new versions of the package that are clean. If you have any software that uses this library, make sure you’ve got the latest version!

Of course this is by no means a unique occurrence. Last month Maya Posch dug into growing issues that come from some flaws of trust in package management systems. The art for that article is a house of cards, an apt metaphor for a system that is only as stable as the security of each and every package being built upon.

Vizio In Hot Water Over Smart TV GPL Violations

October 22, 2021 by Tom Nardi 70 Comments

As most anyone in this community knows, there’s an excellent chance that any consumer product on the market that’s advertised as “smart” these days probably has some form of Linux running under the hood. We’re also keenly aware that getting companies to hold up their end of the bargain when it comes to using Linux and other GPL licensed software in their products, namely releasing their modified source, isn’t always as cut and dried as it should be.

Occasionally these non-compliant companies will get somebody so aggravated that they actually try to do something about it, which is where smart TV manufacturer Vizio currently finds itself. The Software Freedom Conservancy (SFC) recently announced they’re taking the Irvine, California based company to court over their repeated failures to meet the requirements of the GPL while developing their Linux-powered SmartCast TV firmware. In addition to the Linux kernel, the SFC also claims Vizio is using modified versions of various other GPL and LGPL protected works, such as U-Boot, bash, gawk, tar, glibc, and ffmpeg.

According to the SFC press release, the group isn’t looking for any monetary damages. They simply want Vizio to do what’s required of them as per the GPL and release the SmartCast source code, which they hope will allow for the development of an OpenWrt-like replacement firmware for older Vizio smart TVs. This is particularly important as older models will often stop receiving updates, and in many cases, will no longer be able to access all of the services they were advertised as being able to support. Clearly the SFC wants this case to be looked at as part of the larger Right to Repair debate, and given the terrible firmware we’ve seen some of these smart TVs ship with, we’re inclined to agree.

Now of course, we’ve seen cases like this pop up in the past. But what makes this one unique is that the SFC isn’t representing one of the developers who’s software has been found to be part of Vizio’s SmartCast, they’re actually the plaintiff. By taking the position of a consumer who has purchased a Vizio product that included GPL software, the SFC is considered a third-party beneficiary, and they are merely asking the court to be given what’s due to them under the terms of the license.

As firm believers in the open source movement, we have zero tolerance for license violators. Vizio isn’t some wide-eyed teen, randomly copying code they found from GitHub without understanding the implications. This is a multi-billion dollar company that absolutely should know better, and we’ll be happy to see them twist in the wind a bit before they’re ultimately forced to play by the rules.

Basics Of Remote Cellular Access: Watchdogs

October 14, 2021 by Lewin Day 21 Comments

When talking about remote machines, sometimes we mean really remote, beyond the realms of wired networks that can deliver the Internet. In these cases, remote cellular access is often the way to go. Thus far, we’ve explored the hardware and software sides required to control a machine remotely over a cellular connection.

However, things can and do go wrong. When that remote machine goes offline, getting someone on location to reboot it can be prohibitively difficult and expensive. For these situations, what you want is some way to kick things back into gear, ideally automatically. What you’re looking for is a watchdog timer!

Continue reading “Basics Of Remote Cellular Access: Watchdogs” →

Software Removes The Facebook From Facebook’s VR Headset (Mostly)

October 13, 2021 by Donald Papp 18 Comments

It’s not a jailbreak, but [basti564]’s Oculess software nevertheless allows one the option to remove telemetry and account dependencies from Facebook’s Oculus Quest VR headsets. It is not normally possible to use these devices without a valid Facebook account (or a legacy Oculus account in the case of the original Quest), so the ability to flip any kind of disconnect switch without bricking the hardware is a step forward, even if there are a few caveats to the process.

To be clear, the Quest devices still require normal activation and setup via a Facebook account. But once that initial activation is complete, Oculess allows one the option of disabling telemetry or completely disconnecting the headset from its Facebook account. Removing telemetry means that details about what apps are launched, how the device is used, and all other usage-related data is no longer sent to Facebook. Disconnecting will log the headset out of its account, but doing so means apps purchased from the store will no longer work and neither will factory-installed apps like Oculus TV or the Oculus web browser.

What will still work is the ability to sideload unsigned software, which are applications that are neither controlled nor distributed by Facebook. Sideloading isn’t on by default; it’s enabled by putting the headset into Developer Mode (a necessary step to installing Oculess in the first place, by the way.) There’s a fairly active scene around unsigned software for the Quest headsets, as evidenced by the existence of the alternate app store SideQuest.

Facebook’s control over their hardware and its walled-garden ecosystem continues to increase, but clearly there are people interested in putting the brakes on where they can. It’s possible the devices might see a full jailbreak someday, but even if so, what happens then?

Python Provides Classic Basic

October 8, 2021 by Al Williams 22 Comments

Back in the late 1970s and early 1980s when you turned on a PC, more often than not, you’d get a Basic prompt. Most people would then load a game from a tape, but if you were inclined to program you could just start writing. [Richpl] wanted that same experience and thus PyBasic was born. Along with some other Github contributors, the system has grown quite a bit and would be a good start at porting classic games or creating a replica vintage computer.

The interpreter lacks specialized hardware-specific features such as sound and graphics, of course, but then again, you could add them. It does have file I/O and also includes some interesting features like an analog of C’s ternary operator.

Continue reading “Python Provides Classic Basic” →

Linux Fu: Globs Vs Regexp

October 7, 2021 by Al Williams 17 Comments

I once asked a software developer at work how many times we called fork() in our code. I’ll admit, it was a very large project, but I expected the answer to be — at most — two digits. The developer came back and read off some number from a piece of paper that was in the millions. I told them there was no way we had millions of calls to fork() and, of course, we didn’t. The problem was the developer wasn’t clear on the difference between a regular expression and a glob.

Tools like grep use regular expressions to create search patterns. I might write [Hh]ack ?a ?[Dd]ay as a regular expression to match things like “HackaDay” and “Hack a day” and, even, “Hackaday” using a tool like grep, awk, or many programming languages.

Continue reading “Linux Fu: Globs Vs Regexp” →

BFree Brings Intermittent Computing To Python

September 29, 2021 by Tom Nardi 16 Comments

Generally speaking, we like our computing devices to remain on and active the whole time we’re using them. But there are situations, such as off-grid devices that run on small solar cells, where constant power is by no means a guarantee. That’s where the concept of intermittent computing comes into play, and now thanks to the BFree project, you can develop Python software that persists even when the hardware goes black.

Implemented as a shield that attaches to a Adafruit Metro M0 Express running a modified CircuitPython interpreter, BFree automatically makes “checkpoints” as the user’s code is running so that if the power is unexpectedly cut, it can return the environment to a known-good state instantaneously. The snapshot of the system, including everything from the variables stored in memory to the state of each individual peripheral, is stored on the non-volatile FRAM of the MSP430 microcontroller on the BFree board; meaning even if the power doesn’t come back on for weeks or months, the software will be ready to leap back into action.

In addition to the storage for system checkpoints, the BFree board also includes energy harvesting circuity and connections for a solar panel and large capacitor. Notably, the system has no provision for a traditional battery. You can keep the Metro M0 Express plugged in while developing your code, but once you’re ready to test in the field, the shield is in charge of powering up the system whenever it’s built up enough of a charge.

The product of a collaboration between teams at Northwestern University and Delft University of Technology, BFree is actually an evolution of the battery-free handheld game they developed around this time last year. While that project was used to raise awareness of how intermittent computing works, BFree is clearly a more flexible platform, and is better suited for wider experimentation.

We’ve seen a fair number of devices that store up small amounts of energy over the long term for quick bouts of activity, so we’re very interested to see what the community can come up with when that sort of hardware is combined with software that can be paused until its needed.