This Week In Security: Linux VMs, Real AI CVEs, And Backscatter TOR DoS

Steve Ballmer famously called Linux “viral”, with some not-entirely coherent complaints about the OS. In a hilarious instance of life imitating art, Windows machines are now getting attacked through malicious Linux VM images distributed through phishing emails.

This approach seems to be intended to fool any anti-malware software that may be running. The VM includes the chisel tool, described as “a fast TCP/UDP tunnel, transported over HTTP, secured via SSH”. Now that’s an interesting protocol stack. It’s an obvious advantage for an attacker to have a Linux VM right on a target network. As this sort of virtualization does require hardware virtualization, it might be worth disabling the virtualization extensions in BIOS if they aren’t needed on a particular machine.

AI Finds Real CVE

We’ve talked about some rather unfortunate use of AI, where aspiring security researchers asked an LLM to find vulnerabilities in a project like curl, and then completely wasted a maintainer’s time on those bogus reports. We happened to interview Daniel Stenberg on FLOSS Weekly this week, and after he recounted this story, we mused that there might be a real opportunity to use LLMs to find vulnerabilities, when used as a way to direct fuzzing, and when combined with a good test suite.

And now, we have Google Project Zero bringing news of their Big Sleep LLM project finding a real-world vulnerability in SQLite. This tool was previously called Project Naptime, and while it’s not strictly a fuzzer, it does share some similarities. The main one being that both tools take their educated guesses and run that data through the real program code, to positively verify that there is a problem. With this proof of concept demonstrated, it’s sure to be replicated. It seems inevitable that someone will next try to get an LLM to not only find the vulnerability, but also find an appropriate fix. Continue reading “This Week In Security: Linux VMs, Real AI CVEs, And Backscatter TOR DoS”

Amazon Receives FAA Approval For MK30 Delivery Drone

It’s been about a decade since Amazon began to fly its delivery drones, aiming to revolutionize the online shopping experience with rapid delivery of certain items. Most recently Amazon got permission from the FAA to not only start flying from its new Arizona-based location, but also to fly beyond-visual-line-of-sight (BVLOS) missions with the new MK30 drone. We reported on this new MK30 drone which was introduced earlier this year along with the news of the Amazon Prime Air delivery service ceasing operations in California and moving them to Arizona instead.

This new drone has got twice the range as the old MK27 drone that it replaces and is said to be significantly quieter as well. The BLOS permission means that the delivery drones can service areas which are not directly visible from the warehouse with its attached drone delivery facility. With some people within the service range of the MK27 drones having previously complained about the noise levels, we will see quickly enough whether the MK30 can appease most.

As for the type of parcels you can have delivered with this service, it is limited to 2.27 kg (~5 lbs), which is plenty for medication and a range of other items where rapid delivery would be desirable.

Zinc Creep And Electroplasticity: Why Arecibo Collapsed

It’s been nearly four years since the Arecibo Telescope collapsed, an event the world got to witness in unprecedented detail thanks to strategically positioned drones. They captured breathtaking video of one of the support cables pulling from its socket as well as the spectacularly destructive results of 900 tons of scientific instruments crashing into the 300-meter primary reflector. But exactly why did those cable sockets fail?

A new report aims to answer that question, and in the process raises some interesting questions of its own. The proximate causes of the collapse have been known for a while, including the most obvious and visible one, the failure of the zinc “spelter sockets” that were cast around the splayed ends of the wire ropes to hold them in place. The new report agrees with this conclusion, at least in part, implicating “zinc creep,” or the tendency for zinc to deform over time under load. Where it appears to differ, though, is with the quality of workmanship on the sockets, finding no issues with the way the individual wires in the failed support cable were manually splayed within the socket before the molten zinc was poured. The report also points out that the collapse probably started when Hurricane Maria swept over Puerto Rico 39 months before the collapse, after which zinc creep in the sockets seemed to accelerate.

But why did the sockets fail? As the report points out, spelter sockets are commonly used to anchor cables that support heavy loads under conditions similar to the tropical climate at Arecibo. After ruling out every other cause, the committee was left with the conclusion that Arecibo itself may have been to blame for the accelerated zinc creep, thanks to electrical currents induced in the cables and sockets when the telescope’s powerful transmitters were used. They call this “long-term, low-current electroplasticity.” Electroplastic effects have been observed since the 1950s, and while far from certain that’s what happened here, the thought is that skin-effect currents induced in the support cables flowed to ground through the zinc sockets, increasing the plasticity of the metal and accelerating the zinc creep that ultimately led to collapse.

