Software Bug Results In Insulin Pump Injuries, Spurs Recall

Managing Type 1 diabetes is a high-stakes balancing act — too much or too little insulin is a bad thing, resulting in blood glucose levels that deviate from a narrow range with potentially dire consequences on either side. Many diabetics choose to use an insulin pump to make managing all this easier, but as a recent recall of insulin pump software by the US Food and Drug Administration shows, technology isn’t foolproof.

Thankfully, the recall is very narrow in scope. It’s targeted at users of the Tandem t:slim X2 insulin pump, and specifically the companion application running on iOS devices. The mobile app is intended to run on the user’s phone to monitor and control the pump. The pump itself is a small, rechargeable device that users often keep on their belt or tucked into a pocket that delivers a slow, steady infusion of insulin during the day, plus larger bolus doses to compensate for meals.

The t:slim X2 insulin pump.

But version 2.7 of the t:connect mobile app can crash unexpectedly, and on iOS devices, that can lead to the OS continually relaunching it. Each time it does this, the app tries to reconnect with the pump via Bluetooth, which eventually runs down the battery in the pump. Once the battery is dead, no more insulin can be delivered, potentially leading to a condition called hyperglycemia (“hyper” meaning an excess, “gly” referring to sugar, and “emia” meaning presence in blood — excess sugar in the blood.)

Untreated hyperglycemia can progress to a much more serious state called diabetic ketoacidosis, which can lead to coma and death. Thankfully, nobody has suffered that fate from this bug, but the FDA has received over 200 reports of injuries, hence the recall. Tandem sent out a notice to all affected customers back in March to update their apps, but it’s still possible that some users didn’t get the message.

Apart from the human cost of this bug, there’s a lesson here about software design and unintended consequences. While it intuitively seems like a great idea to automatically relaunch a crashed app, especially one with a critical life-safety function, in hindsight, the better course might have been to just go into a safe mode and alert the user with an alarm. That’s a lesson we’ve learned by exploring space, and it seems to apply here as well.

Images: AdobeStock, Tandem Diabetes

This Week In Security: TunnelVision, Scarecrows, And Poutine

There’s a clever “new” attack against VPNs, called TunnelVision, done by researchers at Leviathan Security. To explain why we put “new” in quotation marks, I’ll just share my note-to-self on this one written before reading the write-up: “Doesn’t using a more specific DHCP route do this already?” And indeed, that’s the secret here: in routing, the more specific route wins. I could not have told you that DHCP option 121 is used to set extra static routes, so that part was new to me. So let’s break this down a bit, for those that haven’t spent the last 20 years thinking about DHCP, networking, and VPNs.

So up first, a route is a collection of values that instruct your computer how to reach a given IP address, and the set of routes on a computer is the routing table. On one of my machines, the (slightly simplified) routing table looks like:

# ip route
default via 10.0.1.1 dev eth0
10.0.1.0/24 dev eth0

The first line there is the default route, where “default” is a short-hand for 0.0.0.0/0. That indicate a network using the Classless Inter-Domain Routing (CIDR) notation. When the Internet was first developed, it was segmented into networks using network classes A, B, and C. The problem there was that the world was limited to just over 2.1 million networks on the Internet, which has since proven to be not nearly enough. CIDR came along, eliminated the classes, and gave us subnets instead.

In CIDR notation, the value after the slash is commonly called the netmask, and indicates the number of bits that are dedicated to the network identifier, and how many bits are dedicated to the address on the network. Put more simply, the bigger the number after the slash, the fewer usable IP addresses on the network. In the context of a route, the IP address here is going to refer to a network identifier, and the whole CIDR string identifies that network and its size.

Back to my routing table, the two routes are a bit different. The first one uses the “via” term to indicate we use a gateway to reach the indicated network. That doesn’t make any sense on its own, as the 10.0.1.1 address is on the 0.0.0.0/0 network. The second route saves the day, indicating that the 10.0.1.0/24 network is directly reachable out the eth0 device. This works because the more specific route — the one with the bigger netmask value, takes precedence.

