131–140 of 171 posts
Earlier quoted context omitted.
They are a pointer and an offset with no validation of bounds. But that's OK: C is little more than a high level assembly.
I hate the term "high level assembly" when applied to C since it's loaded against assembly (in the sense of C as its superset) which is obviously not true. C is full of undefined behavior, assembly is not.
Earlier quoted context omitted.
10.3.3? "This update requires a Wi-Fi network connection to download." Frustrating. I read this update may be 80-100 MB. Apple, please let me use my mobile data as I see fit. (And a security patch is certainly a worthy use!)
Agree, this is irresponsible to not let us update over cellular I'm currently on vacation, which means that most of the wifi hotspots I'm connecting to are public. That's a big security risk in itself
Earlier quoted context omitted.
absolutely true. But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception.
> But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception. 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…
Could please someone explain, 1) if firmware is stored on a Wifi chip or rather loaded during the boot process? 2) Do apple/google have binary image from Broadcom or rather source code? It is quite interesting how this patch production/delivery process works.
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
Earlier quoted context omitted.
If a manufacturer makes and sells a gun that keeps going off in people's holsters and shooting people in the foot, the answer is not to say "it's the user's fault for not using it properly. I've shot myself in the foot hundreds of times and I don't blame the manufacturer". 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…
Tools exist that find this error in C code, more to blame the company that didn't use those tools and released code this important. Blaming the language solely... not sure it's productive. If the gun went off in my holster WITH the safety on then I'd blame the manufacturer. Same goes with using the right tools with C, if all steps were taken to do the right thing then I can say we should blame C. But there's not any…
Earlier quoted context omitted.
absolutely true. But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception.
> But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception. 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…
Earlier quoted context omitted.
absolutely true. But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception.
> But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception. 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…
Earlier quoted context omitted.
End users don't really matter to Broadcom. Chip makers don't sell product to end users, they sell to device manufacturers.
absolutely true. But manufacturers are not going to use a wifi chip maker known to be repeatedly exploited, because of end user perception.
C's lack of array size info strikes again: memcpy(current_wmm_ie, ie->data, ie->len); where "ie" points to data obtained from the net.
Programmer's mistake for not validating data, not the fault of C language mechanics. Yes it would be easier if , still gotta be careful. I've made plenty of these mistakes but never blamed the language.
Earlier quoted context omitted.
Agree, this is irresponsible to not let us update over cellular I'm currently on vacation, which means that most of the wifi hotspots I'm connecting to are public. That's a big security risk in itself
iOS security update files are crypto signed, so it's safe to download them on public WiFi.
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.