So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasn’t sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, making it much harder to “win the lottery” with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.
uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function has some odd behavior. When generating DNS requests, the TXID is incremental — it’s predictable and not randomized. Additionally, the TXID will periodically reset back to it’s initial value, so not even the entire 16-bit key space is exercised. Not great. Continue reading “This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat”→
At this point, we’ve all heard how the chip shortage is impacting the big players out there. It makes sense that automakers are feeling the pressure, since they are buying literally millions of components at a clip. But stories like this are a reminder that even an individual’s hobby project can be sidelined by parts that are suddenly 40 times as expensive as they were when you first put them in your bill of materials.
In this particular case, [Walker] explains that a power management chip you could get on DigiKey for $1.20 USD a few months ago is now in such short supply that the best offer he’s found so far is $49.70 a pop from an electronics broker in Shenzhen. It sounds like he’s going to bite the bullet and buy the four of them (ouch) that he needs to build a working prototype, but obviously it’s a no go for production.
Luckily, it’s not all bad news. [Walker] has made some good progress on the power supply board, which will eventually join the diminutive computer inside the USB charger enclosure. Part of the trick is that the device is still supposed to be a functional USB charger, so in addition to 5 VDC for the output port, the power supply also needs to produce 1.1 V, 1.35 V, 2.5 V, 3.0 V, and 3.3 V for the computer. We’re glad to see he’s taking the high road with his mains circuitry, making sure to use UL listed components and maintaining proper isolation.
When we last checked in on the WiFiWart back in July, [Walker] had already managed to boot Linux on his over-sized prototype board. Now he’s got PCBs in hand that look far closer to the final size and shape necessary to tuck them into a phone charger. It’s a shame that the parts shortage is slowing down progress, but we’re confident we’ll at least get to see a one-off version of the WiFiWart powered up before the year is out.
A PoC was just published for a potentially serious flaw in the Ghostscript interpreter. Ghostscript can load Postscript, PDF, and SVG, and it has a feature from Postscript that has been a continual security issue: the %pipe% command. This command requests the interpreter to spawn a new process — It’s RCE as part of the spec. This is obviously a problem for untrusted images and documents, and Ghostscript has fixed security vulnerabilities around this mis-feature several times over the years.
This particular vulnerability was discovered by [Emil Lerner], and described at ZeroNights X. That talk is available, but in Russian. The issue seems to be a bypass of sorts, where the pipe command appears to be working in the /tmp/ directory, but a simple semicolon allows for an arbitrary command to be executed. Now why is this a big deal? Because ImageMagick uses Ghostscript to open SVG images by default on some distributions, and ImageMagick is often used for automatically resizing and converting images for web sites. In [Emil]’s presentation, he uses this flaw as part of an attack chain against three different companies.
I was unable to reproduce the flaw on my Fedora install, but I haven’t found any notice of it being fixed in the Ghostscript or Imagemagick changelogs either. It’s unclear if this problem has already been fixed, or if this is a true 0-day for some platforms. Either way, expect attackers to start trying to make use of it.
Creality, makers of the Ender series of 3D printers, have released a product called Wi-Fi Box meant to cheaply add network control to your printer. Naturally I had to order one so we could take a peek, but this is certainly not a product review. If you’re looking to control your 3D printer over the network, get yourself a Raspberry Pi and install Gina Häußge’s phenomenal OctoPrint on it. Despite what Creality might want you to believe, their product is little more than a poor imitation of this incredible open source project.
Even if you manage to get it working with your printer, which judging by early indications is a pretty big if, it won’t give you anywhere near the same experience. At best it’ll save you a few dollars compared to going the DIY route, but at the cost of missing out on the vibrant community of plugin developers that have helped establish OctoPrint as the defacto remote 3D printing solution.
That being said, the hardware itself seems pretty interesting. For just $20 USD you get a palm-sized Linux computer with WiFi, Ethernet, a micro SD slot, and a pair of USB ports; all wrapped up in a fairly rugged enclosure. There’s no video output, but that will hardly scare off the veteran penguin wrangler. Tucked in a corner and sipping down only a few watts, one can imagine plenty of tasks this little gadget would be well suited to. Perhaps it could act as a small MQTT broker for all your smart home devices, or a low-power remote weather station. The possibilities are nearly limitless, assuming we can get into the thing anyway.
So what’s inside the Creality Wi-Fi Box, and how hard will it be to bend it to our will? Let’s take one apart and find out.
Have you ever wanted to watch someone reverse engineer a piece of hardware and pick up some tips? You can’t be there while [Jeremy] tears open a Netgear N300 router, but you can see his process step by step in some presentation charts, and you’ll get a few ideas for the next time you want to do something like this.
The first part of the presentation might be a little basic for most Hackaday readers, but presumably, the intended audience might not know much about soldering or multimeters. But we enjoyed the methodology used to work out the UART pins on the board. We would have read the baud rate with the scope, which [Jeremy] does, but he also mentions a script to work it out and create a minicom profile that looked interesting.
With everything else going on this summer, you might be forgiven for not keeping abreast of new proposed regulatory frameworks, but if you’re interested in software-defined radio (SDR) or even reflashing your WiFi router, you should. Right now, there’s a proposal to essentially prevent you from flashing your own firmware/software to any product with a radio in it before the European Commission. This obviously matters to Europeans, but because manufacturers often build hardware to the strictest global requirements, it may impact everyone. What counts as radio equipment? Everything from WiFi routers to wearables, SDR dongles to shortwave radios.
The idea is to prevent rogue reconfigurable radios from talking over each other, and prevent consumers from bricking their routers and radios. Before SDR was the norm, and firmware was king, it was easy for regulators to test some hardware and make sure that it’s compliant, but now that anyone can re-flash firmware, how can they be sure that a radio is conformant? Prevent the user from running their own firmware, naturally. It’s pretty hard for Hackaday to get behind that approach.
The impact assessment sounds more like advertising copy for the proposed ruling than an honest assessment, but you should give it a read because it lets you know where the commission is coming from. Reassuring is that they mention open-source software development explicitly as a good to be preserved, but their “likely social impacts” include “increased security and safety” and they conclude that there are no negative environmental impacts. What do you do when the manufacturer no longer wants to support the device? I have plenty of gear that’s no longer supported by firmware updates that is both more secure and simply not in the landfill because of open-source firmware.
Similarly, “the increased capacity of the EU to autonomously secure its products is also likely to help the citizens to better protect their information-related rights” is from a bizarro world where you can trust Xiaomi’s home-automation firmware to not phone home, but can’t trust an open-source replacement.
Public comment is still open, and isn’t limited to European citizens. As mentioned above, it might affect you even if you’re not in the EU, so feel free to make your voice heard. You have until September, and you’ll be in some great company if you register your complaints. Indeed, reading through the public comments is quite heartening: Universities, researchers, and hackers alike have brought up reasons to steer clear of the proposed approach. We hope that the commission hears us.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
We’re not sure how many of you out there own a boat large enough to get its own integrated computer network, but it doesn’t really matter. Even if you can’t use this project personally, it’s impossible not to be impressed with the work [mgrouch] has put into the “Bareboat Necessities” project. From the construction of the hardware to the phenomenal documentation, there’s plenty that even landlubbers can learn from this project.
In its fully realized form, the onboard computer system includes several components that work together to provide a wealth of valuable information to the operator.
What [mgrouch] calls the “Boat Computer” contains a Raspberry Pi 4, a dAISy AIS receiver, an RTL-SDR, a GPS receiver, serial adapters, and the myriad of wires required to get them all talking to each other inside a weatherproof enclosure. As you might expect, this involves running all the connections through watertight panel mounts.
Combined with a suite of open source software tools, the “Boat Computer” is capable of interfacing with NMEA sensors and hardware, receive weather information directly from NOAA satellites, track ships, and of course plot your current position on a digital chart. The computer itself is designed to stay safely below deck, while the operator interacts with it through an Argonaut M7 waterproofed HDMI touch screen located in the cockpit.
For some people, that might be enough. But for those who want to do big, [mgrouch] further details the “Boat Gateway” device. This unit contains an LTE-equipped WiFi router running OpenWrt and all the external antennas required to turn the boat into a floating hotspot. Of course it also has RJ45 jacks to connect up to the other components of the onboard system, and it even includes an M5Stack Core with LAN module so it can display a select subset of sensor readings and navigational data.