The next piece to understand is DHCP, the Dynamic Host Configuration Protocol. That’s the way most machines get an IP address from the local network. DHCP not only assigns IP addresses, but it also sets additional information via numeric options. Option 1 is the subnet mask, option 6 advertises DNS servers, and option 3 sets the local router IP. That router is then generally used to construct the default route on the connecting machine — 0.0.0.0/0 via router_IP.

Remember the problem with the gateway IP address belonging to the default network? There’s a similar issue with VPNs. If you want all traffic to flow over the VPN device, tun0, how does the VPN traffic get routed across the Internet to the VPN server? And how does the VPN deal with the existence of the default route set by DHCP? By leaving those routes in place, and adding more specific routes. That’s usually 0.0.0.0/1 and 128.0.0.0/1, neatly slicing the entire Internet into two networks, and routing both through the VPN. These routes are more specific than the default route, but leave the router-provided routes in place to keep the VPN itself online.

And now enter TunnelVision. The key here is DHCP option 121, which sets additional CIDR notation routes. The very same trick a VPN uses to override the network’s default route can be used against it. Yep, DHCP can simply inform a client that networks 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are routed through malicious_IP. You’d see it if you actually checked your routing table, but how often does anybody do that, when not working a problem?

There is a CVE assigned, CVE-2024-3661, but there’s an interesting question raised: Is this a vulnerability, and in which component? And what’s the right solution? To the first question, everything is basically working the way it is supposed to. The flaw is that some VPNs make the assumption that a /1 route is a bulletproof way to override the default route. The solution is a bit trickier. Continue reading “This Week In Security: TunnelVision, Scarecrows, And Poutine”

A pile of red Swiss Army knives, probably collected by TSA.

Introducing The Swiss Army… Tool?

You’ve probably used one for everything from opening packages to stripping wires in a pinch (because you know better than to use your teeth). We’re talking about the blade of the iconic Swiss Army knife. And while there are many different models out there, they all feature at least one knife among their utensils. Until now.

Citing pressure due to the increase in worldwide knife violence, the company announced that they’ll be releasing a new range of tools without blades. Carl Elsner, fourth-generation CEO of Swiss Army knife maker Victorinox, is also concerned about increasing regulations surrounding knives at sporting events and other activities. And he has a point: according to the UN’s Global Study on Homicide 2023 (PDF), 30% of European homicides were committed with some type of sharp object.

In an interview with The Guardian, Elsner spoke of creating more specialized tools, such as one for cyclists, who don’t necessarily need a blade. He also mentioned that Victorinox have a tool specifically for golfers, but we’d like to point out that it features, among other things, a knife.

It’s going to be a long time before people stop assuming that the skinny red thing in your pocket contains a knife, especially at the airport. What TSA agent is going to take the time to check out your tool? They’re going to chuck it in the bucket with the rest of them. Would you consider buying a blade-less multi-tool? Let us know in the comments.

Don’t have much need for a knife? Here’s a bench tool that has it all.

(Main and thumbnail photos via Unsplash)

Robotic Platform Turns Shop Vac Into Roomba

The robotic revolution is currently happening, although for the time being it seems as though most of the robots are still being generally helpful to humanity, whether that help is on an assembly line, help growing food, or help transporting us from place to place. They’ve even showed up in our homes, although it’s not quite the Jetsons-like future yet as they mostly help do cleaning tasks. There are companies that will sell things like robotic vacuum cleaners but [Clay Builds] wanted one of his own so he converted a shop vac instead.

The shop vac sits in a laser-cut plywood frame and rolls on an axle powered by windshield wiper motors. Power is provided from a questionable e-bike battery which drives the motors and control electronics. A beefy inverter is also added to power the four horsepower vacuum cleaner motor. The robot has the ability to sense collisions with walls and other obstacles, and changes its path in a semi-random way in order to provide the most amount of cleaning coverage for whatever floor it happens to be rolling on.

There are a few things keeping this build from replacing anyone’s Roomba, though. Due to the less-than-reputable battery, [Clay Builds] doesn’t want to leave the robot unattended and this turned out to be a good practice when he found another part of the build, a set of power resistors meant to limit current going to the vacuum, starting to smoke and melt some of the project enclosure. We can always think of more dangerous tools to attach a robotic platform to, though.

