Comment by nonrandomstring | Hacker News Reader

Comment by nonrandomstring | Hacker News Reader

nonrandomstring

Storm in a teacup. But it raises an interesting question. Why are these HCI commands "undocumented"?

A phrase I hear around security nowadays is "Shadow API" [0, 1]

A shadow API is an undocumented one, and it tends to set-off massive alarm bells.

The researchers were clearly too keen to make a splash, and that reflects a sad state of wannabeism and hustling for crumbs these days.

What exacerbates it is proprietary software - stuff that's hidden, obscured, opaque, deceptive, distributed as mysterious "blobs".... this entire cluster of behaviour raises red flags and gets people looking for things. And when we go looking for things that aren't there ... we find them (assume the worst).

That is to say, the researchers are reacting emotionally (but with good justification) to discovering undocumented features, aka a "shadow API".

This could have been avoided if the device maker had just documented them. Why didn't they?

[0] https://www.cybershow.uk/episodes.php?id=39

[1] https://www.cloudflare.com/learning/security/api/what-is-sha...

One fairly common reason to not document something is not wanting to commit to supporting it or to keeping it around in future releases. Document it and customers will come to depend on it and then you might be stuck with it.

I was looking up vacuum tube recently. Apparently there are things called "getter" pins in them that connects to internal material deposition device, used to remove last bits of air out of tube in the manufacturing line. The exact behaviors and operating parameters for those pins are corporate secrets and not documented. Datasheets only mention them as "No Connect" pins that do nothing and has to be disconnected from anything for safe and correct operation of the device. BACKDOOR!!! in an analog vacuum tube.

... everything ever always had factory-use-only interfaces. Manufacturers don't document every bits of everything on public datasheets. Granted, the dynamics of this change if they can be used as backdoors, and those might have to be either disclosed or securely disabled, but "why they exist in the first place" is just nonsensical question; they exist for necessary internal purposes.

That question should be "how should factory use interfaces be handled going forward".

Great example, and I'm old enough to have also wondered why those "nc" pins on valves and ICs clearly did do something.

As you frame it, it's "What the eye doesn't see the heart doesn't grieve". Definitely apropos the making of burgers and sausages.

Now we have a different discussion, about "internal" or "external" legibility.

We used to live in a world of high trust in vendors. Those days are gone. Vendor malware is a massive and growing problem and supply-chain legibility is a hot topic.

FWIW I'm arguing the fully open position. Unless you've desperate trade secrets, there is no "internal". And if you've a 16 bit register that's 65536 entries, most of them sparsely documented as "no op". And if a researcher finds it does something,... it's suspicious by default.

This "no user serviceable parts" is an old schism in technology. Today we have almost blanket rights to repair and openness is the new security model.

All complex devices, like CPUs, GPUs, microcontrollers, have tons of undocumented debug features, without exception.

The only difference between devices is whether such debug features remain accessible to users or they are completely disabled after production.

In this specific case, as well explained in TFA, the debug commands do not really provide any additional exploitable capabilities for a malicious programmer, especially because the Bluetooth controller is already hosted on the same CPU as the potentially malicious application, so if that could use the debug commands it could already do anything it wants, like sending arbitrary Bluetooth packets. The Bluetoth driver also can already do anything it wants on the shared CPU, so if it had bugs or backdoors that can be triggered by received Bluetooth packets the existence of these debug commands does not change anything.

Unlike this case where there is nothing to criticize in the reply of ExpressIf or on what they have done, an example of atrocious handling of the undocumented debug features has been provided by Apple, whose devices had for several years, until the end of 2023, a backdoor created by non-disabled debug registers, which allowed a total bypassing of the memory protection, enabling (in conjunction with some bugs in Apple system libraries) complete remote control of an iPhone, and which has been exploited for the remote and undetectable spying of some iPhone owners (discussed on HN at the time of the public revealing of the CVEs).

All of this higher level HCI and API shiz rests (in the embedded world) on a set of registers which are usually documented in the daatsheet. By manipulating these registers, the developer can make the IC do anything it is capable of doing: it is the ultimate API, and there is almost no means in code of making the hardware do anything except by this means. So any 'shadow' API is not really of any consequence in embedded, because it all boils down to these registers, which we can perfectly well view or manipulate.

Espressif, as well as all other manufacturers of such BLE enabled SoCs provide at least some parts of their RF stack as precompiled binary. However, Espressif took the decision to deliberately not publish the registers used at lowest level to configure and command the RF peripheral on the IC. All other manufacturers I am aware of publish these registers, just like all the others. Ultimately this minor obfuscation offers no additional security benefit, nor does it create any security loophole above any that exist on any other chipset.

Reply on news.ycombinator.com