12 ms·
Over 400 vulnerabilities on Qualcomm’s Snapdragon chip
- deleted 6y ago[deleted]
- maxdo 6y agoIs there any related data for Apple?
- skrowl 6y agoThey have a lot too, a new one just popped up a few days ago https://www.bgr.in/news/apple-products-have-a-new-unpatchable-security-flaw-in-the-secure-enclave-chip-details-specifications-vulnerability-jailbreak-906524/ https://www.bgr.in/news/apple-products-have-a-new-unpatchabl... I'm not sure if anyone has compiled a list of how many
- compscistd 6y ago> The report notes that this security flaw is present in all the devices running chips between A7 and A11 Bionic. Apple has already fixed the exploit in A12 and A13 Bionic chips so newer devices are safe. That's four generations of Apple hardware, the latest being iPhone X and iPhone 8/8 Plus (Sept 2017). The patch being fixed in A12 means the iPhone XR and iPhone XS (and later) are unaffected.
- supernova87a 6y agoI wonder if Apple/others knew about such vulnerabilities, and passed up on using the chip as a risk? Or, was it just dumb luck that they avoided this?
- DudeInBasement 6y agoIf you have connections to the real infosec world. They'd avoid it.
- saagarjha 6y agoNot sure what you mean?
- deleted 6y ago[deleted]
- jandrese 6y agoFrom Apple's perspective Qualcomm has been insufficient for a long time for many reasons, the security issues here would only be one of the many factors involved in the decision to do their own development. For what it is worth, a modern chip as complex as the A* series is essentially guaranteed to have vulnerabilities. Maybe not 400, but definitely not 0.
- josh2600 6y agoThis is a thing I think people constantly underestimate... Intel's cores are not necessarily dramatically more broken than everyone else's chips, they just pay for more auditing and public research.
- yjftsjthsd-h 6y ago> they just pay for more auditing and public research. Did Intel finance the research that turned up any of the major headline vulnerabilities over the last few years (meltdown, spectre)?
- monocasa 6y agoThey did not.
- Polylactic_acid 6y agoIt was a Google researcher mostly.
- GeekyBear 6y ago> Meltdown was independently discovered and reported by three teams: Jann Horn (Google Project Zero), Werner Haas, Thomas Prescher (Cyberus Technology), Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology) Spectre was independently discovered and reported by two people: Jann Horn (Google Project Zero) and Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61) https://meltdownattack.com/#faq-systems-meltdown https://meltdownattack.com/#faq-systems-meltdown
- cosmiccatnap 6y agoIt's more of an obsession with cutting costs to the bare minimum combined with a pretty good deal with ARM. Apple chips have bad just as many issues in terms of security.
- mohaine 6y agoLooking at the slides from a different article, these are not really in the chip per say but in the SDK. So any lib compiled to use the chip would be affected but not really a hardware issue. Basically fuzzy testing found 400 library calls that fail with segfaults. These can sometimes (but not always) be modified to do a takeover, but I didn't see anyone claiming to have done that.
- stefan_ 6y agoIt's even more intentionally misleading than that. The SDK generates wrapper libraries that allow you to interface with your code running on the DSP. Some of the wrapper functions generated have vulnerabilities. The 400 vulnerabilities are the few vulnerabilities found in the SDK template multiplied by how many different generated wrapper libraries they found. So you fix the handful of errors in the SDK templates and all the 400 vulnerabilities go away.
- jojobas 6y agoThe implication is that Apple's own chips are somehow bug-free, which they probably aren't.
- akshayB 6y agoHardware vulnerability and issues are hard to address at times as it can be connected to other vendor hardware or softwares. I always wonder if these flaws are left in the design intentionally or its just a sneaky bad bugs.
- ithrow 6y agoI guess this makes "national security" as an argument a bad joke.
- therealmarv 6y agounless they force everyone to buy Apple phones ;)
- harpratap 6y agoCheckM8? https://arstechnica.com/information-technology/2019/09/developer-of-checkm8-explains-why-idevice-jailbreak-exploit-is-a-game-changer/ https://arstechnica.com/information-technology/2019/09/devel...
- corty 6y agoNational security is and will continue to be a joke until there is strong regulation forcing all involved vendors to fix their crap for as long as their devices are used.
- wyldfire 6y agoAlso discussed here https://news.ycombinator.com/item?id=24081581 https://news.ycombinator.com/item?id=24081581 https://news.ycombinator.com/item?id=24092545 https://news.ycombinator.com/item?id=24092545
- walterbell 6y agoSpaceX designed custom SoCs for their isolated offshore/offworld network of Starlink satellites, https://spacenews.com/spacex-accused-of-poaching-chipmakers-employees/ https://spacenews.com/spacex-accused-of-poaching-chipmakers-... > Broadcom filed suit ... claiming SpaceX hired a number of Broadcom’s top engineers to develop “a family of sophisticated, customized computer chips.” The two companies had been working together on the development of advanced computer chips for an undisclosed project, but SpaceX ultimately ended the collaboration.
- oh_sigh 6y agoWhat's your implication here? SpaceX perhaps saw a bunch of security vulns and decided to DIY?
- fsflover 6y agoTime to switch to open source: https://en.wikipedia.org/wiki/Pinephone https://en.wikipedia.org/wiki/Pinephone https://en.wikipedia.org/wiki/Librem_5 https://en.wikipedia.org/wiki/Librem_5
- cestith 6y agoAn Open Source OS can help, sure, and is a start. A DSP is a programmable hardware device. Both phones to which you linked use variants of ARM processors and then use third-party baseband systems. You're not getting rid of closed-source hardware vulnerabilities by replacing Android or iOS.
- evilos 6y agoAgree, we need open source hardware (like RISC-V) to mature in order to eliminate this class of vulnerabilities. I haven't heard much on mobile class RISC-V SOCs though.
- jlokier 6y agoRISC-V is an open source ISA, which means anyone is free to implement it, interface with it, customise it etc. But most RISC-V devices are not open source as far as I know, as least currently. And a mobile class SoC would still be a very complex device, therefore with vulnerabilities (and also therefore with much less motivation for a company to open source the whole design). You'd have a similar problem as now. That said, if someone wants to work with me on a RISC-V mobile class SoC (or server/supercomputer class) do get in touch, I'd love to do it :-)
- fsflover 6y agoYes, you're not getting rid of closed-source hw vulnerabilities, but you get a lot of control. Librem 5 allows to replace the modem. Both phones ensure that it cannot access anything in the OS. You can also use killswitches if you require location privacy.
- xvilka 6y agoThere's Osmocom[1] for that. Sadly, it doesn't support modern PHY layers of the modem not modern baseband stack. It demonstrates, though, the possibility. I wish it had more traction. [1] http://osmocom.org/ http://osmocom.org/
- mschuster91 6y agoSeriously I'm beyond pissed at the state of Android, patches and open-source compliance. If we are lucky 10% of current phone models will get any form of update. The rest will be vulnerable for years until the devices finally break. And that's only the Qualcomm stuff. There is another CPU vendor beginning with M who is big in el-cheapo hardware - look at their Android kernel leaks, wherever you dig you find horrid, HORRID code. Google should mandate full open source disclosure of all GPL'd components as part of the Play Store certification and unlockable bootloaders, otherwise this shit is never going to change.
- daneel_w 6y agoAre you referring to the fabless bunch whose name starts with M and ends with ediaTek? :)
- BiteCode_dev 6y agoStill getting updates for my one plus 6. YMMV.
- ChuckNorris89 6y agoThat phone is barely 2 years old from a reputable brand, I sure as hell hope it's still getting updates. My older OnePlus 3 got updates for almost 4 years I think. Not bad, but it's not like apple's 5-6 years. Still, it was half the price of an iPhone with better hardware to boot so fair trade I guess. I don't like frivolous spending on phones but I never keep a phone more than 4 years anyway. The progress of camera, microphone and speaker quality alone across 4 years is enough of a quality of life improvement for me to upgrade. At this rate of Android security issues, my next phone will probably be the next iPhone SE but only if they update the display to a larger 1080p 90Hz panel and add an ultrawide camera lens, I don't care about anything else.
- Iolaum 6y agoYou are getting updates for the OS and kernel but not for device drivers. That's a big surface area for someone to hack your phone.
- daneel_w 6y agoThere seems to be some confusion on the authors' behalf about what a DSP is, and what an SoC is ("software" on chip, as they call it...) I'm just nitpicking, of course.
- wmf 6y agoI think you have a point here. When they say "DSP chip" instead of "DSP core inside the Snapdragon chip" it makes me wonder what else they got wrong. I don't think the oversimplified language is any more approachable here. (As it happens I read the slides and this is a legit vulnerability but you'd never know it from the press release.)
- cosmiccatnap 6y agoThat's not bad actually. On par with apple when you put them head to head. If you think that's outlandish try comparing it to x86 which is riddled with undocumented opcode's and backdoors.
- ETHisso2017 6y agoIf the US government hadn't sanctioned Huawei, we could have an alternative to these chips.
- kanox 6y agoShouldn't proper IOMMU usage prevent this? In theory when properly configured the DSP or GPU should be unable to touch system RAM outside of buffers that are specifically assigned to them. I'm not very familiar with the status of IOMMU on Android devices.
- monocasa 6y agoIt's dependent on the SoC whether there's IOMMUs at all and whether they're rigged up to all the bus masters in the system. A lot don't have them as it was seen as a virtualization feature rather than a security feature for the longest time.
- cbsks 6y agoHere's a link to the DEF CON talk: https://www.youtube.com/watch?v=CrLJ29quZY8 https://www.youtube.com/watch?v=CrLJ29quZY8
- sp332 6y agoWhile they are still withholding info about how to exploit the bugs, there is more technical detail in their Defcon talk, "Pwn2Own Qualcomm Compute DSP for Fun and Profit" https://www.youtube.com/watch?v=CrLJ29quZY8 https://www.youtube.com/watch?v=CrLJ29quZY8
- AdmiralAsshat 6y agoDo any of these vulnerabilities let us unlock the bootloader?
- segfaultbuserr 6y agoI wonder how would it be like to fill application forms for over 400 CVE numbers, or reading a security advisory with the first page exclusively occupied by CVE numbers. Well, seriously speaking, they'll probably group these vulnerabilities and apply a big one.
- wmf 6y agoKeep reading; there are 6 CVEs assigned. The 400 is different binaries that have the same vulnerability.
- throwmemoney 6y ago“A single SoC (Software on Chip) may include features to enable daily mobile usage such as image processing, computer vision, neural network-related calculations, camera streaming, audio and voice data.“ Should be SoC (System on Chip)
- joemazerino 6y agoGoogle has pushed the patch for this back to October. I wonder what will happen to downstream vendors (Samsung, CopperheadOS)?
- ta17711771 6y agoYou mean GrapheneOS.
- joemazerino 6y agoI'm referring to businesses because they have SLAs or other customer obligations. AFAICT Graphene isn't a business but is a FOSS project without customer support requirements or obligations.
- rStar 6y agoinsecure by design
- jamisteven 6y agoYou say vulnerability, we say feature.
- LoveMortuus 6y agoWould having an open source chip with a rolling release be more secure? Like as soon as the vulnerability is discovered you would push the fix and the next generations would already be fixed. Or would such frequent changes to the chip design be to difficult to mass produce, due to having to modify the production process? This is coming from a point of view that Linux is quite a success and thus maybe the same philosophy could be used for hardware?
- unionpivo 6y agofirst you have to have open source chip, and then have fabs willing to want to make it (and someone willing to pay them up front), and have phone makers want to use it.. And no changing chips every few months possibly breaking compatibility (people working around your bugs) is not a feature that a lot of hw designers want. This may change eventually. I have high hopes for RISC V but we will see
- HPsquared 6y agoHardware is different in that it can't be updated once it's leaves the factory and has to be "right first time".
- jaywalk 6y agoNot quite true: https://en.wikipedia.org/wiki/Intel_Microcode https://en.wikipedia.org/wiki/Intel_Microcode
- based2 6y agohttps://www.reddit.com/r/netsec/comments/i58ex8/new_qualcomm_chip_vulnerability/ https://www.reddit.com/r/netsec/comments/i58ex8/new_qualcomm...