One of the things
ssh can do is execute a command on a remote server. Most of us expect it to work transparently when doing so, simply passing the command and its arguments on without any surprises in the process. But after 23 years of using OpenSSH on a nearly daily basis, [Martin Kjellstrand] got surprised.
It turns out that the usual rules around how things are parsed can have some troublesome edge cases when spaces are involved. [Martin] kicks off an example in the following way:
One would reasonably expect the commands
figlet foobar bar\ baz and
ssh localhost figlet foobar bar\ baz to be functionally equivalent, right? The former ultimately runs the command “figlet” with arguments “foobar” and “bar baz” on the local machine. The second does the same, except with
ssh being involved in the middle. As mentioned, one would expect both commands to be functionally identical, but that’s not what happens. What happens is that
bar\ baz into two distinctly separate command-line arguments in the process of sending it for remote execution: “bar” and “baz”. The result is mystification as the command fails to run the way the user expects, if it runs at all.
What exactly is going on, here? [Martin] goes into considerable detail tracking down this odd behavior and how it happens, but he’s unable to ultimately explain why
ssh does things this way. He suspects that it is the result of some design decision taken long ago. Or perhaps a bug that has, over time, been promoted to entrenched quirk.
Do you have any insights or knowledge about this behavior? If so, [Martin] wants to hear about it and so do we, so don’t keep it to yourself! Let us know in the comments, below.
Bluetooth has become widely popular since its introduction in 1999. However, it’s also had its fair share of security problems over the years. Just recently, a research group from the Singapore University of Technology and Design found a serious vulnerability in a large variety of Bluetooth devices. Having now been disclosed, it is known as the BrakTooth vulnerability.
Full details are not yet available; the research team is waiting until October to publicly release proof-of-concept code in order to give time for companies to patch their devices. The basic idea however, is in the name. “Brak” is the Norweigan word for “crash,” with “tooth” referring to Bluetooth itself. The attack involves repeatedly attempting to crash devices to force them into undesired operation.
The Espressif ESP32 is perhaps one of the worst affected. Found in all manner of IoT devices, the ESP32 can be fooled into executing arbitrary code via this vulnerability, which can do everything from clearing the devices RAM to flipping GPIO pins. In smart home applications or other security-critical situations, this could have dire consequences.
Other chipsets are affected to varying degrees, including parts from manufacturers like Texas Instruments and Cypress Semiconductor. Some parts are vulnerable to denial of service, while audio devices may be frozen up or shut down by the attack. The group claims over 1400 products could be affected by the bug.
Firmware patches are being rolled out, and researcher [Matheus E. Garbelini] has released code to build a sniffer device for the vulnerability on GitHub. If you’re involved with the design or manufacture of Bluetooth hardware, it might pay to start doing some homework on this one! Concerned vendors can apply for proof-of-concept test code here.
If you ever get the feeling someone is watching you, maybe they are listening, too. At least they might be listening to what’s coming over your computer speakers thanks to a new attack called “glow worm.” In this novel attack, careful observations of a power LED on a speaker allowed an attacker to reproduce the sound playing thanks to virtually imperceptible fluctuations in the LED brightness, most likely due to the speaker’s power line sagging and recovering.
You might think that if you could see the LED, you could just hear the output of the speaker, but a telescope through a window 100 feet away appears to be sufficient. You can imagine that from a distance across a noisy office you might be able to pull the same trick. We don’t know — but we suspect — even if headphones were plugged into the speakers, the LED would still modulate the audio. Any device supplying power to the speakers is a potential source of a leak.
Continue reading “Eavesdropping By LED”
[Jiska Classen] and [Dennis Mantz] created a tool called Internal Blue that aims to be a Swiss-army knife for playing around with Bluetooth at a lower level. The ground for their tool is based in three functions that are common to all Broadcom Bluetooth chipsets: one that lets you read arbitrary memory, on that lets you run it, and one that lets you write it. Well, that was easy. The rest of their work was analyzing this code, and learning how to replace the firmware with their own version. That took them a few months of hard reversing work.
In the end, Internal Blue lets them execute commands at one layer deeper — the LMP layer — easily allowing monitoring and injection. In a series of live (and successful!) demos they probe around on a Nexus 6P from a modified Nexus 5 on their desk. This is where they started digging around in the Bluetooth stack of other devices with Broadcom chipsets, and that’s where they started finding bugs.
As is often the case, [Jiska] was just poking around and found an external code handler that didn’t do bounds checking. And that meant that she could run other functions in the firmware simply by passing the
address handler offset. Since they’re essentially calling functions at any location in memory, finding which functions to call with which arguments is a process of trial and error, but the ramifications of this include at least a Bluetooth module crash and reset, but can also pull such tricks as putting the Bluetooth module into “Device Under Test” mode, which should only be accessible from the device itself. All of this is before pairing with the device — just walking by is sufficient to invoke functions through the buggy handler.
All the details of this exploit aren’t yet available, because Broadcom hasn’t fixed the firmware for probably millions of devices in the wild. And one of the reasons that they haven’t fixed it is that patching the bug will disclose where the flaw lies in all of the unpatched phones, and not all vendors can be counted on to push out updates at the same time. While they focused on the Nexus 5 cellphone, which is fairly old now, it’s applicable to any device with a similar Broadcom Bluetooth chipset.
Aside from the zero-day bug here, the big story is their Bluetooth analysis framework which will surely help other researchers learn more about Bluetooth, finding more glitches and hopefully helping make Bluetooth more openly scrutinized and more secure. Now anyone with a Raspberry Pi 3/3+ or a Nexus 5, is able to turn it into a low-level Bluetooth investigation tool.
You might know [Jiska] from her previous FitBit hack. If not, be sure to check it out.
Continue reading “35C3: Finding Bugs In Bluetooth”
For a little while it was possible to spend Bitcoin twice. Think of it like a coin on a string, you put it into the vending machine to get a delicious snack, but if you pull the string quickly enough you could spend it again on some soda too. Except this coin is worth something like eighty-grand.
On September 20, the full details of the latest fix for the Bitcoin Core were published. This information came two days after the fix was actually released. Two vulnerabilities were involved; a Denial of Service vulnerability and a critical inflation vulnerability, both covered in CVE-2018-17144. These were originally reported to several developers working on Bitcoin Core, as well as projects supporting other cryptocurrencies, including ABC and Unlimited.
Let’s take a look at how this worked, and how the network was patched (while being kept quiet) to close up this vulnerability.
Continue reading “Bitcoin’s Double Spending Flaw Was Hush-Hush During Rollout”
All the Radio Shacks are dead. adioS, or something. But wait, what’s this? There are new Radio Shacks opening. Here’s one in Idaho, and here’s another in Claremore, Oklahoma. This isn’t like the ‘Blockbuster Video in Nome, Alaska’ that clings on by virtue of being so remote; Claremore isn’t that far from Tulsa, and the one in Idaho is in a town with a population of 50,000. Are these corporate stores, or are they the (cool) independent Radio Shacks? Are there component drawers? Anyone want to take a field trip and report?
A few years ago, [cnxsoft] bought a Sonoff WiFi switch to control a well pump. Despite this being a way to control the flow of massive amounts of water with an Internet of Things thing, we’re still rocking it antediluvian style, and for the most part this WiFi-connected relay worked well. Until it didn’t. For the past few days, the switch wouldn’t connect to the network, so [cnxsoft] cracked it open to figure out why. There was one burnt component, and more than one electrocuted insect. Apparently, an ant bridged two pins, was shortly electrocuted, and toasted a resistor. It’s a bug, a real bug, in an Internet of Things thing.
eInk is coming to license plates? Apparently. Since an eInk license plate already includes some electronics, it wouldn’t be much to add some tracking hardware for a surveillance state.
Hold up, it’s a press release about crypto hardware. No, not that crypto, the other crypto. Asus has announced a new motherboard that is capable of supporting twenty graphics cards. This isn’t a six-foot-wide motherboard; it’s designed especially for coin mining, and for that, the graphics cards really only need a PCIe x1 connection. The real trick here is not using PCIe headers, and instead piping everything over vertical-mount USB ports. Yes, this is a slight cabling nightmare. So, you still think the early 80s with fluorinert waterfalls and Blinkenlights that played Game of Life was the pinnacle of style in computer hardware? No, this is it right here.
Here’s a book you should read.
When it comes to surveillance, why let the government have all the fun? This tiny spy transmitter is just the thing you need to jumpstart your recreational espionage efforts.
We kid, of course — you’ll want to stay within the law of the land if you choose to build [TomTechTod]’s diminutive transmitter. Barely bigger than the 337 button cell that powers it, the scrap of PCB packs a fair number of surface mount components, most in 0201 packages. Even so, the transmitter is a simple design, with a two transistor audio stage amplifying the signal from the MEMS microphone and feeding an oscillator that uses a surface acoustic wave (SAW) resonator for stability. The bug is tuned for the 433-MHz low-power devices band, and from the video below, it appears to have decent range with the random wire antenna — maybe 50 meters. [TomTechTod] has all the build files posted, including Gerbers and a BOM with Digikey part numbers, so it should be easy to make one for your fieldcraft kit.
If you want to dive deeper into the world of electronic espionage, boy, have we got you covered. Here’s a primer on microphone bugs, a history of spy radios, or how backscatter was used to bug an embassy.
Continue reading “Tiny Transmitter Brings Out The Spy Inside You”