Comment by izacus
14 hours ago
"An app can bypass OS security system with certain setting enabled" absolutely fits into CVEs. There's no "depends: on it.
I love how quickly you all forget about security and privacy when it gives a chance to angrily rant.
Anything can fit into CVE.
"An app can bypass OS security system with certain setting enabled" is absolutely a valid CVE. We have countless examples every day of vendor apps bypassing OS security systems because they're allowed to do so.
"A device can bypass protective layers and cause soft tissue damage when thrown" is an absolutely fine CVE, too.
Whether it matters or is something that should be addressed, is the depends part. Here we're talking about CVE that's at risk of trying to address a feature.
You are forgetting the most important questions of security, without which the whole discussion becomes pointless:
Who is securing what, and from who?
CVEs seem much less like holy writ when they're aimed at protecting the device for commercial interests and from the device owner.
Apps being able to bypass a restriction put on them by the OS always matter.
Whether that means there's a _feature_ lacking there, is another question.
The OS provides restrictions and permissions so that the user can apply them to apps.
If the user chooses to free certain apps from restrictions, that should be their choice.
But if a piece of software overrides the users' choice, that certainly qualifies as a CVE.
This is an important distinction! The user must always have final say.
Whether an app breaks out of the sandbox and steals my vacation photos, or the OS sets new restrictions I can't remove, both are wrong.
Any piece of software has to act in service of the user, and ONLY the user. It must not do things or set restrictions without the users consent. No means no.
a lot of cves are of the type "if you leave the keys in the door, then anyone can unlock it and get in! We must destroy all doors, they are insecure!"
This is one of them
This is not one of them. This is "the lock accepts any key" type of CVE.
> In adbd_tls_verify_cert of auth.cpp, there is a possible bypass of wireless ADB mutual authentication due to a logic error in the code. This could lead to remote (proximal/adjacent) code execution as the shell user with no additional execution privileges needed.
Patch: https://android.googlesource.com/platform/packages/modules/a...
Docs:
> EVP_PKEY_cmp() return 1 if the keys match, 0 if they don't match, -1 if the key types are different and -2 if the operation is not supported.
The original code cast the integer return value to boolean, and -1 and -2 cast to "true", therefore authentication would succeed if the key types were different or the operation wasn't supported.
You jest, but passkeys seem to have literally been invented to address something like: "Keys to your doors can be used by anyone to open those doors, regardless of your knowledge or presence".
Which is a problem only if the third party acquired those keys without your permission, but the industry decided to "fix it" regardless.
I changed the sudo settings to not require a password.
Now an application on my computer can obtain root without user interaction.
Where is my CVE?
Same. There are so many things you could mess up without root from my account anyway. My account isn't a locked down one. You could alias sudo to a keylogger, for instance, and then do whatever as root the next time I sudo something.
So the password check really has no point. Typing sudo is still a lightweight sanity check, otherwise I may as well just log in as root.
When half that security is aimed against the user it's pretty easy to cheer for cracks in it.
Sounds like the Settings panel is a CVE, we should immediately get rid of it. And don't forget the Play Store!