People want the news now. They don't want to wait for it to be peer reviewed, or even cursorily checked. There is an infinite maw for information, and it has already consumed every single known fact.
If you want science, you'll wait a month, because it's not actually urgent. These species waited hundreds of millions of years and it'll still be there in a few weeks.
If you want entertainment, you want it right this instant. And that's what LiveScience exists to do.
So you really should have stopped reading as soon as you saw the URL.
I always thought the begging for support by critical infrastructure open source projects would eventually not be a thing. I, could, not, have, been, more, wrong.....
> It took less than 3 months of research to discover 6 separate bugs in the adsprpc driver, two of which (CVE-2024-49848 and CVE-2024-21455) were not fixed by Qualcomm under the industry standard 90-day deadline. Furthermore, at the time of writing, CVE-2024-49848 remains unfixed 145 days after it was reported. Past research has shown that chipset drivers for Android are a promising target for attackers, and this ITW exploit represents a meaningful real-world example of the negative ramifications that the current third-party vendor driver security posture poses to end-users. A system’s cybersecurity is only as strong as its weakest link, and chipset/GPU drivers represent one of the weakest links for privilege separation on Android in 2024. Improving both the consistency and quality of code and the efficiency of the third-party vendor driver patch dissemination process are crucial next steps in order to increase the difficulty of privilege escalation on Android devices.
Does this mean the vast majority of Android users (who are on Qualcomm chipsets) are vulnerable to these zero day attacks?
I also read between the lines something like "don't be surprised if we start to make our own chipsets and drivers, because current vendors can't be trusted to do a good job".
Even Apple failed at that, despite having bought out Intel's modem division and there being no other company coming even close to Apple's demand of hoarding knowledge in-house.
The problem is multifold:
- RF of any kind is extremely complex
- RF of any kind that is to be certified in virtually all countries on this rock, with providers with infrastructure from 2G shit that never got upgraded since the 90s to hyper-modern OpenRAN is even more complex simply due to all the cert and testing effort required
- making that RF stuff power efficient is the utter end game
- mobile communications standards on their own are a horrid, horrid mess to implement, not made easier by some of the specs being decades old and never intended to coexist in a world where a single device can run 30 gigabit a second...
- patents, so many patents, because of course it's a global standard that a) isn't open and b) everyone and their dog wants to profit off of
- on top of that come legal aspects: not just the certification requirements, but also lawful intercept and stealth ping stuff, or having to secure the device so that enterprising hackers can't readily turn it into an SDR, jammer or sniffer...
> - patents, so many patents, because of course it's a global standard that a) isn't open and b) everyone and their dog wants to profit off of
This is the only real problem. The other problems are challenging but surmountable engineering issues (which Apple already had solutions to, thanks to their Intel-modem acquisition).
There are plenty of Chinese basebands that work (code quality and security aside), because the CCP told Qualcomm to get bent in 2015.
All of the issue you described are specific to basebands, not all "chipsets and drivers", and this article is talking about exploits in DSPs, not basebands. Moreover, AFAIK the baseband (or more specifically the modem) is separated from the application processor on both iPhones and Pixels, so a baseband 0day allowing you to take over the entire phone is already unlikely.
For what it's worth, the DSP this driver talks to is the same type of DSP used in Qualcomm basebands.
However, there's actually no strong relevance to DSPs at all here; it's just a broken DMA/ION-shared-memory driver that happens to be the one that talks to a DSP. There are lots of these in most Android board support packages.
> separated from the application processor on both iPhones and Pixels
Across an interface with drivers! Quite a few baseband drivers are exploitable from both sides of the interface.
> so a baseband 0day allowing you to take over the entire phone is already unlikely.
The baseband has to talk with the main SoC though by some way, and wherever there are interfaces, so are drivers and associated bugs. And usually you get the baseband and main SoC from the same company, so same engineering culture. It's not like shoddy development isn't just happening on the baseband BSP side.
> All of the issue you described are specific to basebands, not all "chipsets and drivers", and this article is talking about exploits in DSPs, not basebands.
Power efficiency, patents and legal compliance crap also impact the main SoC/chipset side.
> Even Apple failed at that, despite having bought out Intel's modem division and there being no other company coming even close to Apple's demand of hoarding knowledge in-house.
The upcoming SE going on sale in 2025 is set to have the Apple modem.
For compute offload, Google has indeed done that - the Tensor chips have Google's TPUs instead of Qualcomm DSPs.
Both on these TPUs as well as on pre-Tensor hardware that had Qualcomm DSPs, Pixels would not allow apps access to the kernel interfaces. Access would be blocked or mediated via a separate service process ('binderized HAL').
(Some) OEMs have repeatedly opened access to these kernel interfaces in order to trade security for performance.
> Does this mean the vast majority of Android users (who are on Qualcomm chipsets) are vulnerable to these zero day attacks?
If not these precise ones, related ones yes. Certain chip vendors are notorious for not providing fixes of this kind to the manufacturers to roll out (maybe doing so selectively based on who they're extra special buddies with), if they ever even made them at all before moving on to the next shiny SoC.
The other side of this is Google never met a security problem that isn't solved by further coupling the system to their cloud, especially for updates. Coincidence?
> Certain chip vendors are notorious for not providing fixes of this kind to the manufacturers to roll out (maybe doing so selectively based on who they're extra special buddies with), if they ever even made them at all before moving on to the next shiny SoC.
Never heard that before. Chipset vendors are under maintenance contracts with their customers, so they are actually PAID to provide fixes especially for CVE's.
Manufacturers on the other hand have little to no recurring revenue from a device which could finance to implement, test and rollout each patch.
Care to provide a concrete example for your claim?, especially for this "extra special buddies" suggestion which insinuates that a chipset vendor developed a patch and still doesn't provide it to all its customers...?
If the chipset vendors never provide fixes except to customers that ask, and the customers never ask because it costs reimbursed money to do something with them, from the point of view of the end consumer, the chipset vendors haven't provided the fixes.
In PC hardware, the expectation is that most drivers are available both from the manufacturer of the device, and directly from the chipset vendors. Some chipset vendors don't play that way, but most do. In mobile, the expectation is that drivers only come from the device manufacturer and if there's no updates, it's hard to figure out who's at fault because there's no transparency.
For like 2 years per chipset. That's not very long. Also since every customer has its own kernel branch, not all of them get the fix just because it was made in one branch.
As an aside: Why can't DSL modems be a single USB dongle?
Those of us with DSL connections must suffer either an extremely limited selection of DSL modem/routers that can run Linux/OpenWRT, or have to suffer running a Linux/OpenWRT router behind a DSL modem (that often has proprietary and out of date firmware).
I'm just about to cancel my DSL, but when you run the modem in bridge mode, and run PPPoE on your actual NAT gateway if needed (which is sadly often the case), the modem firmware doesn't matter very much.
I put together some stuff so I could transfer PPPoE sessions to a backup system and then I could reboot the NAT boxes for upgrates with minimal downtime. Sometimes, it even worked ;)
When I last used DSL, I was using AT&T uverse (which is/was VDSL with multicast video layered in).
I configured the provided gateway/router-widget to provide a "DMZ Plus" mode for my router (a custom box running Tomato or OpenWRT or something), and I called to get ports 25 and 80 unblocked. And then, plus-or-minus some completely-surmountable difficulty with making dynamic DNS behave properly it all worked fine.
For years.
I never connected anything other than my router to the ISP-provided device.
There's probably some corner cases where this configuration falls flat, but I never ran into them.
What might be some practical advantages of what you suggest?
A device runs on electricity and performs a function. It consumes power at a rate of x.
You're telling me that a device that performs the same function will consume power at a rate of precisely x/2 simply by virtue of being plugged into USB?
There are fiber PON/ONU/UT/$JARGON in shape of an SFP module, though most customers don't appreciate such offering and therefore it'll be an upsell.
As for why not USB specifically, probably because such a device is inherently much faster and responsive in upload to the Internet than downloads, and therefore it makes less sense.
> As an aside: Why can't DSL modems be a single USB dongle?
They definitely existed in the UK for a time and were often supplied by ISPs. IIRC they were only supported in Windows XP, and drivers were never provided for Vista.
I tried for years to do similar when I lived in Australia. Though with a PCI/PCI-E card
ZyXEL if I remember correctly did make an ADSL2+ at the time PCI-E card. Literally just a DSL modem wired to a Realtek 8139 NIC. You could slap it in a Linux (or BSD, or Windows) PC and just use PPPoE to connect to the internet
Naturally it was impossible to order the damn thing and I never got to realize my dream of an "all-in-one" DSL Linux router.
After moving to DOCSIS (Cable) internet I ran into the same confusing problem. "Thankfully" with Fiber everything is just ethernet (more or less) now. But it was an infuriating time in the 2010's
How an entire article about rotary mixers fails to mention Rane or their legendary MP2016 mixer is wild.
It became one of the most commonly available rotary mixers, was the house mixer for many NYC clubs, and one of the mixers commonly found on tech riders of DJs who were the last to transition to CDJs.
Random bit of trivia: if you see old school photos or videos of rotary mixers in American clubs, sometimes it wasn't actually the Rane MP2016, but the Phazon SDX 3700: https://www.integralsound.com/sdx-3700-mixer It was the house mixer for Tunnel/Limelight.
I completely believe in evolution ........ but sometimes I find myself wondering how did evolution allow for something so intentionally diabolical to come around at the MOLECULAR level.
In addition I think you are making a false equivalence here. As a German citizen, I can only emphasize that grouping people along the "Jew" line and drawing hateful conclusions from it is a path to a dark place. I don't care what other scenarios might also be problematic, I can say without a doubt, the sentiment he endorsed is anti-semitic!
This is not whataboutism - I am not saying it's not wrong because others do it too, or that it's not antisemitism. I am not presenting any opinion or judgment. I am trying to understand whether it's considered to be the same or different.
BTW my grandfather was in a Nazi concentration camp. I guess that says enough about what I think. But my opinion is not the matter here.
> I am trying to understand whether it's considered to be the same or different.
Why does it matter in this conversation?
If you want an ethical discussion about a mildly related topic, please find someone else to have it with. I'm not interested in having that discussion with you here.
Our countries weren't conquered by foreign powers who set up occupation governments with blasphemy laws against the ruling classes. Please leave your German brainwashing on these topics at home.
Yes, NATO nations have marked Russia as the clear and designated enemy. So, any statements that that support Russia or Russians are very bad and wrong and will be down-voted. All statements that criticize Russia or Russians are very good and correct and will be up-voted. You are a Pro-Putin-bot if you disagree with this.
> Earlier this month, the European Union Court of Justice ruled that harmonized standards are a part of EU law, and thus must be accessible to EU citizens and residents free of charge.
> In 2018, two nonprofits, Public.Resource.Org and Right to Know, made a request to the European Commission for access to four harmonized standards—that is, standards that apply across the European Union—pertaining to the safety of toys. The Commission refused to grant them access on the grounds that the standards were copyrighted.
> Last week, the EU Court of Justice overturned the General Court decision, holding that EU citizens and residents have an overriding interest in free access to the laws that govern them.
Also Morrison & Foerster (aka Mofo) were involved in representing the nonprofits Public.Resource.Org and Right to Know to the ECJ. Not exactly cheap and not exactly small fries....
Zink: Provides OpenGL support for devices that only support Vulkan.
NVK: Newer open source Vulkan driver for Nvidia hardware. Different than the older existing nouveau driver which was largely developed with very very little Nvidia support.
https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected
Displayport is the better technology in every way possible.
reply