Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

blog.exodusintel.com

Post reply on HN
Print view View original

161–170 of 171 posts

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#161

Post by frankzinger »

revelation wrote: post #47
viraptor wrote: post #41

Earlier quoted context omitted.

> hacked together by the last kind of crowd you want working on them That was neither informative nor necessary, really... (And likely not true)

The leading Android smartphone producer Samsung had on at least two of their flagship phones a world RW device that allowed full access to the entire system memory including the entirety of the kernel, deliberately: 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 fi…

That's shocking, but it happened in 2012. How have they been doing for the past 5 years?

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#162

Post by vsl »

orf wrote: post #45
corndoge wrote: post #33

Earlier quoted context omitted.

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.

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…

> that keeps going off

If the C language (not even a compiler, the language) somehow magically inserted bad code or rewrote your good code to be buggy on its own, you'd have a point.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#163

Post by paulie_a »

azernik wrote: post #156
paulie_a wrote: post #82

Earlier quoted context omitted.

There is no benefit. They probably have an embarrassing code base that is full of garbage and a bunch of lawyers paranoid about IP. Why would any manager suggest to take that risk that has very little potential upside. 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

Judging from what I've seen of their drivers, yeah, their firmware/microcode is probably an embarrassing bug-ridden code base. But it also represents a lot of investment in low-level/low-layer features that they would prefer to hide from competitors (much more sensitive than the higher-layer logic in the driver proper).

While I can understand that sentiment and perspective. Those people are wrong, they are inconveniencing their competitors to a tiny degree and over estimating the value of those features due to the awful implenation.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#164

Post by mihular »

azernik wrote: post #156
paulie_a wrote: post #82

Earlier quoted context omitted.

There is no benefit. They probably have an embarrassing code base that is full of garbage and a bunch of lawyers paranoid about IP. Why would any manager suggest to take that risk that has very little potential upside. 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

Judging from what I've seen of their drivers, yeah, their firmware/microcode is probably an embarrassing bug-ridden code base. But it also represents a lot of investment in low-level/low-layer features that they would prefer to hide from competitors (much more sensitive than the higher-layer logic in the driver proper).

OTOH anybody can reverse engineer it. Just a tad bit more work.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#165

Post by throwaway47861 »

loonattic wrote: post #159
corndoge wrote: post #33

Earlier quoted context omitted.

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.

It's 2017. It's about time we had a better, well designed language (ie Rust, but I'm not sure if it's well designed enough, depends on what you want it for, too). There have been many advances in language research since the 70's that could be very useful for the kind of work C is used for. Saying we should stick to C because it's well established is like saying we should stick to assembly if it was well established.…

I've noticed that C and C++ have pretty fanatical and very narrow-minded fanbase. And I am talking about people of ages 50+ as well -- I was acquainted with several of them (in the real physical world) as well.

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.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#166

Post by justinjlynn »

Animats wrote: post #154
justinjlynn wrote: post #73

Earlier quoted context omitted.

There's a reason "THIS SIDE TOWARDS ENEMY" is a thing.

It's actually FRONT TOWARD ENEMY [1] https://en.wikipedia.org/wiki/M18_Claymore_mine

Fair enough. Thanks for the correction and additional information.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#167

Post by DiThi »

astrange wrote: post #94
JustSomeNobody wrote: post #26

Earlier quoted context omitted.

Probably referring to the fact that they are simply pointers into contiguous memory.

C doesn't have "memory" in the standard. They're pointers into a contiguous object, but anything before a[-1] or after a[sizeof(a)-1] is undefined aka it actually doesn't exist.

`sizeof(a)` only gives the size of the array when the size is specified at compile time. Either you accept e.g. `int[16]` as a type, or you pass a pointer (for which `sizeof` just returns `sizeof(intptr_t)`)

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#168

Post by zero_intp »

nucleardog wrote: post #157
azernik wrote: post #149

Earlier quoted context omitted.

In which case this is your answer; they're worried about knockoffs, because without the firmware logic their devices are simple commodities, ie don't really have strong differentiators from the competition.

The other hugely important side of this is that a lot of these devices have the ability to transmit on frequencies which they may not be licensed for, or may not be licensed for in all markets. 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 certification…

It is required(1). The FCC requires locking down the ability to transmit into regulated frequencies.

1. https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?...

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#169

Post by kbenson »

ams6110 wrote: post #105
JepZ wrote: post #46

Earlier quoted context omitted.

And yet another time we learn why it is better to use Lineage OS. Five year old Samsung S3: Android: Version 7.1.2 Security Patch Level: 5th July 2017

Guess I'll have to look at upgrading my diehard old Moto G. It's still on Android 5.1.1. Meanwhile I guess disabling WiFi is a mitigation?

> Meanwhile I guess disabling WiFi is a mitigation?

That's a good question. If it's disabled in firmware and not actually powered down, it might still be susceptible.

Re: Remotely Compromising Android and iOS via a bug in Broadcom's WI-FI Chipsets

#170

Post by nemetroid »

DiThi wrote: post #167
astrange wrote: post #94

Earlier quoted context omitted.

C doesn't have "memory" in the standard. They're pointers into a contiguous object, but anything before a[-1] or after a[sizeof(a)-1] is undefined aka it actually doesn't exist.

`sizeof(a)` only gives the size of the array when the size is specified at compile time. Either you accept e.g. `int[16]` as a type, or you pass a pointer (for which `sizeof` just returns `sizeof(intptr_t)`)

That's not quite right. Arrays always have a knowable length, and sizeof will give a correct result for variable length arrays as well.

However, arrays that are passed as arguments to functions decay into raw pointers, at which point you lose information about its length.

Post reply on HN