Hacker News Reader

Comment by dguido | Hacker News Reader

As 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.

View on HN

> Apple identified and fixed these bugs 2 major releases ago.

Huh. Did they pass the information back to the relevant vendors, or just keep it in their toolbox for when they needed to say "See, Android is so insecure!"?

Edit: this is probably snarkier than it should be, but without reading a 30+ page white paper on my phone these seem to be OS and library issues not chipset issues. Did Apple do a big Bluetooth fix on their own stuff, or are they using (and fixing) some of the same libraries without passing vulnerabilities back to the library maintainers? I don't follow Apple enough to know.

It looks like Apple's implementation diverges substantially from other vendors, and is likely not based on the same stack at all.

I'm not so convinced Linux is a "tire fire". Just about everything has vulnerabilities and needs to be occasionally patched, doesn't mean we need to get into some sort of holy war every time there's a new exploit for one device or the other.

That said, Android's lack of updates for older devices is its biggest weakness. Google is looking to fix this next version as they separate the HAL out. Something to look at is definitely if there would be a standard kernel with loaded modules or if it would still be left to manufacturers.

No, Linux is qualitatively worse off since it keeps bug-dense code in areas of high privilege with few mitigating controls.

Yes, there will be bugs but refusing to properly address that ahead of time by separating and lowering privileges, applying sandboxes, and proactively auditing external attack surface is why Android is worse than iOS for security.

I'm not disagreeing that it's poorer for security, but in practice under most threat models you'll be able to patch in time for it to not even matter. And you'd still need to patch, even if it was nicely sandboxed - getting access to just the bluetooth stack could allow emulation of a keyboard or internet connection. Let's not forget that Apple has had trivially exploitable vulnerabilities in the past too - I'd argue that Linux's recent history has been significantly better in that department actually, despite the technical merits of the mitigations being worse.

There's no PoC code out for this even and it's been many times longer than it would take to patch something like this in most cases.

What I'm saying is that going from "Linux has worse security design" to "use an iPhone" is just a non-sequitur - people choose devices and operating systems for reasons other than the best security design and there's no reason that an attack like this should force you onto a single platform. It comes off as nothing more than fanboyism.

If I have to wait 3 minutes for a bus instead of 2, I am 'qualitatively worse off', but that extra minute doesn't flip into being 'a tire fire'.

>Linux is a security tire fire.

Perhaps I'm missing something, but why are you calling Linux a tire fire when it has had significantly less code execution and buffer overflow exploits than iOS?

Definitely missing something.

The CVE counts say otherwise.

Do you have a data source to back up your claim? It doesn't sound right.

http://www.cvedetails.com/product/15556/Apple-Iphone-Os.html...

http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html...

first, exploits and vulnerabilities are different if related things. If you're showing links to CVEs, I'm guessing you meant vulnerabilities not exploits.

The number of reported vulnerabilities does not have a strong correlation at all to how vulnerable something actually is. People pay hundreds of thousands of dollars for apple bugs; indeed apple does. Based on the above data, I'd even suggest that it "proves" iOS is significantly more secure. The bounties available for Linux are minuscule.

Indeed, Linux's monolithic kernel design will mean that such errors will be continuing popping up.

The 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.

If 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.

That'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.

Reply on news.ycombinator.com