11 ms·
Billions of devices imperiled by new clickless Bluetooth attack
- jgaa 9y agoSo, I guess it's back to using wired headphones with the phone...
- chiph 9y agoUnless you're on a new iPhone...
- zimpenfish 9y agoI don't wanna be that guy but ... the iPhone isn't mentioned as vulnerable in the article -anywhere-.
- brndnmtthws 9y agoActually, older versions of iOS are vulnerable (before iOS 10). I have no idea how many people actually run that, however.
- coldcode 9y agoOne of our bigger apps is showing about 1%.
- zimpenfish 9y agoAh, you're right, my mistake. Apologies all.
- evgen 9y agoiPhones that are required to use Bluetooth for headphones cannot run pre-10 versions of iOS, so this is a moot point.
- antihero 9y agoNot people on the iPhone 7.
- deleted 9y ago[deleted]
- fulafel 9y agoThis is just a grab bag of BT vulnerabilities they found. It's pretty likely that there are vulnerabilities in iOS BT, they just weren't found in this round. (Remember that these vulnerabilities have been around a long time, laying there undiscovered).
- brndnmtthws 9y agoWired headphones are superior anyway, IMO.
- PeachPlum 9y agoFor all use cases? Or just yours
- brndnmtthws 9y agoI'm just speaking in terms of my personal opinion. Most of the really good headphones are wired (i.e., higher-end audiophile headphones like Grado) and will probably remain so. People also like to supply their own amps. There are some portable Bluetooth headphone amps, but they're not so good compared to USB or analogue amps.
- euyyn 9y agoWireless ones are better for running, so it's not a Pareto dominance thing. Both have pros and cons.
- zeveb 9y agoWireless headphones pop out when running; wired phones have a convenient wire tethering them to one's phone.
- euyyn 9y ago> pop out when running There are many different ways wireless headphones prevent that from happening. > wired headphones have a convenient wire tethering them to one's phone The wire is convenient if you tend to drop them to the floor, which won't happen to most wireless headphones. But it's hateful if it yanks them from your ears, as is sometimes the case when you're exercising.
- driverdan 9y agoFor quality music. For everything else it matters less.
- bjt2n3904 9y agoLink to the whitepaper. http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Pa... Part of the attack is on BlueZ's implementation. > In BlueZ’s case, L2CAP is included as part of the core Linux kernel code. This is a rather dangerous choice. Combining a fully exposed communication protocol, arcane features like EFS and a kernel space implementation is a recipe for trouble.
- crescentfresh 9y agoWhy are none of the CVE vulnerability ids from that paper coming up for me in the CVE database? Eg http://www.cvedetails.com/cve/CVE-2017-14315/ http://www.cvedetails.com/cve/CVE-2017-14315/ I tried all 8 of them, none found.
- sillysaurus3 9y agoDepends on the newness of the attack. It can take awhile for an attack to get into the CVE DB. Though usually it says "this CVE is reserved" rather than "not found."
- ghaff 9y agoIt was only unembargoed at 9AM EDT. More details here: https://access.redhat.com/blogs/product-security/posts/blueborne https://access.redhat.com/blogs/product-security/posts/blueb...
- Ajedi32 9y agocve.mitre.org has at least some of them: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14315 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1431...
- crescentfresh 9y agoThat was also not there a couple of hours ago!
- sillysaurus3 9y agoStuff like this is why physical pentesting is so effective. If you sneak into a company and stick a raspi in a corner, nobody tends to notice a black box amidst a bunch of cables. But that black box can attack the dev machines in a variety of ways: it can be a honeypot wifi AP until someone accidentally connects to it, at which point you have creds for the real network. Then you can connect to the real network and look for workstations to attack. Or, as this article points out, you might be able to use a tricky bluetooth attack to get onto the workstations directly. I'm not sure there's any way to protect against this. Physical pentesters tend to get caught less than 10% of the time. It's very easy to sneak into a building if you know what you're doing and have confidence. And "knowing what you're doing" generally consists of "dress up like a construction worker xor interviewee."
- keyme 9y agoI'll add that extending the range of a Bluetooth transmitter significantly (hundreds of meters) is possible using a directional antenna and a power amplifier. This means that sitting in a building next door, or just having a direct line of sight to the target, is enough to perform such attacks.
- emerongi 9y agoThe beauty of just dropping your black boxes everywhere is that once you have a 0-day, you can just run it on your full fleet of machines scattered everywhere. Once you find a new 0-day, you can run that one etc. Less effort with a lot more payoff.
- lawnchair_larry 9y agoThere's no way anybody has actually done this. Are you guys just fantasizing?
- B1FF_PSUVM 9y agoTomorrow's news today?
- bauc 9y agoIs that why Google Play Protect was recommending to disable Bluetooth Share which seems to have caused a lot of issues for people. Turning it back on requires to reset all app preferences.
- jasonmaydie 9y agoChalk one up for Windows Phone. Security through obscurity, on a more serious note does the flaw happen because of a common opensource implementation?
- detaro 9y agoWhat makes you think that the Windows attack doesn't apply to Windows Phones? At least Windows Phone 8 and 10 are based on the normal Windows kernel, and I don't see why they wouldn't share the Bluetooth implementation as well.
- jasonmaydie 9y ago> A Microsoft representative said Windows Phone was never vulnerable. it says it right there in the article
- detaro 9y agowhops, missed that.
- brndnmtthws 9y agoAs a slightly related side note, I pretty much only turn on bluetooth when I actually need to use it (which is rarely, such as syncing my Garmin every now and then). It's a waste of battery power to keep it on, and Bluetooth is also often used to track people. For example, it's used by traffic monitoring systems to measure the speed of traffic[1] by storing and tracking the MAC address. It would be nice if Android and iOS provided a convenient way to activate Bluetooth temporarily, only when needed. [1]: http://www.tyco-its.com/products-and-services/urban-traffic-control/bluetooth-travel-timespeed-measurement-system http://www.tyco-its.com/products-and-services/urban-traffic-...
- sillysaurus3 9y agoIt's already patched Well, yes. But how long has the exploit been effective? It's certainly noteworthy. A coworker once demo'd a metasploit module capable of taking over a Windows 7 machine. The vuln had long since been patched, but apparently it was still useful in the field sometimes because people hadn't bothered to upgrade every workstation.
- flachsechs 9y ago> convenient way to activate Bluetooth temporarily, only when needed the slide-up menu in ios is pretty convenient.... you can do it when the phone is locked, even. i use it all the time to disable and enable wifi and bluetooth and use the flashlight.
- brndnmtthws 9y agoIt'd be nice to use NFC to temporarily activate Bluetooth for a given device, for the duration of use. Even better if it generated a random MAC address every time you established the connection, and handle auth entirely in userspace through encrypted channels. You could bypass the stupid Bluetooth auth.
- tedunangst 9y agoPlus an option to temporarily enable and disable the NFC radio!
- mpclark 9y agoI've noticed that, starting quite recently, Bluetooth has always been off every time I've gone to use it on my trusty old Nexus 5. I figured it was the sort of bug that tends to accumulate on old phones, but maybe not eh?
- joe890 9y ago>It's already patched. This refrain is tired and myopic. We must operate with the assumption that like BadUSB, heartbleed, and this latest attack, there are likely devastating vulnerabilities present in all devices we use and actors may have the chance to exploit them before we ever become aware of them or have the opportunity to apply a patch.
- azinman2 9y agoWhat is the actual exploit? Article was very thin on details....
- Ajedi32 9y agoHere's the whitepaper: http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Paper.pdf http://go.armis.com/hubfs/BlueBorne%20Technical%20White%20Pa...
- codedokode 9y agoFrom description of vulnerability in Linux Kernel bluetooth code: > This function receives a configuration response buffer in the rsp argument, and its length in the len argument > Each element it unpacks from the configuration response is validated and then packed back onto a response buffer, which is pointed to by the data argument. > However, the size of this response buffer is not passed into the function C developers are repeating the same mistake for years. Why don't they invent some type or class for safe work with memory buffers?
- nokcha 9y agoThere have been attempts to do so. One ongoing project that looks promising is CheckedC: https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc/releases/download/v0.6-final/checkedc-v0.6.pdf https://github.com/Microsoft/checkedc/releases/download/v0.6... https://www.microsoft.com/en-us/research/project/checked-c/ https://www.microsoft.com/en-us/research/project/checked-c/
- hossbeast 9y agoPerformance.
- nomel 9y agoHow would this be performance? Not checking a length, resulting in an overflow, should be a warning. Whatever it takes to make that happen needs to happen. This is beyond silly.
- fulafel 9y agoThis game of C vulnerabilities and patches has been going on on the Internet for 20+ years. It's largely an awareness problem, and prejudice toward safer languages.
- deleted 9y ago[deleted]
- dguido 9y agoAs per usual, Apple identified and fixed these bugs 2 major releases ago. Even if they had not, exploitation of them would have been strongly mitigated by sandboxing applied to every system service. Use an iPhone. On the other hand, Linux still does bluetooth parsing in the kernel, and Armis definitely found these by simply grep'ing for memcpy calls. There are few mitigating controls throughout the Linux, Android, and embedded device ecosystem. Linux is a security tire fire. At the very least, I have to give Armis credit for a detailed technical writeup. It goes above what many other firms have done in similar situations. Full disclosure: I am quoted in the ArsTechnica article.
- baybal2 9y agoIndeed, Linux's monolithic kernel design will mean that such errors will be continuing popping up.
- jacquesm 9y agoThe one has nothing to do with the other. I'm a big fan of microkernels but this class of bugs has nothing to do with whether or not you use a micro kernel or a monolithic one.
- dguido 9y agoThat's not true, it strongly affects the ability to separate privileges and apply sandboxing. For example, compare Apple's Seatbelt, which was a comparatively light lift to the intrusiveness of SELinux or restricted token sandboxing on Windows.
- language 9y agoIf by class of bugs you mean "munging the stack," yes - but the difference is in the effect on integrity of the total system. In monolithic kernels, if an attacker can monopolize on the situation (by defeating mitigations, if any) and control execution-flow, they can run code on ring 0. This isn't the case if you're on a microkernel where a bluetooth driver lives in userspace.
- 9y ago
- baybal2 9y agoI wonder, if a physical "chain reaction" attack described is possible. Back in mid naughties, the "MMS of death" chain reaction attacks on Sony Ericsson phones were so intense, that they were taking down cell networks through which they propagated, thus fizzling.
- pmontra 9y agoI got the update from Sony while I was reading the post. It's an Xperia X Compact and they've made a good job so far. Almost an update per month, it started with Android 6 and it's on Android 7.1.1 now, September patch level, which is safe according to the post. Bluez for Ubuntu 16.04 LTS instead is old, from March 2016. There is a newer Bluez from August 2017 but it's probably for newer versions of Ubuntu. I hope they patch it quickly for everybody.
- debunn 9y agoWe've had a number of folks at work ask if their Android phone will be patched, so I thought it would be helpful to list the Android Open Source Project (aka: device operating system) versions that will be receiving the necessary patches [0]: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0 Note: it will likely take some time for your handset manufacturer to test and release the patch for your specific phone. 0: https://source.android.com/security/bulletin/2017-09-01 https://source.android.com/security/bulletin/2017-09-01 (see CVE-2017-0781, 0782, 0783 and 0785)
- blfr 9y agoOf course my Motorola (X Play) is getting no updates so I get to spend the evening installing LineageOS and reconfiguring the phone. Should have treated it like a computer: wipe the manufacturer's software right away and install a free alternative. Pretty sad that random opensource projects are offering better support than the companies I paid for their products.
- Animats 9y agoIs it a C buffer overflow? - Edit: Yes, it is, on the stack.
- mtzaldo 9y agoIs the playstation 3/4 vulnerable to this?