This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256

March 29, 2024 by Jonathan Bennett 1 Comment

The Linux command wall is a hold-over from the way Unix machines used to be used. It’s an abbreviation of Write to ALL, and it was first included in AT&T Unix, way back in 1975. wall is a tool that a sysadmin can use to send a message to the terminal session of all logged-in users. So far nothing too exciting from a security perspective. Where things get a bit more interesting is the consideration of ANSI escape codes. Those are the control codes that moves the cursor around on the screen, also inherited from the olden days of terminals.

The modern wall binary is actually part of util-linux, rather than being a continuation of the old Unix codebase. On many systems, wall runs as a setgid, so the behavior of the system binary really matters. It’s accepted that wall shouldn’t be able to send control codes, and when processing a message specified via standard input, those control codes get rejected by the fputs_careful() function. But when a message is passed in on the command line, as an argument, that function call is skipped.

This allows any user that can send wall messages to also send ANSI control codes. Is that really a security problem? There are two scenarios where it could be. The first is that some terminals support writing to the system clipboard via command codes. The other, more creative issue, is that the output from running a binary could be overwritten with arbitrary text. Text like:
Sorry, try again. [sudo] password for jbennett:

You may have questions. Like, how would an attacker know when such a command would be appropriate? And how would this attacker capture a password that has been entered this way? The simple answer is by watching the list of running processes and system log. Many systems have a command-not-found function, which will print the failing command to the system log. If that failing command is actually a password, then it’s right there for the taking. Now, you may think this is a very narrow attack surface that’s not going to be terribly useful in real-world usage. And that’s probably pretty accurate. It is a really fascinating idea to think through, and definitively worth getting fixed. Continue reading “This Week In Security: Peering Through The Wall, Apple’s GoFetch, And SHA-256” →

Art Exhibit Lets You Hide From Self-Driving Cars

March 29, 2024 by Maya Posch 16 Comments

In the discussions about how dangerous self-driving cars are – or aren’t – one thing is sorely missing, and that is an interactive game in which you do your best to not be recognized as a pedestrian and subsequently get run over. Even if this is a somewhat questionable take, there’s something to be said for the interactive display over at the Asian Art Museum in San Francisco which has you try to escape the tyranny of machine-vision and get recognized as a crab, traffic cone, or something else that’s not pedestrian-shaped.

The display ran from March 21st to March 23rd, with [Stephen Council] of SFGate having a swing at the challenge. As can be seen in the above image, he managed to get labelled as ‘fire’ during one attempt while hiding behind a stop sign as he walked the crossing. Other methods include crawling and (ab)using a traffic cone.

Created by [Tomo Kihara] and [Daniel Coppen], it’s intended to be a ‘playful, engaging game installation’. Both creators make it clear that self-driving vehicles which use LIDAR and other advanced detection methods are much harder to fool, but given how many Teslas are on the road using camera-based systems, it’s still worth demonstrating the shortcomings of the technology.

There’s no shortage of debate about whether or not autonomous vehicles are ready to share the roads with human drivers, especially when they exhibit unusual behavior. We’ve already seen protesters attempt to confuse self-driving systems with methods that aren’t far removed from what [Kihara] and [Coppen] have demonstrated here, and it seems likely such antics will only become more common with time.

LoRA, With No Radio

March 29, 2024 by Jenny List 29 Comments

A LoRa project has traditionally required a dedicated radio module, because it’s a commercially licenced protocol. But as the way it works has been progressively reverse engineered, it’s become ever more possible to produce a LoRA radio for yourself. But what about a LoRA radio without a radio at all? [CNLohr] has managed just that, by driving a microcontroller pin and relying on one of its harmonics to provide enough RF to be received by a LoRA gateway.

The video below the break goes into the process in great detail, revealing some of the tricks. Undersampling to create intentional aliasing for example allows subharmonic peaks to be produced in unexpected places. Most of the development is performed on Espressif microcontrollers, but as the code is optimised it becomes possible to use it on much more modest silicon. The dirt cheap CH32V003 RISC-V microcontroller for example can be a LoRA transmitter able to talk to a gateway at a range of hundreds of metres with the CH32 and 2.5km with the ESP32. The code can be found in this GitHub repository.

The CH32 can’t receive of course, and it relies on barfing harmonics all over the spectrum to work. But on the other hand its total RF output is so tiny that we’re guessing a filter for the LoRA band might even make it almost legal. He’s got a little way to go before beating the record though.

Continue reading “LoRA, With No Radio” →