This Week In Security: Not A Vulnerability, BGP Bug Propogation, And Press Enter To Hack

September 1, 2023 by Jonathan Bennett 6 Comments

Curl was recently notified of a CVE, CVE-2020-19909, rated at a hair-raising 9.8 on the CVSS scale. And PostgreSQL has CVE-2020-21469, clocking in with a 7.5 severity. You may notice something odd about those two vulnerabilities, but I promise the 2020 date is only the tip of the iceberg here.

Let’s start with PostgreSQL. That vulnerability was only present in version 12.2, which released in February of 2020, and was fixed with the 12.3 release in May of that same year. The problem is a stack buffer overflow, which doesn’t seem to enable code execution, but does cause a denial of service situation. To trigger the bug? Repeatedly send the PostgreSQL daemon the SIGHUP signal.

If you’re familiar with Linux signals, that might sound odd. See, the SIGHUP signal technically indicates the end of a user session, but most daemons use it to indicate a restart or reload request. And to send this signal, a user has to have elevated privileges — elevated enough to simply stop the daemon altogether. Put simply, it’s not a security vulnerability, just a minor bug.

And now on to curl — This one is just bizarre. The issue is a integer overflow in the --retry-delay argument, which specifies in seconds how often curl should retry a failing download. The value is multiplied by 1000 to convert to milliseconds, resulting in an overflow for very large values. The result of that overflow? A smaller value for the retry delay.

[Daniel Stenberg] makes the point that this tale is a wonderful demonstration of the brokenness of the CVE system and NVD’s handling of it. And in this case, it’s hard not to see this as negligence. We have to work really hard to construct a theoretical scenario where this bug could actually be exploited. The best I’ve been able to come up with is an online download tool, where the user can specify part of the target name and a timeout. If that tool had a check to ensure that the timeout was large enough to avoid excess traffic, this bug could bypass that check. Should we be assigning CVEs for that sort of convoluted, theoretical attack?

But here’s the thing, that attack scenario should rate something like a CVSS of 4.8 at absolute worst. NVD assigned this a 9.8. There’s no way you can squint at this bug hard enough to legitimately rank it that severe. At the time of writing, the NVD lists this as “UNDERGOING REANALYSIS”.
Continue reading “This Week In Security: Not A Vulnerability, BGP Bug Propogation, And Press Enter To Hack” →

Diving Into Starlink’s User Terminal Firmware

August 31, 2023 by Maya Posch 7 Comments

The average Starlink user probably doesn’t spend a lot of time thinking about their hardware after getting the dish aligned and wiring run. To security researchers, however, it’s another fascinating device to tinker with as they reverse-engineer the firmware and try to both find out what makes it tick, as well as how to break it. This is essentially the subject of [Carlo Ramponi]’s article over at Quarkslab as he digs into the firmware architecture and potential weaknesses in its internal communication.

The user terminal hardware itself is a quite standard AArch64 ARM-based SoC, along with the proprietary communication interface, all of which is controlled by the Linux-based firmware. Dumping the firmware itself was made easy thanks to existing work by researchers at the KU Leuven, involving dumping the contents of the onboard eMMC storage. After this the firmware architecture could be analyzed, which turned out to consist out of mostly C++-based binaries, but with a single big binary for the user front-end written in Go.

Communication between these processes is handled through a custom inter-process protocol called ‘Slate Sharing’, all of which is coordinated via the core User Terminal Control process. It are these Slate IPC messages which form the most likely attack surface for a fuzzing attack, with the SoftwareUpdateRequest command being an interesting target as it would seem to not require authentication since it doesn’t address a specific user. This work is part of [Carlo]’s master’s thesis, and should form the basis of further research on the Starlink User Terminal firmware.

Logic Analyzers: Tapping Into Raspberry Pi Secrets

August 31, 2023 by Arya Voronova 46 Comments

