Slashdot Mirror
Bleedingbit Zero-Day Chip Flaws May Expose Majority of Enterprises To Remote Code Execution Attacks (zdnet.com)
Two new zero-day vulnerabilities called "Bleeding Bit" have been revealed by security firm Armis, impacting Bluetooth Low-Energy (BLE) chips used in millions of Cisco, Meraki, and Aruba wireless access points (APs). "Developed by Texas Instruments (TI), the vulnerable BLE chips are used by roughly 70 to 80 percent of business wireless access points today by way of Cisco, Meraki and Aruba products," reports ZDNet. From the report: The first vulnerability, CVE-2018-16986, impacts Cisco and Meraki APs using TI BLE chips. Attacks can remotely send multiple benign BLE broadcast messages, called "advertising packets," which are stored on the memory of the vulnerable chip. As long as a target device's BLE is turned on, these packets -- which contain hidden malicious code to be invoked later on -- can be used together with an overflow packet to trigger an overflow of critical memory. If exploited, attackers are able to trigger memory corruption in the chip's BLE stack, creating a scenario in which the threat actor is able to access an operating system and hijack devices, create a backdoor, and remotely execute malicious code.
The second vulnerability, CVE-2018-7080, is present in the over-the-air firmware download (OAD) feature of TI chips used in Aruba Wi-Fi access point Series 300 systems. The vulnerability is technically a leftover development backdoor tool. This oversight, the failure to remove such a powerful development tool, could permit attackers to compromise the system by gaining a foothold into a vulnerable access point. "It allows an attacker to access and install a completely new and different version of the firmware -- effectively rewriting the operating system of the device," the company says. "The OAD feature doesn't offer a security mechanism that differentiates a "good" or trusted firmware update from a potentially malicious update."
The second vulnerability, CVE-2018-7080, is present in the over-the-air firmware download (OAD) feature of TI chips used in Aruba Wi-Fi access point Series 300 systems. The vulnerability is technically a leftover development backdoor tool. This oversight, the failure to remove such a powerful development tool, could permit attackers to compromise the system by gaining a foothold into a vulnerable access point. "It allows an attacker to access and install a completely new and different version of the firmware -- effectively rewriting the operating system of the device," the company says. "The OAD feature doesn't offer a security mechanism that differentiates a "good" or trusted firmware update from a potentially malicious update."
It does not surprise me at all that their shit is broken.
Doesn't seem to make sense to me.
On a laptop, phone or tablet, you probably want bluetooth and wifi.
But "enterprise" wifi access points are normally wired in with a controller, and I don't see what the bluetooth would be used for.
What am I missing?
Obviously it's there to increase the attack area. Duh.
"Developed by Texas Instruments (TI), the vulnerable BLE chips are used by roughly 70 to 80 percent of business wireless access points today by way of Cisco, Meraki and Aruba products," reports ZDNet.
Of course, it's entirely likely you're not affected by the compromised chips.
So you can take the reassuring route of "Clearly, that vulnerability clearly affects folks other than me, so I'm righteously Dunning-Kruger in my examination of the evidence that might suggest I'm super, duper, special.
Happiness in intelligent people is the rarest thing I know.
Ernest Hemingway
Your search - butthoaljoe - did not match any documents.
Suggestions:
Make sure all words are spelled correctly.
Try different keywords.
Try more general keywords.
No they don't, the chips run microcode.
The OS doesn't matter, it's a hardware problem.
It's a checkbox in the bullshit-feature game.
You know those checkboxes. From your local electronics big box mart. With every appliance, there's this sticker that has a lot of checkboxes next to the name of features. And some are checked and some are not, depending on whether the appliance has the feature or not. Which ones sell? The ones with features of course. If appliance A costs about as much as appliance B, how will the average person tell the difference? By counting ticked checkboxes, of course. Do they need those features? Hell no. In 9 out of 10 cases they don't even know what those features mean. But A has it and B doesn't, so A is better!
Why do you think the average procurement manager works differently?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Not allowing the owners of the chips to load custom firmware onto the chips is an atrocious practice. That would be the equivalent of maintaining hidden root access on a system that doesn't belong to you and relegating the legitimate owner to a shadow fake root. If you're going to require signed firmware images on a piece of kit then you need to include the private key to sign new firmware to anyone with with your chip in their equipment.
How many big box mart stores sell these enterprise Cisco, Aruba and Meraki access points?
microcode is the code a cpu runs internally to implement its own instruction set.
I highly doubt the cpu in these ble chips use microcode at all.
Except one of these vulnerabilities is exactly what you're complaining about.
The ability to allow any code to be uploaded was accidentally left enabled, allowing anyone within radio range to load any code they wish.
Reflashing should require setting a physical jumper.
I don't think that word means what you think it means.
In fact, the TI chips, like many other BLE chips is an ARM cortex SOC (cannot run Linux) running a light weight RTOS with a Bluetooth protocol stack and a suitable radio.
In other words, they run ARM machine language.
All of them. Linksys is owned by Cisco.
Enterprise vendors and the pointy hairs that sign the POs follow exactly the same pattern.
In other words, you mean none of the products identified as having this issue.
These aren't consumer marketed products. Just because Cisco has a consumer brand with a different set of products, doesn't mean their enterprise offerings are identical.
So to upgrade the firmware in these enterprise outdoor access points, they should send a guy on site up a pole, take the thing down, open it up, insert the jumper, upgrade the firmware, reassemble it and then reinstall it outside? For each of the hundred devices they have?
Even the indoor AP's in my building would be a costly nightmare. There's 10 floors with at least 6 AP's on the roof of each floor.
It's up to you, you can balance the risk/reward as you see fit.
For example, you might prefer to change the bootloader so it will flash an image you signed without the jumper, but require the jumper to change the signing key.
Or, since the firmware I'm referring to is for the BLE module, (not the entire AP), you could just leave it as is with the jumper off..
Again, this is the procurement version of it. You have a procurement manager who knows jack shit about routers. But you, in IT, can't simply go and purchase a sensible access point when you need one. You have to go through procurement. And procurement will buy the "most economic" solution. Which usually means the cheapest shit that fits the bill. And if you find different cheap shit, the one with the most filled tick boxes get bought.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
It's for new wayfinding and location-based features. And they leveraged it for console use, though you rarely ever need console on these things.
Note the second CVE is not a "0-day". Aruba notified customers quite some time ago with workarounds (and a patch relaease, though only for their most-deployed chain.)
And they knew before then (they said they had to notify earlier than they wanted due to someone leaking.)
Someone had to do it.
I'd love to get that horse back in the barn, but considering the tech docs for these chipsets are not released to customers, we'd have to round up the pony as well. You can hope the chips behave like some similar design but you never know if there's one register in there wired up differently on a device made custom fr a manufacturer.
Also in this specific case they can hide behind the fact that the chipsets participate in RF and thus amateur firmware could cause illegal interference, so there's a mule out in the field as well (same problem with phone chipsets.)
(Proper way to go about this is have the TPM allow a customer key, not publish your corporate private key. Preferably you can have more than one key, and disable the vendor key if needed. Main problem is making it easy for low-level IT guys to check what the status of the keys are... very low-level IT guys. So preventing the TPM from using keys it was not booted with and providing a service/mechanism that validates the running key.)
Someone had to do it.
linksys is not owned by cisco. belkin bought it from cisco way back in march of 2013. but get with the program. it's not over yet, either, try to keep up... because now, foxconn is in process of buying belkin.
but either way, belkin or foxconn, don't expect anything to improve on the security and update front. they're both worse than cisco was for security support of that product line, and far worse than linksys was on its own before that.
These are all manufacturers during the NSA/Snowden leak. What a coincidence they have such exploits?
Remind me why we put Bluetooth in everything nowdays?
Not True. Just upgrade the software.
https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2018-006.txt
Someone in marketing said that they need to put Bluetooth on the devices before the competition does. Now they have the most wireless in their wireless access points and have closed the Bluetooth "gap" with the competition.
This one may not run Linux, but ARM cortex SoC's certainly can. Most Raspberry Pi's are running Linux.
Doesn't seem to make sense to me.
On a laptop, phone or tablet, you probably want bluetooth and wifi.
But "enterprise" wifi access points are normally wired in with a controller, and I don't see what the bluetooth would be used for.
What am I missing?
IOT devices with low power BT are used for tracking. Some McDonalds in the Netherlands uses these to serve your order.
The best weapon of a dictatorship is secrecy, but the best weapon of a democracy should be the weapon of openness.
Would it not be preferable to just have the motherboard require a switch accessible by users when the case is fully assembled set to allow firmware updates?
I had to look at TFA to find out that:
1) It has an auto-play video. Another to add to your blocker's blacklist
2) BLE chips are used for IoT connectivity. I assume the Access Points run wifi for your phones and laptops and Bluetooth (LE) for your IoT devices. If you don't have any IoT, you don't need the BLE functionality (there may be a way to turn it off in these products, but knowing Cisco, you can turn the functionality off but it won't protect you from the vulnerability).
In other words... IoT is a sack of insecure shite. If the device itself doesn't have vulnerabilities, the AP will. Great.
Enterprise procurement works the same, is the point. The decision makers for very large purchases don't understand the technology, but they do understand feature checklists.
Socialism: a lie told by totalitarians and believed by fools.
A lot of these devices don't even store the firmware themselves any more. They just have a bootloader and the firmware is loaded every time they are powered up.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
So what you are saying is they store the firmware and load it up each time they're powered on. Sure sounds like they're storing it to me...But they don't store the firmware themselves anymore. Do you realize you just completely and totally contradicted yourself?
Re: several comments that wireless exploits demand physical presence - not true. Phish a trojan on to a few thousands cell phones from the other side of the planet and in no time flat you will have people carrying your attack into the most sensitive of data centers sniffing for vulnerable WiFi access point and proxying your attacks through the cell/Internet connection into the local WiFi / Bluetooth space.
True, some don't, but the TI devices do have their own flash for firmware.
Some devices have their own onboard flash and bootloader. Others have no internal flash and they are initialized by the main CPU and run out of the main device flash.
Cortex A runs linux, but cortex M used in bluetooth devices cannot.
I said SHOULD, not DOES.
That would be up to the manufacturer that incorporates the BLE module into the product.
Tracking and advertising. These things emit BLE beacons that apps on your smartphone pick up. This allows for analytics in malls, geofencing ads, ... (Look up Eddystone and iBeacon.) That coupon app for your supermarket chain? Allows them to track your every move through their store, from the moment you enter to when you check out.
Other uses include "indoor GPS" (having the app show your location in the building on a map, ...).
https://documentation.meraki.c...
https://www.arubanetworks.com/...
https://www.cisco.com/c/en/us/...
Congratulations for proving you have poor reading comprehension.
He said not allowing the owner of the device to upload code was wrong, NOT that allowing anyone to upload code was right.
He also gave an example for an authentication mechanism to determine who can upload new code. Which is absent in the vulnerability you're referring to.
Further the vulnerability you're referring to would have still been present if they had required manufacturer signed firmware only. Which guess what? They do if it's enabled by the manufacturer of the device. Which means any vulnerability would be protected by the manufacturer and could only be fixed by the manufacturer, even if you knew exactly what bits were bad and how to fix them. The only difference in this case is that this particular vulnerability bypasses this restriction when enabled. Rendering the protection useless.
So no, his "complaint" is different.