This is the kind of thing I'd expect to see utilized by state-level actors who in many cases may be able to obtain internal technical information and tools from vendors. I wouldn't expect this to become an in-the-wild exploit, but for targeted use by agencies with the resources and motivations to identify specific models, obtain them and test against them this kind of thing should be relatively easy.
As an example, what kind of Android device is best used for insomniac tweets? At one point I thought I saw mentioned that it was a Samsung device a generation or two old, so perhaps a Galaxy S5 suitable for tweeting from the tub? That's a known-vulnerable device, elderly by Android standards of "who gets updates" meaning that Samsung and the carriers don't put any priority on it. Sure you can look at things like LineageOS, but since part of the problem here is in the proprietary firmware blob of the chipset there may still be problems that aftermarket OS upgrades aren't going to touch.
For that matter, is Trump's possible change to an iPhone within the last month[1] related to this, and has it stuck of does he still have a Samsung floating around as seems to be the case?
I would totally expect this kind of thing to be already in the wild for the simple reason that people have been saying this sort of thing is possible for many years, it is just not the sort of thing that once the parties capable of doing it have found a practical exploit that they are then going to turn around and publish it to make the world a better place.
On the contrary, it will be hoarded and used against suitable targets.
In the wild as in "being actively exploited" yes, that's quite possible, but it's not a practical exploit for large-scale hacks on devices.
The required firmware changes are likely to be somewhat different for each version of the radio hardware and firmware and each carrier's OS variants. That means that you'd either need a very sophisticated set of exploit code (which means complicated and bulky when you may not have a lot of space to play with and may be working in hand-optimized assembler) or that you need to narrow your focus to only specified handsets. Even after that, you then have to have a WiFi access point pushing this, so even if you're in a high-traffic area such as a city downtown or an airport you're going to impact a relatively small percentage of devices.
If you have control of a large botnet of compromised WiFi routers you might be able to push this from those, but the more you do that the more likely you are to be discovered, and you're still going to have the problem of selectivity.
What this all translates to is that exploiting this on a wide scale would require a lot of resources and extremely skilled developers while also being at fairly high risk of detection. Using this for highly targeted attacks on the other hand would allow for less work generalizing the attack and could probably go undetected. Further, if someone not a state actor has "weaponized" this their best option for making money on it would likely be to sell the exploit to either a government or to one of the groups who specializes in targeted hacking.
It all depends on who you are. Politician or CEO of a multinational or a company related to defense? Political activist? Enemy of the state? The opposition? Hacker?
It doesn't have to be 'large scale' to be effective and given how hidden an attack like this could be (and how easy it would be to erase the fact that it was even there) it may have been used on your device and you still wouldn't be aware of it or able to prove that it was.
If you do a little bit of "open source intelligence" you can find the author of this exploit used to be employed in an Isreali Defense Force - Elite Technological Unit.
Read between the lines where he got the idea to do an exploit like this.
I dunno about revolving. The pay in the private sector is very good. Tons of folks who worked in the IDF end up at tech companies for two reasons:
(1) almost everyone goes through the IDF thanks to mandatory service
(2) if you have aptitude you end up in the signal Corp, who are good at what they do.
I wouldn't call this a conspiracy, and the parents speculation is very thin. If the author got this from the IDF they almost certainly wouldn't be publishing; breaking that kind of confidentiality can end really badly
In the case of the Broadcom exploits being discussed in this series of articles, yes, the iPhone is almost certainly more secure than most (all?) Samsung devices with Android. In particular, the iOS 10.3.1 update released a week ago addresses "An attacker within range may be able to execute arbitrary code on the Wi-Fi chip" and credits the author of these articles and Google Project Zero. Because most iOS updates aren't carrier restricted (maybe on Verizon?) that update should be available to any device capable of running iOS 10.
If there are corresponding releases from Samsung I don't remember seeing any mention of them, and even so they'd presumably be waiting for carriers to approve them so there's a chance that some of them will be released by the time people are replacing their current phones anyway.
As for LineageOS, they may be able to address things in the driver, but in my somewhat outdated experience most ROMs don't touch the radio firmware. Radio firmware updates are a completely separate item.
Supported Google Nexus and Pixel phones have the fix as well, I see "Remote code execution vulnerability in Broadcom Wi-Fi firmware" listed on the April update:
I'd regard Nexus and Pixel phones to be the equivalent of iPhones for something like this - they get updates directly from the "manufacturer"/Google, much as iPhones get updates from Apple.
Samsung-branded devices sold primarily through carriers on the other hand get updates when they finish passing through the system of Google->handset maker->carrier and often both the handset makers and carriers are big delay points.
That's strange, do you have auto-updates disabled? My understanding is that it was immediately released. My Nexus 6P has it, I got it the same day it was released or a day after. Screenshot of my About Phone screen:
These write-ups are amongst the best stuff on HN in the last year or so. Fantastic content.
I'm not too hopeful on getting this kind of problem permanently solved though, but one thing that could be done is that manufacturers should treat the radio assembly as hostile rather than friendly.
Completely agree. Google gets some rightly deserved hate on HN, but I think their work on Project Zero and other security efforts is exemplary (I'd love to see Apple do the same).
Hat as well tip to the many individuals that contribute to Android security [0]. Especially Chinese companies, academics, and individuals, who often don't have the best reputation here either, but contribute a huge amount of the security bug reports to Android.
It's about time regulators start to require publication of full firmware source code and build stacks. Even Google's power apparently is not able to enforce Android vendors (and IC vendors) to such standards.
The reason is simple: closed-source blobs are a danger to society as they leave exploitation to those with the highest budget (i.e. secret services) or a bit of luck (the "usual" rooters). Furthermore, having source code reduces electronic waste as independent developers can carry on offering support.
Closed source somehow prevent most exploits to be found. I truly don't believe that open source would do more good than it would harm the general public.
Only as long as the binaries can't be extracted from the device. Once that is possible there is no reason to put closed source above open source with respect to safety, open source at least has the (debatable) advantage of having a lot of people looking at it. Closed source but binaries available is the equivalent of security by obscurity.
Another way to look at this: if you're into reverse engineering looking at the disassembled code is as good and in some cases even better than looking at the source because the source shows you the intent whereas the assembly shows you what is actually going on which might be subtly different, different enough to sometimes have a little edge.
I see this kind of statement often, but I've yet to see evidence supporting it. The kind of actors who even have the ability to execute this kind of exploit wouldn't easily be stopped by a closed source codebase. My theory is that the security of open source firmware would be equivalent to that of closed source firmware in the worst case.
I agree. What OP is saying is akin to "if my lock is stronger, then the bad guys will go find another target". This never stops targeted attacks, APTs etc. If anything, it engenders a level of complacency, right up to when a breach occurs...
(and of course, in the "good ol days" of hacking, being a more difficult target actually meant being a more prime target, since that's how repuations are built... oops!)
> The Wi-Fi chip managed to DMA into the physical address range containing the host’s kernel, without any interference! This finally confirms our suspicion; either there is no SMMU present, or it isn’t configured to prevent the chip from accessing the host’s RAM.
Lack of IOMMU and no memory protection on the Wi-Fi IC was really awkward (but sorta expectable).
However, it's kinda shocking to me that they'd go to the trouble use a magic ethertype to tag internally-originating synthetic frames but completely neglect to strip out externally-originating frames with that magic ethertype.
I'm less shocked by that than I am by the fact that they still apparently aren't hiring external auditors. At this point it seems to me that it would be cheaper to hire an auditor (even after initial shipment, so no time-to-market problem) than to get black eyes like this one.
As an example, what kind of Android device is best used for insomniac tweets? At one point I thought I saw mentioned that it was a Samsung device a generation or two old, so perhaps a Galaxy S5 suitable for tweeting from the tub? That's a known-vulnerable device, elderly by Android standards of "who gets updates" meaning that Samsung and the carriers don't put any priority on it. Sure you can look at things like LineageOS, but since part of the problem here is in the proprietary firmware blob of the chipset there may still be problems that aftermarket OS upgrades aren't going to touch.
For that matter, is Trump's possible change to an iPhone within the last month[1] related to this, and has it stuck of does he still have a Samsung floating around as seems to be the case?
[1] http://money.cnn.com/2017/03/29/technology/trump-iphone-andr...
edit: more neutral