This is kind of scary :(. How does one ensure that they aren't vulnerable to this bug?
replies(7):
https://support.apple.com/en-us/HT207923 https://support.apple.com/en-us/HT207922
https://source.android.com/security/bulletin/2017-07-01#broa...
https://android-developers.googleblog.com/2017/06/2017-andro...
To me, the takeaway from this is that unless you are using a "flagship" device, or one sold directly by Google, you're probably not getting updates in a timely manner.
> Broadpwn is a fully remote attack against Broadcom’s BCM43xx family of WiFi chipsets, which allows for code execution on the main application processor in both Android and iOS.
But it doesn't go into any details on this privilege escalation actually works for iOS and more specifically that it doesn't require additional exploits. Can anyone explain this in more detail? If this actually allows code execution on iOS application processor, that means we have a jailbreak right?
BlackBerry: PRIV
Fujitsu: F-01J
General Mobile: GM5 Plus d, GM5 Plus, General Mobile 4G Dual,
General Mobile 4G
Gionee A1
Google: Pixel XL, Pixel, Nexus 6P, Nexus 6, Nexus 5X, Nexus 9
LGE: LG G6, V20, Stylo 2 V, GPAD 7.0 LTE
Motorola: Moto Z, Moto Z Droid
Oppo: CPH1613, CPH1605
Samsung: Galaxy S8+, Galaxy S8, Galaxy S7, Galaxy S7 Edge, Galaxy S7 Active, Galaxy S6 Active, Galaxy S5 Dual SIM, Galaxy C9 Pro, Galaxy C7, Galaxy J7, Galaxy On7 Pro, Galaxy J2, Galaxy A8, Galaxy Tab S2 9.7
Sharp: Android One S1, 507SH
Sony: Xperia XA1, Xperia X
Vivo: Vivo 1609, Vivo 1601, Vivo Y55
How could it possibly be detrimental for Broadcom to have free software drivers?
This article is a poignant example that it is detrimental for them to continue to keep their drivers proprietary.
The other more obvious privilege escalation is that there is still a kernel driver on the application processor talking to the chipset. There is per se no reason to distrust data coming from the chipset, so these often aren't written as defensive as they should be and could contain trivially exploitable assumptions on what the chipset will send and do.
I'm not sure it's fair to assume iOS IOMMU isn't set up properly just because that's the case on many (most?) android phones. According to the author, most android phones don't even have KASLR which iOS had since iOS6. I would assume IOMMU exists and is working properly unless someone has evidence otherwise (quick google shows very little information on iOS + IOMMU). If a DMA attack is indeed successful on iOS devices, I think that would be substantial enough to write about.
> The other more obvious privilege escalation is that there is still a kernel driver on the application processor talking to the chipset.
I would consider that a separate exploit--but even then you still need a KASLR bypass (another exploit?) at the very least to gain control.
> so these often aren't written as defensive as they should be
On the contrary, the market rate for a iOS jailbreak chain is upwards $1 million USD so I'd be surprised if a single exploit gives you full system control.
Every wifi chipset has working drivers; therefore there is little to no value in Broadcom's driver as "IP".
Contrast that to the value of having a free driver that can receive security patches from anyone at any time.
One way of attacking would be to intercept someone's internet traffic, and redirect them to a different site (ie, instead of going to Google, you go to get-hacked which looks just like Google).
Well, they patched something. Maybe they just patched the firmware image that is loaded onto the chipset on boot and there was no privilege escalation onto the iOS application processor. But if there was, the obscurity means criminals can easily look at the patch to see what it was and exploit that while the public knows nothing.
There's no abstraction or 'concept' of arrays there. You are literally just telling the compiler to take a certain pointer and move i steps ahead.
This implies they have code execution on the application processor just from broadpwn (and not additional safari/ios exploits). Hijacking internet traffic is indeed serious but tech blog sites are already picking up on this and blowing it up. Example: https://9to5mac.com/2017/07/20/broadpwn-wifi-vulnerability-i...
> PSA: Update to iOS 10.3.3 to fix serious wifi vulnerability allowing attacker complete control
Or something. That analogy sounded better in my head than written down. The point is that IMO the blame lies squarely with the C language: it's a language that's used in a lot of complex parsing code and provides pretty much nothing to help with this, and if anything actually puts roadblocks in the way.
http://www.securitytracker.com/id/1027894
They needed it to get the camera working. This is not an exaggeration, the people they have writing software for their phones will take every shortcut they can find or imagine to deliver another bullet point on the feature list. Security be damned.
I expect a network card to not 'interpret' my traffic in a similar way.
The way the drivers + backing architecture are built contains tons of IP and things that they would very much not want their competitors seeing.
Our team built our reputation and relationship on keeping that data separate and confidential despite working with just about every vendor out there.
Are you aware that atoi("a"); is undefined behavior? It can crash, it can launch nethack, it can return 0.
This list shows the models with a MAJORITY OF DEPLOYED DEVICES running a security update from the last two months.
If you outfitted a police force with guns without safeties and hair-pull triggers, and you have any sanity, you're not going to be surprised if the rate of accidental discharges goes up. Programmers use their programming languages a lot more frequently and with a lot less care.
So, sure, let's tell the programmers to be more careful. But the most careful of programmers know they'll still make mistakes, and seek out ways to aid themselves in catching those mistakes instead of hoping they can will them away. One such aid can be choosing another programming language that doesn't share C's language mechanics.
Put another way - programmer's mistake for choosing to use C's language mechanics. You could argue that's technically not saying it's the fault of C language mechanics, but I'd say that's splitting hairs at the best.
You could share the blame with a failure to properly fuzz, and insufficient use of static analysis. I'd be okay with that too.
How do you figure? The detectability of infringement is a key factor in deciding whether to file a patent.
Regardless, copyright infringement might also be an issue.
It isn't that it would be realistically detrimental, it just has no value to the individual attempting to change the established course of the ship
In other countries (most of Asia), where there is no discivery, it's almost impossible to prove hardware or software patent violations so your case is kicked out of court immediately, even if your patent claims are valid and their product reads into your claims. That's why most patent suits end up in the US or Europe (or in the even faster ITC import injunction).
Reading assembly with no comments is a different skill than reading C or C++, especially since it's not always clear what's an instruction and what's data, but it's still reading code, and there are tools to help you trace through it. And most of the drivers aren't writing code like it's a 64k demo (where the code is the data, and the data is the code, and they both modify each other)
so if you buy that car and you do that, it's your fault regardless of how poor the car design is
pretty sure trusting user provided data without validation is the programmers fault regardless of language
Most wifi adapters fail at least one of these requirements under windows or linux.
Excellent!
> it's in the manual
It's not in MSDN: https://msdn.microsoft.com/en-us/library/yd5xkb5c.aspx
It's not in the manpages: https://linux.die.net/man/3/atoi
Cppreference understates it has having an undefined return value, rather than undefined behavior outright: http://en.cppreference.com/w/cpp/string/byte/atoi
Tutorialspoint defines the behavior as returning 0, and fresh2refresh makes no mention of undefined behavior.
My eighth google hit for atoi finally, finally, gets it right: http://pubs.opengroup.org/onlinepubs/9699919799/functions/at...
If you buy or pirate a copy of e.g. the C89 standard, or refer to one of the free draft versions, it's of course properly documented there too. Neither shows up in the first 50 google results, naturally.
And, of course, by google result 9, we're back to square one - incorrectly defining the behavior as being "returning 0": https://en.wikibooks.org/wiki/C_Programming/stdlib.h/atoi
That's likely because having to pass it in and out of functions and libs that don't expect your special structure might cause it to have an invalid length, and then all your special wrappers can become a liability and not an advantage through either assuming your bufs are valid, or defensively checking more than is necessarily because they can't know whether it was altered or not.
> stdlib doesn't provide them either
Which is the real problem. That would make them a de facto standard, and a lot (but probably not all) of the problems would be mitigated by people accepting the performance trade offs needed to make them safe.
Manufacturers currently have no choice but to ship devices running vulnerable application software that communicates with remote devices using vulnerable protocols. This is facilitated by vulnerable operating systems running many vulnerable device drivers communicate with devices that themselves have embedded processors running yet more vulnerable software.
All manufacturers can do is keep patching the morass of code that their offering depends on, but most device manufactures can't even manage that, or if they can they are unable do it fast enough and unwilling to do it for long enough.
Reverse engineering silicon to figure out if you used a specific type of patented algorithm is super hard.
Looking at open source code is waaaay easier.
Competitors could review the code and "copy" how great features work without actually copying the code.
Because they are used as a front/vector for US intelligence agencies. Opening this firmware would not allow for the distribution of these implants.
Actually we often give up features and specialize with high level languages. That's why there are things easier to do in Ruby than in C++ and vice versa.
They are all (usually much more convenient) subsets of assembly.
2) Do apple/google have binary image from Broadcom or rather source code?
It is quite interesting how this patch production/delivery process works.
EDIT: From another comment [0], unfortunately if you've been holding out on updates like I have you'll have to upgrade to 10.3.3.
https://9to5mac.com/2017/07/20/broadpwn-wifi-vulnerability-i...
How many of your non-professionally-technical friends could tell you the manufacturer of their WiFi chip? Is it on the box? Could they even tell you who Broadcom is?
"Intel NIC" only recently became a very minor selling point in enthusiast desktop motherboards. I'm not holding out hope this is going to follow a more informed curve.
The gatekeepers (manufacturers) are the only ones informed enough to make the decision en mass. And they're not going to do so without a market reason. So barring something like "Broadcom stops providing security updates" or "New law holds device manufacturers liable for security bugs" they're going to save the few cents on BoM and continue using them.
Typically it's loaded during the boot process. On Linux, see the binary blobs in /usr/lib/firmware or: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
Source: I did some work with some broadcom (wired) firmware years ago and found it to be pretty unpleasant.
http://ipxe.org/gsoc/bnx2 and https://github.com/dewyatt/bnx2-fw-utils
If your wifi chipset is known to be compromised, and there is a remote exploit available, as in this case, then merely connecting with wifi to an evil hotspot is enough to compromise a device.
Once a device's been compromised, crypto signatures on update files won't protect you, as the signature checking itself can no longer be trusted.
An open ideology is one where everyone wins, even those who aren't on your team. The closed one is mostly to protect ones own team. I don't consider any of the reasons to be good reasons, personally. Commercially necessary, perhaps, as a conforming act as part of the "super-state", also perhaps.. but nevertheless, the best conclusion is that this situation is rotten enough to motivate someone to fix it.
Me personally .. I'd love to have the sources for every sub-processor/component in my system. It would be of immense value - commercially and otherwise - to me as an end-user. I hope I don't sit alone in this market...
The driver is not deeply protected IP. They will hand out full copies to any device manufacturer that uses they're chipset, so that they can integrate it with their systems. The secret sauce, the bit that they won't share with anyone even if it's necessary for debugging, is the on-chip firmware. That's the stuff they take seriously. The driver itself is just a lawyer thing.
The driver is indeed "protected" for IP-lawyer reasons; they'll have it out under license to every Tom, Dick, and Jane looking to build a device with their chipset. The firmware, on the other hand, is very closely held, because that's where the chip's functionality lives. A WiFi chipset implements a fantastically complicated protocol, and no one wants to bake that into hardware that can't be updated as bugs are found; so they build relatively simple hardware, and slap a microcontroller right on the die that runs all the complicated logic.
This means that the microcode is as sensitive as The hardware specs on earlier generations of hardware; a competitor with a copy of that source can make a (perhaps better and improved) knockoff if they're not too worried about legal implications like, say, several dozen Chinese knockoff shops.
echo $original_comment | sed 's/driver/firmware/g'Similarly, cheaper chips often don't support optional performance-enhancing features at layers 2 and 3 (link and MAC) that boost performance without any hardware investment.
FRONT
TOWARD ENEMY
The easiest example being b/g channel 13. You're permitted to use it for WiFi in most of the world, but not North America. Keeping the firmware proprietary and "secure" is likely an important part of their FCC/IC certifications.
2. These weren't drivers. Did you read the article?
3. The larger share of the blame belongs to Apple. Why does Apple trust devices like this that are essentially independent computers? Why should anything this chip does be able to take over the phone and install software on it, in privileged mode, that replicates itself?
4. Why can't you see things rationally?
So IMO it's absolutely pointless trying to argue with them in the first place. They are set in their ways and while a good chunk of them are pretty strict and excellent in what they do, they are not open to any changes.
I would be the first to agree that Go and Rust aren't ready to start replacing drivers but IMO people should start trying! (Or invest in LLVM some more?)
C/C++'s faults aren't ever going away. They're too convenient in their target area. I am against the overly-used "disruption" term -- I happen to believe the USA tech blogosphere bastardized the term long ago -- but IMO the systems programming area is very, VERY overdue for disruption.
It's time.
1. https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?...
However, arrays that are passed as arguments to functions decay into raw pointers, at which point you lose information about its length.
In C99 with rather spotty support. And never with malloc and similar, which is how the vast majority of arrays are (and can be) created. And you can't return or store those dynamic arrays somewhere else without losing the size info, nor it can be declared static.
In other words, you're right but for very limited situations.