The forensic report on the failure of the cable sockets is at https://www.thorntontomasetti.com/sites/default/files/2022-0.... Unlike the linked article this includes detailed diagrams and discussion explaining how these sockets worked and how they failed.
My attempt at a quick summary: the Arecibo instruments were held up by heavy steel cables, which are composed of a bundle of 126 to 216 individual wire strands twisted together, where each wire strand is about 1/4 inch diameter. At the cable ends these were anchored in sockets. The socket is conical, widening out towards where the wire ends go. The wire strands of the cable would be separated in a "broom" shape to fill out that conical area, and then the whole thing filled in with molten zinc.
The failure mode of these zinc-filled sockets is for an inner core cylinder, about the same diameter as the cable body, to pull out from the socket while outer strands of the cable which are broomed out of that core either snap or pull free from the zinc plug.
This failure mode hadn't really been seen prior to the Arecibo collapse, partly because it is a long term process where the zinc slowly flows under stress over decades.
I think the "electromigration" part of this is a red herring. It seems perfectly plausible after reading this report that improper construction and low safety factors were the cause of the collapse.
Given the choice between "you should've gone up a size" and "you should've bought more engineering" these reports will always say the latter because they are prepared by engineers.
With competent engineering and construction, the (failed at Arecibo) zinc socket cable anchors can be very reliable. Unfortunately, Arecibo's engineering was so-so, and the construction quality was half-assed.
With annual inspections (by someone with a passable understanding of cable anchors) the problems at Arecibo could easily have been caught in time to correct. Unfortunately, Arecibo received no such inspections.
And this is roughly the pattern for most "sudden" failures of infrastructure.
> Unfortunately, Arecibo received no such inspections.
With or without the inspections, the problems Arecibo faced were of a more serious nature. They are hinted in one of the findings: the non-replacement, repair or bypass of the sockets where large slips were observed.
The telescope received minimal funding for maintenance over the two decades prior to the collapse despite signs of increasing damage observed in the various inspections. A lot of factors probably contributed to this (political climate, the dropping importance of Arecibo compared to other science instruments and missions, and so on) but the result was that the structure was left with slow but sure decay.
I met a couple of people who worked with the telescope including on location and they told me that the general feeling among the people who had this on their minds (most people who ever had anything to do with Arecibo cared about the science not the instrument) was that the decay was slow but certain and catastrophic failure was bound to happen sooner or later. Like a car receiving no maintenance despite the check engine light being on for a decade.
The telescope received minimal funding because stakeholders couldn't make a good case for more. The results the facility could produce weren't seen as justifying the expense. In that light, that it was operated at all was more than one might reasonably have expected. The alternative was to just shut it down earlier. They squeezed the last drops of output before the old thing was allowed to die.
Sometimes with facilities like this you have to make the call that it's over.
Yes-ish? Funding was far more plentiful when the telescope was being designed and built, and in its early decades. I know zero details about that era - but I strongly suspect it suffered from "just focus on the cool parts" syndrome. And if it'd been designed and built correctly, or the problem caught and corrected back then, it would very likely still be standing.
Which is not to say it'd still be receiving operational funding, nor that its potential scientific contributions would be particularly worthwhile.
It was built in the ‘60s and started losing its relevance and funding in the 2-3 decades before the collapse. A lot of time for issues to develop, be noticed, but not have enough money to fix.
Read through the Thornton Thomasetti Forensic Report (linked above).
If the original builders had cared about the boring parts, then pre-WWII QC technology could easily have spotted the extremely shoddy workmanship in the zinc spelter sockets, while those were originally being fabricated.
Similar for designing larger safety margins into the whole cable system. Even PHB's can understand that "Hurricane Snaps Cables, Telescope Collapses" headlines could make them look really bad.
Ah, so historically things were build with a lot of slop. It was just the traditional kind with sloppy design, sloppy construction, and sloppy maintenance.
There is a lesson here to be ignored in the name of short-term personal gain.
The pictures on page 25 seem to show how this socket design fails. First because they didn't evenly distribute the wires in the socket (seriously??)... And second, the shear on the zinc from the compressed wire bundle is essentially a narrow rectangle in the direction of the cable with almost all the force concentrated in a narrow forward bit, not really distributed evenly through the socket, because of the wire ends splaying outward and not being equally distributed. I guess the idea is the rest of the zinc towards the back provides a counter force on the front part, but there's a whole lot more zinc in the back pulling on a smaller amount in the front. The tight bundle and the conical shape is great for a tight install, but doesn't help distribution of load. Compare to the Golden Gate Bridge wire termination (https://c7.alamy.com/comp/2RY9PKW/golden-gate-bridge-plans-i...). The zinc creep is definitely bad, but it seems made worse by an uneven distribution of load in the socket, in addition to all the other problems...
tl;dr once the outer wires break in the socket (in part due to zinc creep, but also potentially more load on them), the "glue" keeping the wire bundle connected to the socket is broken, the former wedge keeping the core in place becomes a straight line, and you have a core ready to pop out.
AFAIK cable brooming for spelter sockets is still not automated and relies on human skill, there's no tool to guarantee the necessary wire distribution. I wonder why it's hard to automate, these sockets are everywhere (along with wedge sockets) and are always safety-critical.
I'd refine this to, the cylinder for the lock did not care what key you put in, it woul open it anyways. So the key looks secure, but the lock is a joke.
I am less interested in the threat models than the accidental denial of service models. I've avoided passkeys because of that. It seems like there are real problems if you use multiple devices not somehow symced.
I have started using Passkeys everywhere that I can. One of my "requirements" is "do they support multiple key enrollment". Most do, it's sort of required by the spec and semi-required in practice by the giant number of consumers in the US with iOS or Android phones and Windows PCs. The open source libraries certainly push you in the direction of implementing it properly multi-key per user. (I've also implemented Passkey-Only website login.)
I generally add keys from two very different Password Managers to every site/app I use Passkeys with. Both Password Managers also sync between multiple devices I own.
Redundancy is already an option. Choice in Password Managers to use for your Passkeys is an option.
I understand that accidental denial of service fear, but the tools exist technically to deal with that fear if you wanted to try to deal with it.
Matt Pharr (author of the SIMD programming language ISPC) nailed it with the insight "Auto-vectorization is not a programming model."
As Matt writes ([1]) : "
The problem with an auto-vectorizer is that as long as vectorization can fail (and it will), then if you’re a programmer who actually cares about what code the compiler generates for your program, you must come to deeply understand the auto-vectorizer. Then, when it fails to vectorize code you want to be vectorized, you can either poke it in the right ways or change your program in the right ways so that it works for you again. This is a horrible way to program; it’s all alchemy and guesswork and you need to become deeply specialized about the nuances of a single compiler’s implementation—something you wouldn’t otherwise need to care about one bit."
I’m not sure I follow their point. By going with structs of arrays you’re already getting your max SIMD bandwidth 80% there even with the most naive implementations. Learning which math operations are hardware SIMDable gets you another 10%. It’s the last 10% where you rely on math expressions (eg. trig identities), restricted pointers, and ternary “masking magic” where the author may have a point.
Was daydreaming the other day about how this could be used by adversaries to hack even air-gapped computers. Any peripheral which contains a microchip and some ram is a vector. Does the compartmentalized facility ever bring in a new monitor, or mouse, or keyboard? All of those things could be hacked to hack their new host. And then taking data into/out of the facility. Which devices have lights? Any LED that can be blinked is a low-speed output channel. Which have light-level sensors, or sound sensors? Or any RF capability? If bluetooth is disabled by software but the hardware is still there...
If I was writing a novel, the top secret facility would be cracked open by the smoke alarm, which has a wired connection to the central fire control and runs a little microprocessor. There is enough storage for 20 programmable voice alert messages. I/O includes an LED and also a light sensor. After the attacker gains control of the smoke alarms -- reach to every room of the secure facility -- their focus turns to mass poisoning peripherals until one makes it into range. A poisoned monitor detects the smoke alarm blinking a coded broadcast via its LED during darkened overnight hours. The monitor responds with flashing code of its own. That creates a communication path back to the controlling LLM. From there its like attacking a normal networked device, just with a slow data link in the middle...
In environments where the threat model requires it you can/must already buy hardware variants that are non-radio. It's not just disabled in software but is a different physical SKU. Likewise data diodes for USB, audio, or display connections are also common.
The novelty is the uniform adaption of USB-C for the rest of the world and the endless attack surface that provides.
There are a lot of cars out there where the head unit has connection to the CAN bus. Which means this malware vector could be used to directly cause crashes. E.g. https://news.ycombinator.com/item?id=19751872
The car hacker's handbook [1] has a chapter on just using the infotainment system to access the CAN. Specifically mentions "attacking through the update system".
An aftermarket head unit connects to the CAN bus? The aftermarket head unit I installed certainly doesn't. Are you sure what you are saying, which is true for OEM units, applies to aftermarket ones?
Can't vouch for all car architectures, but in most cases the head unit is QM and safety domains are usually segmented from each other. So even if the head unit talks CAN (it needs to get car data somehow) it will only communicate with the rest of the car through a gateway that will not allow it to take any dangerous actions.
That's true for most cars, but some, particularly the older cars, they weren't as concerned about security as they should have been. And so sometimes the radio can talk to things that it probably shouldn't be able to talk to.
I did not connect ODB2. The HU I got puts itself as a passthrough to the stock BMW HU (which you still need to be able to use, you switch the screen to its output by holding down a button), and that connector includes CAN.
There are numerous reasons the HU needs CAN, for example to get the steering wheel angle to be able to draw the guides over the backup camera feed. Or to switch to the backup camera feed when you put the car in reverse.
It is really exposing the CAN bus, it is not some adjacent subsystem overlaying the steering guides and rearview video by interrupting the video signal? It's actually entirely coming from the aftermarket HU? That's fascinating! I wouldn't expect an aftermarket system to be too good at that functionality, guides tend to be carefully tuned for specific car/steering/camera combos.
Ideally most cars should be relying heavily on data diodes to minimize the risk of a bad actor wreaking havoc. I know for sure some cars (there was a Jeep example as I recall) don't do that, but I kinda wonder which ones do. It seems like a pretty obvious attack vector worth protecting.
Yes, the BMW NBT quadlock connector has K-CAN2 (so only body bus, no engine/chassis which is on a different CAN bus). (in true German over-engineering fashion it also has fiber for audio and Ethernet for diagnostics)
I brought up the backup camera as another reason the head unit has CAN, since in my car that's what's handling drawing the backup guide lines.
The aftermarket HU would have enough data to do so, but in my case it doesn't (although it does read CAN for buttons/iDrive). The original HU is still there and functioning, but the aftermarket Android is between the vehicle harness and the original HU with some passthrough and swapping of video cables.
I can hold down the Menu button on my iDrive and the Android HU switches the screen to show the original HU output and I can interact with it normally. And when I put the car into reverse it also switches so I can see the original backup camera feed, then switches back to Android after I drive forward again.
Of course I use none of the Android functionality at all, the whole ridiculous system is solely for CarPlay.
As the other comment points out, if you've installed more than a few, you've definitly connected to the CAN bus.
Few headunits will ask you to connect to the OBD2 port for practical reasons, but the miscilanous manufacturer specific connectors you hook up often include CAN bus connections.
OBD2 port is just 1 of multiple ports with access to the network, even your headlights can be on the bus
The expensive ones do so you get more of an OEM infotainment experience. I guess you could potentially cause a crash over the CAN bus but there's a very small overlap between cars that allow you to swap out headunits and cars that can be controlled enough over CAN to cause a crash. Other than commercial vehicles, I don't think there are any new cars that have DIN stereos anymore.
Many do - the one I was looking at for my vehicle in particular uses it to restore the steering wheel controls (which are broadcast over the CAN-B low speed bus)
So on an affected system, ring 0 root has access to pretty much everything that was hidden in negative ring territory. The page is pretty quiet about what other processor families might be similar beyond this specific AMD16h (an older AMD low-power family)?
from the GH page:
> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked. 17h and beyond simply leave this information out.
As long as you know the controller's translation registers, it's applicable? Not tested on later one's merely because the information wasn't readily available it seems.
> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked. 17h and beyond simply leave this information out.
My attempt at a quick summary: the Arecibo instruments were held up by heavy steel cables, which are composed of a bundle of 126 to 216 individual wire strands twisted together, where each wire strand is about 1/4 inch diameter. At the cable ends these were anchored in sockets. The socket is conical, widening out towards where the wire ends go. The wire strands of the cable would be separated in a "broom" shape to fill out that conical area, and then the whole thing filled in with molten zinc.
The failure mode of these zinc-filled sockets is for an inner core cylinder, about the same diameter as the cable body, to pull out from the socket while outer strands of the cable which are broomed out of that core either snap or pull free from the zinc plug.
This failure mode hadn't really been seen prior to the Arecibo collapse, partly because it is a long term process where the zinc slowly flows under stress over decades.
reply