Today, I’d like to highlight a tool that brings your hacking skills to a whole new level, and does that without breaking the bank – in fact, given just how much debugging time you can save, how many fun pursuits you can unlock, and the numerous features you can add, this might be one of the cheapest tools you will get. Whether it’s debugging weird problems, optimizing your code, probing around a gadget you’re reverse-engineering, or maybe trying to understand someone’s open-source library, you are likely missing out a lot if you don’t have a logic analyzer on hand!

It’s heartbreaking to me that some hackers still don’t know the value that a logic analyzer brings. Over and over again, tactical application of a logic analyzer has helped me see an entirely different perspective on something I was hacking on, and that’s just the thing I’d like to demonstrate today.

Diving In

A logic analyzer has a number of digital inputs, and it continuously reads the state of these digital inputs, sending them to your computer or showing them on a screen – it’s like a logic-level-only oscilloscope. If you have an I2C bus with one MCU controlling a sensor, connect a logic analyzer to the clock and data pins, wire up the ground, launch the logic analyzer software on your computer, and see what’s actually happening.

For instance, have you ever noticed the ID_SC and ID_SD pins on the Raspberry Pi GPIO connector? Are you wondering what they’re for? Don’t you want to check what actually happens on these pins? Let’s do that right now! Continue reading “Logic Analyzers: Tapping Into Raspberry Pi Secrets” →

ACK1 Makes Getting To Know The ATtiny1616 Easy

August 30, 2023 by Julian Scheffers 13 Comments

Many readers will be familiar with Microchip’s ATtiny85, which has been a popular choice for DIY projects in the past for its low price and (for the time) small size. But those looking for a more modern and capable 8-bit chip may find the ATtiny1616-MNR of interest. It offers expanded flash storage, more GPIO, and ditches SPI programming in favor of UPDI — a protocol that can be done using nothing more than an USB-UART converter and a resistor.

The contents of the ACK1 kit — What’s in the kit if you buy it.

But here’s the catch: the new chip is only available in SMD and there are far fewer tutorials for it! That’s why [Bradán Lane] has created ACK1, a cute little AVR Coding Kit for those of us who want to play with the ATtiny1616 and a companion for his free and open-source course.

The board contains an array of 6 by 7 LEDs in a charlieplexed configuration, a large piezo buzzer, two push buttons, an on/off switch, and a CR2032 battery holder to keep it on without the need for a cable. The kit looks gorgeous in its white-on-black theme with gold plated contacts and can be had for $20 on Tindie at the time of writing.

The ATtiny1616 itself runs at up to 20 MHz and has 17 GPIO pins, 16 KiB of flash storage, 2 KiB of RAM, and 256 bytes of EEPROM for configuration — making it roughly on par with the original Arduino Uno.

The course that goes hand-in-hand with the ACK1 is all about the features of the ATtiny1616, from the basics of using the programmer to reading the buttons, using timers, driving the charlieplexed LEDs, storing data in the EEPROM and much more. Though it does not cover the basics of C, the course is free, and even licensed MIT, so that anyone can share it and improve upon it.

If you enjoy seeing beautiful microcontrollers, you’ll definitely want to see the stylish Uno Plus+.

Wireless Data Connections Through Light

August 25, 2023 by Bryan Cockfield 38 Comments

When wired networking or data connections can’t be made, for reasons of distance or practicality, various wireless protocols are available to us. Wi-Fi is among the most common, at least as far as networking personal computers is concerned, but other methods such as LoRa or Zigbee are available when data rates are low and distances great. All of these methods share one thing in common, though: their use of radio waves to send data. Using other parts of the electromagnetic spectrum is not out of the question, though, and [mircemk] demonstrates using light as the medium instead of radio.

Although this isn’t a new technology (“Li-Fi” was first introduced in 2011) it’s not one that we see often. It does have a few benefits though, including high rates of data transmission. In this system, [mircemk] is using an LED to send the information and a solar cell as the receiver. The LED is connected to a simple analog modulator circuit, which takes an audio signal as its input and sends the data to the light. The solar cell sends its data, with the help of a capacitor, straight to the aux input on a radio which is used to convert the signal back to audio.

