Taiwan-based MediaTek supplies chips for Android handsets and “internet of things” products. Their silicon powers 37% of all smartphones and IoT devices, according to market research cited by Check Point Software.
The four vulnerabilities discovered by the cybersecurity firm affect some of MediaTek’s systems, which combine a central processing unit with additional computing modules. Those modules include an artificial intelligence accelerator and a digital signal processor that performs audio processing tasks.
The vulnerabilities affect the digital signal processor. Three of them are in the processor’s firmware, the low-level software that controls how a chip operates. The fourth security issue was found in the hardware abstraction layer. The hardware abstraction layer is a technology that is used by a device’s operating system, in this case, Android, to control the chip on which it runs.
According to Check Point Software, the vulnerabilities can be used by a malicious Android application to infect a MediaTek digital signal processor with malware users. Hackers can install the malware by causing the processor to generate a software flaw known as a heap overflow. In a heap overflow, parts of a processor’s memory that contain application data are overwritten with malicious code.
By themselves, the settings cannot cause a severe risk because they can’t be accessed by Android apps under normal conditions. But access is made possible by a separate set of problems affecting a piece of software that the digital signal processor uses to coordinate its work with other components.
Check Point Software has added the vulnerabilities to the CVE system that the cybersecurity community uses to track cybersecurity flaws.
The vulnerabilities are tracked as following: CVE-2021-0661, CVE-2021-0662, CVE-2021-0663 and CVE-2021-0673.
]]>Dependencies have some integration cost, of course, but really good libraries or services—Stripe is a great example, or PostgreSQL—let us add them with almost no effort. They’ve successfully unbundled their area of concern from user code.
This goes for frameworks, too, and some languages. When they work, when they really get problems out of the way, it feels magical.
Over the last 15 years, many companies have begun to productize that experience.
Why is authorization so hard?
Authentication is the mechanism for checking who you are—like a log-in screen. It’s the front door to your app.
Providers like Okta/Auth0 and Amazon Cognito have APIs for authentication. Authorization is the mechanism for checking what you’re allowed to do—like what pages you can see, what buttons you can click, and what data you can touch.
It’s common to hack together a quick and dirty solution for authorization to start. Usually, that looks like some if statements and roles in a database. That can last a little while until you need to add more authorization features, like role hierarchies, nested objects, and relationships. Any entities that don’t map to a simple list of roles add complexity, and it’s hard to write that code without a plan.
Or, you might want to let customers define custom permissions. Or you might want to go multi-tenant or move to microservices. There might be any number of requirements you didn’t anticipate when, understandably (and often correctly), you started with some basic if statements. When that time comes, your team will inevitably do a big refactor (think six to 18 months) on a domain that’s not central to your business
To get a sense of why this is hard, imagine an application like Google Docs. You have docs that you own. You can view, edit, comment on, and delete these docs. You have docs and even folders that someone has shared with you. Maybe you can edit or just comment on these. There might be other docs for which you only have view access.
The system is controlling access across files and folders, orgs, teams—up and down, at varying levels, and preventing you from seeing docs that you shouldn’t. There are two key aspects of authorization:
The logic is specific to the application itself. How you’d build authorization for Google Docs is different from how you’d build authorization for something like Salesforce or Expensify.
The authorization controls the use of the application’s everyday data, so you’re going to need full access to that data. This means that the authorization system needs access to your application’s data, which will be in a different form for every app.
Every company goes through a custom design process to write custom code to solve its authorization problems. Thousands of companies, solving thousands of authorization problems, every day.
How to make authorization easier
So, if you were going to build an API or a library for authorization, it would need to address the two requirements noted above, along with making life easier for developers. It would need to: