marcan_42 · HackerTrans

4 tahun yang laludiscuss

And what little "security" features the Librem 5 has, they aren't even using. One of their engineers came at me with "we have RPMB!" (a poor excuse for anti-replay memory that is semi-standard these days, and vastly inferior to dedicated chips like Pixels and iPhones have). I asked what they use it for, and got crickets.

marcan_42

4 tahun yang laludiscuss

There's a linux driver behind typical basebands. One driver, since there is no device discovery for platform devices.

The Librem 5 doesn't have one driver exposed to the baseband. It has every single USB driver in the kernel exposed to it, because the baseband can present any descriptors it feels like and engage whatever driver it wants, or a combination thereof by presenting itself as a composite USB device, since USB is plug&play. That is a massively larger attack surface. All you have to do is find one exploitable bug in any USB driver in Linux, and you're in.

This can be mitigated with USB descriptor filtering, but the Librem 5 guys haven't implemented that yet, because they don't actually care about security. So while their marketing department is lying about DMA access for the competition (heck, as far as I know no iPhone gas ever given the baseband unchecked DMA access to the system, but Purism claims they all do!), their engineering department can't even bother to lock down the attack surface of the baseband to something smaller than "every single USB driver in the kernel".

Also, for what it's worth, the Librem 5 doesn't even have an IOMMU at all. They can't even use the PCIe ports in their SoC because that would give whatever you plug into them full DMA to the system. This also means that driver bugs that result in bad DMA descriptors for embedded SoC devices will directly escalate to full memory access; there is no safeguard by having to engage the IOMMU subsystem first to map them.

marcan_42

4 tahun yang laludiscuss

strcat is right here. Purism designs and markets their devices, effectively, to cater to a crowd that believes that devices with actual security are inherently evil, because they do not understand it. You can have better security with user control, but for that you need to look at the details. They don't care about the details; their story is all fluff under the guise of freedom and privacy.

Purism's marketing material is outright deceptive, e.g. they insist that in competing phones the baseband blob has access to system memory, which is a lie. The reality is that the baseband blob in the Librem 5 (which is every bit a giant blob as that in the competition) has access to the USB port of the AP and there is no filtering implemented yet, so the attack surface it is exposed to is every USB driver in the Linux kernel, which is much worse than systems with embedded basebands and proper memory firewalling where the baseband has no more inherent access, but is exposed to a smaller attack surface. That means that you are more vulnerable to giant blobs doing evil things with a Librem 5 than with, say, an Android phone running a free OS build.

Then there's the whole hilarious situation with the RAM initialization blob where Purism went and hid it behind two layers of CPUs (not execution, just handling it), because somehow doing that - which provides absolutely no benefit to the user, it's just a waste of engineering time - made it possible to certify the phone under the FSF's utterly broken and nonsensical "Respects your Freedom" program, even though precisely zero freedom was gained by doing this, since it still running the same blob on the same final CPU with the same access. All the while while reducing security, since the blob is then made no longer part of the normal OS image and is not validated with it, so it could be backdoored as part of a supply chain attack and you would be none the wiser.

The whole thing just stinks the more you look into it, and it is completely evident that the folks behind Purism are a mix of deliberately deceiving people and just clueless about security and modern embedded platforms.

marcan_42

5 tahun yang laludiscuss

That's not how fair use works. It doesn't matter how unlikely it is, if Copilot one day decides to "suggest" a significant snippet of ckxd from a GPLed app, you'd better be planning to GPL your project.

marcan_42

5 tahun yang laludiscuss

Of course, if you set up Home Assistant you can firewall them off the internet. That's how I do it too, with an IoT VLAN. It's not how these devices are intended to work, and not how they work if you just follow the manufacturer's instructions for Google/Alexa integration. You're replacing the vendor's cloud service with Home Assistant, effectively.

For example, I had to work out that in order to get Broadlink devices to stop rebooting every 3 minutes because they can't contact their cloud crap you have to broadcast a keepalive message on the LAN (it normally comes from their cloud connection, but their message handler also accepts it locally, and thankfully that's enough to reset the watchdog). This involved decompiling their firmware. I think that patch finally got merged into Home Assistant recently.

My point is that this is not the intended use for these devices. Normal people are going to put the gateways on the internet and enable the Google integration; in fact, it's quite likely that they will sign in to some IKEA cloud service as soon as you put the gateways on a network with outgoing internet connectivity, even before you enable the integration.

marcan_42

5 tahun yang laludiscuss

Symmetric cryptography is often hardware based, but asymmetric crypto rarely is. The latter is commonly used for pairing/key exchanges, and would be painfully slow on a slow MCU.

marcan_42

5 tahun yang laludiscuss

foobar33333 said "The gateway also does not connect to the internet", which cannot be true, because connecting to the internet to speak to a manufacturer-provided cloud service that then speaks to Google is required to integrate with Google Home. That's how it works. The IKEA gateway has to talk to an IKEA cloud service. If you think otherwise, please link to the Google Home docs that explain how that could possibly work, because I can't find them.

Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.

https://www.home-assistant.io/integrations/google_assistant/

There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices.

Bulb --> Zigbee --> Zigbee Gateway --> WiFi/eth --> LAN --> Your router --> WAN --> IKEA cloud --> Google cloud --> WAN --> Your router --> LAN --> WiFi --> Google Home device.

If that sounds stupid, congrats, this is why they call it the internet of shit.

marcan_42

5 tahun yang laludiscuss

IKEA has to have servers for their devices to integrate with Google Home and Alexa. That's how those systems work. Only Apple offers direct local connectivity as far as I know.

These days Google Home has local fulfillment, but that seems to only be offered as an addition to cloud fulfillment. It always has a cloud fallback path.

Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.

https://www.home-assistant.io/integrations/google_assistant/

There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices. There is a bypass path these days for local access, but it is always in addition to the cloud path, and only an optimization.

marcan_42

5 tahun yang laludiscuss

ZigBee is a network protocol with a network stack. Just because it isn't TCP/IP does not mean it's not a network. It has addressing, routing and routing tables, fragmentation and reassembly, discovery, error detection, packet retransmission, and everything else you'd expect from a functional network protocol.

marcan_42

5 tahun yang laludiscuss

As far as I know only Apple does the local network stuff. If a device is Alexa or Google Home compatible, it talks directly to some cloud service from the manufacturer on the Internet which then talks to Google or Amazon. So it connects directly to the internet, and moreover there is the additional attack/privacy surface of the manufacturer's cloud service.

Source: I run a HomeAssistant local IoT hub and to integrate it with Google Home I had to give it a public hostname and sign up as an IoT vendor with Google to register it as a developer/testing mode service (if I were a real vendor it would be one cloud hub for all my customers, it wouldn't be Google to individual homes, it's just that in my case there is only one user and the server is at my house).

marcan_42

5 tahun yang laludiscuss

Chips that can run Doom are nowhere near the dirt cheap bottom tier. The dirt cheap bottom tier is this $.03 chip:

https://hackaday.com/2019/04/26/making-a-three-cent-microcon...

Chips that can run Doom, though, are just about at the low end for internet-connected devices. You can't run an IoT stack on that $.03 thing. The chip in the bulb is exactly in the right ballpark for the application. You do need a fairly beefy chip to run multiple network protocols efficiently.

marcan_42

5 tahun yang laludiscuss

It's burst processing. You do actually need high processing speeds for short periods of time to implement network protocols like these effectively. Think cryptography, reliability, etc. The CPU isn't doing anything most of the time, but it makes a big difference if it can get the job done in 500μs instead of 5ms when there is something to do (like process a packet).

Also, higher clock speed = lower power consumption. It sounds counterintuitive, but getting the job done quickly so you can go back to low power mode sooner actually saves power, even if the instantaneous power draw while processing is higher.

marcan_42

5 tahun yang laludiscuss

The processing power needed to run a decent internet connected device with typical software stacks these days is about the same as the processing power needed to run Doom.

comments