Continue reading “Robotic Platform Turns Shop Vac Into Roomba”

Remembering Dick Rutan And His Non-Stop Flight Around The World

On December 23, 1986, an airplane landed at Edwards AFB. This by itself wouldn’t mean much, but this particular airplane had just written history. Piloted by Dick Rutan and Jeana Yeager, the Rutan Model 76 Voyager had just completed its non-stop flight around the world after taking off from that very same runway just over nine days prior. Designed by Dick’s younger brother Burt Rutan, this airplane and this one flight will forever speak to the world’s imagination, even as we say farewell to Dick “Killer” Rutan.

Dick Rutan (r) and Jeana Yeager (l) standing next to the Voyager aircraft in 1986. (Source: Ray Kamm collection)
Dick Rutan (r) and Jeana Yeager (l) standing next to the Voyager aircraft in 1986. (Source: Ray Kamm collection)

Born Richard Glenn Rutan on July 1, 1938, he spent his military career in the United States Air Force, initially working with radar systems before beginning pilot training in the 1960s. He flew 325 sorties over Vietnam (ejecting once) and served for many more years while racking up many awards and reached the rank of Lieutenant Colonel before retiring in 1978.

After this he would fly as a test pilot for a range of aircraft, including a modified Rutan Long-EZ: the XCOR EZ-Rocket in 2001. Yet no flight would be as memorable as the record-breaking flight in the Rutan Voyager, which saw the world’s media following the aircraft’s journey around the globe, including with live feeds whenever the aircraft was within reach of national broadcasters. Despite nine days of strenuous flight and some mechanical breakdowns and damaged wingtips (from the fuel-burdened wings scraping over the runway), the flight went about as well as could have been hoped, thanks to Dick’s and Jeana’s piloting skills.

Dick Rutan died on May 3, 2024 at the age of 85 after a long struggle with the consequences of Long COVID. He will be sorely missed by the aviation community and countless others, but his achievements never forgotten.

The 2024 Business Card Challenge Starts Now

If you want to make circuits for a living, what better way to impress a future employer than to hand them a piece of your work to take home? But even if you’re just hacking for fun, you can still turn your calling into your calling card.

We are inviting you to submit your coolest business card hacks for us all to admire, and the top three entries will win a $150 DigiKey shopping spree.  If your work can fit on a business card, create a project page for it over on Hackaday.io and enter it in the 2024 Business Card Contest. Share your tiny hacks!

To enter, create a project for your hacked business card over at Hackaday IO, and then enter it into the 2024 Business Card Challenge by selecting the pulldown on the left. It’s that easy.

Continue reading “The 2024 Business Card Challenge Starts Now”

Google Removes RISC-V Support From Android

Last year the introduction of  RISC-V support to the Android-specific, Linux-derived Android Common Kernel (ACK) made it seem that before long Android devices might be using SoCs based around the RISC-V ISA, but it would seem that these hopes are now dashed. As reported by Android Authority, with a series of recently accepted patches this RISC-V support was stripped again from the ACK. While this doesn’t mean that Android cannot be made to work on RISC-V, any company interested would have to do all of the heavy lifting themselves, which might include Qualcomm with their recently announced RISC-V-based smartwatch Snapdragon SoC.

No reason was provided by Google for this change, and the official statement from Google to Android Authority says that Google is not ready to provide a single supported Android Generic Kernel Image (GKI), but that ‘Android will continue to support RISC-V’. This change however, removes RISC-V kernel support from the ACK, and since Google only certifies Android builds which ship with a GKI featuring an ACK, this effectively means that RISC-V is not supported at this point, and likely won’t be for the foreseeable future.

As discussed on Hacker News, a potential reason might be the very fragmentary nature of the RISC-V ISA, which makes a standard RISC-V kernel very complicated if you want to support more than a (barebones) profile. This is also supported by a RISC-V mailing list thread, where ‘expensive maintenance’ is mentioned for why Google doesn’t want to support RISC-V.