Case closed? Hardly. The electroplasticity mechanism for the Arecibo collapse offered by this report is almost a “diagnosis of exclusion” situation. It makes sense, though; since no other spelter sockets have ever failed this way in a century of use, there’s a good chance that the root cause was specific to Arecibo, and since it was once the world’s most powerful radio transmitter, it seems like a red flag that bears further investigation.

Three 3D printed, spring loaded contraptions sit on a wooden shield. There are arrow shafts connected to the end and a piece of monofilament fishing line extending away from them and through a small eyelet at the edge of. the shield.

How To Shoot Actors With Arrows Sans CGI

Today, movie effects are mostly done in CGI, especially if they’re of the death-defying type. [Tyler Bell] shows us how they shot actors with arrows before CGI.

Almost every medieval movie has someone getting shot with an arrow, but how do you do that non-destructively? [Bell] shows us two primary methods that were used, the pop up rig and steel pronged arrows. The pop up rig is a spring loaded device with one end of an arrow attached that pops up when a mechanism is triggered. [Bell] 3D printed his own version of the mechanism and shows us how it can be used to great effect on shots from the side or rear of the victim.

But what about straight on shots where the rig would be blatantly obvious? That’s when you get to actually shoot the actor (or their stunt double anyway). To do this safely, actors would wear wooden body armor under their costumes and arrows with two small prongs would be shot along a wire into the desired impact site. We appreciate [Bell] using a mannequin for testing before letting his brother shoot him with an arrow. That’s definitely the next level above a trust fall.

We even get a look at using air cannons to launch arrow storms at the end which is particularly epic. Looking for more movie magic? How about the effects from King Kong or Flight of the Navigator?

Thanks to [Xerxes3rd] on Discord for the tip!

Continue reading “How To Shoot Actors With Arrows Sans CGI”

GNSS Reception With Clone SDR Board

We love seeing the incredible work many RF enthusiasts manage to pull off — they make it look so easy! Though RF can be tricky, it’s not quite the voodoo black art that it’s often made out to be. Many radio protocols are relatively simple and with tools like gnuradio and PocketSDR you can quickly put together a small system to receive and decode just about anything.

[Jean-Michel] wanted to learn more about GNSS and USB communication. Whenever you start a project like this, it’s a good idea to take a look around at existing projects for designs or code you can reuse, and in this case, the main RF front-end board is taken from the PocketSDR project. This is then paired with a Cypress FX2 development board, and he re-wrote almost all of the PocketSDR code so that it would compile using sdcc instead of the proprietary Keil compiler. Testing involved slowly porting the code while learning about using Python 3 to receive data over USB, and using other equipment to simulate antenna diversity (using multiple antennas to increase the signal-to-noise ratio): Continue reading “GNSS Reception With Clone SDR Board”

Supercon 2024: Streaming Live

The 2024 Hackaday Supercon is on in Pasadena, but if you couldn’t make it to sunny California this year, don’t worry. We’ve got a live streams of the main stage talks, and all of the second track talks are being recorded and will be put up on the YouTube channel after the con.

If you’re watching from home and want to join the conversation, today might be a good time to join the official Hackaday Discord server.

Continue reading “Supercon 2024: Streaming Live”

Apple Forces The Signing Of Applications In MacOS Sequoia 15.1

The dialogue that greets you when you try to open an unsigned application in MacOS Sequoia 15.1.

Many MacOS users are probably used by now to the annoyance that comes with unsigned applications, as they require a few extra steps to launch them. This feature is called Gatekeeper and checks for an Apple Developer ID certificate. Starting with MacOS Sequoia 15, the easy bypassing of this feature with e.g. holding Control when clicking the application icon is now no longer an option, with version 15.1 disabling ways to bypass this completely. Not unsurprisingly, this change has caught especially users of open source software like OpenSCAD by surprise, as evidenced by a range of forum posts and GitHub tickets.

The issue of having to sign applications you run on MacOS has been a longstanding point of contention, with HomeBrew applications affected and the looming threat for applications sourced from elsewhere, with OpenSCAD issue ticket #880 from 2014 covering the saga for one OSS project. Now it would seem that to distribute MacOS software you need to have an Apple Developer Program membership, costing $99/year.

So far it appears that this forcing is deliberate on Apple’s side, with the FOSS community still sorting through possible workarounds and the full impact.

Thanks to [Robert Piston] for the tip.