Some of the other perks of a system like this are seen here as well. The audio is clear even as the light source and solar cell are separated at a fairly significant distance, perhaps ten meters or so. This might not seem like a lot compared to Wi-Fi, but another perk shown is that this method can be used within existing lighting systems since the modulation is not detectable by the human eye. Outside of a home or office setting, systems like these can also be used to send data much greater distances as well, as long as the LED is replaced with a laser.

Continue reading “Wireless Data Connections Through Light” →

UChaser Follows You Anywhere

August 15, 2023 by Matthew Carlson 16 Comments

If you’ve been making up for lost years of travel in 2023, you might have seen a fellow traveler in the airport terminal or train station walking with their luggage happily careening behind them. [Jesse R] and [Brian Lindahl] wanted more of that. They wanted an open-source, low-cost system that could be put in anything.

The basic principle is that they will have a transmitter that sends both a radio signal and an ultrasonic pulse. The receiver receives the radio signal and uses it as a reference for the two ultrasonic sensors. The time since the radio signal is compared between the two, and a distance and direction are established.

In practice, the radio is an ESP32-S3 using ESP-NOW (which we’ve seen relatively recently on another project), a protocol from Espressif that offers low latency 250 bytes payloads. The ultrasonic transceiver is based on Sparkfun’s HC-SR04. For prototyping purposes on the receiver, they just removed the transmitter to avoid populating the airwaves, as to listen, you had to transmit. The prototype was an electric wheelbarrow that would happily follow you around the yard wherever you go.

With the concept validated, they moved to a custom ultrasonic setup with a custom buffer amp and damp transistor, all centered around 20kHz. The simulations suggested they should have been better than the HC-SR04 from Sparkfun, but the 30-foot (9 meters) range went to 10 feet (3 meters). They ultimately returned to using Sparkfun’s circuit rather than the custom amp.

We’re looking forward to seeing the project continue. There are various challenges, such as variability in the speed of sound, echos and reflections, and ultrasonic line of sight. We love the peak behind the curtain that allows us to see what decisions get made and the data that informs those decisions. All the code and PCB design files are available on GitHub under an MIT and Creative Common license, respectively. This project was submitted as part of the 2o23 Hackaday Prize.

Video after the break.

Continue reading “UChaser Follows You Anywhere” →

Screwdrivers And Nuclear Safety: The Demon Core

August 15, 2023 by Al Williams 61 Comments

Harry Daghlian and Louis Slotin were two of many people who worked on the Manhattan Project. They might not be household names, but we believe they are the poster children for safety procedures. And not in a good way.

Harry Daghlian (CC-BY-SA 3.0, Arnold Dion)

Slotin assembled the core of the “Gadget” — the plutonium test device at the Trinity test in 1945. He was no stranger to working in a lab with nuclear materials. It stands to reason that if you are making something as dangerous as a nuclear bomb, it is probably hazardous work. But you probably get used to it, like some of us get used to working around high voltage or deadly chemicals.

Making nuclear material is hard and even more so back then. But the Project had made a third plutonium core — one was detonated at Trinity, the other over Nagasaki, and the final core was meant to go into a proposed second bomb that was not produced.

The cores were two hemispheres of plutonium and gallium. The gallium allowed the material to be hot-pressed into spherical shapes. Unlike the first two cores, however, the third one — one that would later earn the nickname “the demon core” — had a ring around the flat surfaces to contain nuclear flux during implosion. The spheres are not terribly dangerous unless they become supercritical, which would lead to a prompt critical event. Then, they would release large amounts of neutrons. The bombs, for example, would force the two halves together violently. You could also add more nuclear material or reflect neutrons back into the material.

Continue reading “Screwdrivers And Nuclear Safety: The Demon Core” →