Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Saturday August 10 2019, @05:12AM   Printer-friendly
from the BlackHat-strikes-again dept.

Submitted via IRC for SoyCow7671

QualPwn Bugs In Snapdragon SoC Can Attack Android Over the Air

Two serious vulnerabilities in Qualcomm's Snapdragon system-on-a-chip (SoC) WLAN firmware could be leveraged to compromise the modem and the Android kernel over the air.

The flaws were found in Qualcomm's Snapdragon 835 and 845 WLAN component. The tests were made on Google Pixel 2 and 3 but any unpatched phone running one of the two SoCs is vulnerable.

Security researchers from Tencent's Blade team found that one one of the vulnerabilities (CVE-2019-10538, with a high severity rating)  allows attackers to compromise the WLAN and the chip's modem over-the-air.

The second one is a buffer overflow tracked as CVE-2019-10540; it received a critical severity rating and an attacker can exploit it to compromise the Android Kernel from the WLAN component.

The researchers informed both Google and Qualcomm about the flaws and exploitation is currently possible only on Android phones that have not been patched with the latest security updates that rolled out today.

Qualcomm on June 3 published a security bulletin to original equipment manufacturers (OEMs) to allow them to prepare the Android update for their devices.

The chip maker advises "end users to update their devices as patches become available from OEMs."

Despite patches being available, a high number of phones is likely to remain vulnerable for a long time as the devices may no longer be eligible for updates from the vendor.

Also, not all makers are ready to push the Android update when Google releases it. It is common to see security updates for phones still supported by their maker reach devices with weeks of delay.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by FatPhil on Saturday August 10 2019, @07:14AM (4 children)

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Saturday August 10 2019, @07:14AM (#878137) Homepage
    Or, they could open source it, and offer a bug bounty. And then with a million eyes, all their bugs would become shallow. And much wetting of pants in haliarious laughter would ensue, for a while, but it would be for their own good in the long run. And their customers. Not that they deserve any.

    Take a peek at https://www.qualcomm.com/company/product-security/bulletins - they're making newb errors left right and centre. Almost everything is an unchecked length and a subsequent overrun. I mean, literally that's coding 101.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by driverless on Saturday August 10 2019, @12:35PM (3 children)

    by driverless (4770) on Saturday August 10 2019, @12:35PM (#878198)

    Or, they could open source it, and offer a bug bounty. And then with a million eyes, all their bugs would become shallow.

    BBs are possibly some of the most inscrutable hardware ever produced. They're also the crown jewels for companies like Qualcomm. So firstly they'll never, ever ever release anything about them, and secondly even if they did only a handful of people would be able to do anything with it, all of whom already work for cellphone vendors.

    • (Score: 3, Informative) by Snotnose on Saturday August 10 2019, @01:29PM (2 children)

      by Snotnose (1623) on Saturday August 10 2019, @01:29PM (#878223)

      BBs are possibly some of the most inscrutable hardware ever produced.

      When I worked for Qualcomm we'd get these 1300 page pdfs for each baseband that were nothing but register and bit descriptions. They were all along the lines of "0x10342 flurgler control", with bit descriptions like "bit 0 - 1 = enable blingtron, 0 = disable. bit 1-3 - blingtron level", etc. The registers were grouped into subsystems, each subsystem had it's own 20-200 page document (hopefully) documenting what these registers actually did.

      --
      Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
      • (Score: 2) by driverless on Saturday August 10 2019, @01:43PM (1 child)

        by driverless (4770) on Saturday August 10 2019, @01:43PM (#878226)

        Yup, that's exactly it. And the icing on the cake was that not only were the docs unclear and obtuse, it wasn't uncommon to find parts where they were flat out wrong, e.g. describing something from three revisions ago, or something that was planned but never actually implemented that way. And there were undocumented interactions where if you did X in subsystem Y then subsystem Z would randomly corrupt data blocks of a certain hamming weight, and other craziness. You had to know which developer that created the subsystem to call in order to find out what was really going on, and how to fix it, which was usually "don't do that".

        • (Score: 3, Interesting) by Snotnose on Saturday August 10 2019, @06:47PM

          by Snotnose (1623) on Saturday August 10 2019, @06:47PM (#878393)

          I remember when they first put GPS in their basebands. Turned out GPS and the radio interfered with each other, so that if one was on the other didn't work. The design pipeline was so full 4-5 different chips went out to fab before we got the first one back and discovered the problem.

          Fun times! Qualcomm was the best place I've ever worked, by far.

          --
          Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.