"this has a known vuln", install in app details, uninstall/ignore/freeze in the Updates view

This flag must be settable per version. While the older versions of bla-suelz are know to be vulnerable the newer ones are not. Or this vulnarability is in version 3.14, but neither in 2.78 nor in 4.1... FreeBSD checks a database containing the CVE, the package name, the first vulnerable version and the last vulnerable version (if any), e.g. 4711,bla-suelz, 3.14, 4.0

Related to #1069 (closed).

mentioned in issue #1069 (closed)

Thanks @eighthave. I searched fdroidserver and notice that there is no specifics other than KnownVuln in the metadata. I guess this is a good start, but inevitably we are going to be fielding support requests from end users and upstream devs asking why an apk was marked as known vuln.

At the very least, we should add some info to the documentation so we can link to it (either directly from the client, or from support requests). I don't think we'll be able to embed enough detail in the metadata to explain to the user why it was vulnerable. At least, not in the foreseeable future - but happy to be shown wrong because that would be amazing to get shown "This depends on OpenSSL <= 1.0.1. See here for more details" for example.

@guest4711: It is per apk as @eighthave mentioned:

apk['antiFeatures'].add('KnownVuln')

changed title from "this has a known vuln", uninstall/ignore/freeze in the Updates view to "this has a known vuln", install in app details, uninstall/ignore/freeze in the Updates view

changed the description

A further consideration - what should we do if:

The installed version is vulnerable.
There is one or more newer versions available.
All newer versions are vulnerable too.

Should we exclude all vulnerable apks from the "suggested version" calculation? (Or should we still suggest the best version, regardless of if it is vulnerable?)

I tend to think that if both apps have the same known vulnerability, then we shouldn't try to discourage them from upgrading. There is probably other fixes in that new version, despite it having the same vulnerability as the earlier version.

Related: What if the only non-vulnerable version is an unstable update, but the user doesn't have unstable updates enabled?

Should we just warn the user and then suggest they uninstall?

For those interested, I'm implementing this UI for the Updates tab:

.

Starting with "We suggest you uninstall" and then will add support for "A newer version is available" afterward.

We pack an antivirus now? What vulnerability? You've also confirmed that it affects my device specifically? More details please... else this sounds like FUD.

@licaon-kter: Thanks for the questions. Are you saying we should answer these in the UI, or would you just like feedback about the feature in general?

Right now the server tools support looking for apps which compile against an old and known vulnerable version of OpenSSL. In the future, we can improve this scanning on the server to find apps with other vulnerabilities. @eighthave probably has more insight into what other things are planned for the future.

As far as FUD is concerned, I agree that there is a chance this could be a problem if the output of most automated vulnerability scanners are dumped into our metadata, because my experience is they tend to have many false positives. I'm currently having flashbacks to my last job where our clients would provide us with 75 page PDFs full of identified vulnerabilities, of which about one or two actually applied to our software. However I'm content with the current approach of looking for very specific, known vulnerabilities like the OpenSSL one.

Looking at the mock-up I see that notification staying there forever, right? I'm forced to uninstall it... I have no other option there...

That will become annoying fast, I'd rather have that button as MORE INFO, which takes me to app details and there, right before the actual app description have the text:

"O hay, this app... affected by CVE-xxx-xxx, recommended uninstall"

Also, if you don't have the app installed but you try to, another extra dialogue pops-up before downloading:

"O hay, this app... affected by CVE-xxx-xxx, recommended wait for update"

(with proper Settings->"Ignore vuln warning" just like root)

Definitely agree with @licaon-kter there needs to be a more info link with a reference to a CVE number. Otherwise you are left guessing what might be the problem with the app.

Also I'm not really sure I like the automatic Vulnerability tagging. You can use an old OpenSSL version with published CVEs and still be perfectly fine because you only use libcrypto and all vulns were in the tls handling code. What do you think about changing the text to "Might be affected by a security vulnerability"? Or "Probably has a security vulnerability and should be uninstalled."?

This will much more accurately reflect what an automatic scanning/tagging mechanism can do. Only if a CVE is actually published for a specific version of an app we really can tag it with a KnownVuln.

@pserwylo Let's keep this as simple as possible right now. So no changes to the suggested version, but that could be a good idea in the future. Same goes with using something newer than the upstream CurrentVersionCode.

@licaon-kter We have two active checks so far, with more coming. One is based on scanning for openssl versions, which Google Play also does. The other is based on the expired MD5 signature algorithm.

Right now, the known vulns are all about things that can be detected automatically. Adding links to CVEs would definitely be bonus, but that would only work with human input. Let's take the first step first so we can learn more. Then we can better improve it.

@licaon-kter: Thanks for your suggestions. I didn't realise that the UI mockup I posted above was missing the important notion of "Ignore" (which Hans did mention in this issue at the top). I'll be adding support for "Ignore" as well, right next to "Uninstall".

@Bubu, I agree with your assesment of the language around "We found a vulnerability" vs "Might contain a vulnerability". In this case though, I think it is okay to be assertive. I can't think of an upstream dev who would think it is unreasonable for us to flag an app with such a dependency. If my app was flagged as "Contains a vulnerability", my response is not to argue that I'm only using this 5% of the library which is not affected, my response is instead to update to a later, non-vulnerable version of the dependency and rerelease my app.

Unfortunately we are in this position where being technically correct (i.e. "May contain") may result in the users being less likely to listen. It reminds me of the academic discipline where they are (rightly) very conservative in what they say (e.g. "to date, there is no evidence to suggest...") vs what politicians and the media are able to say (e.g. blatantly stating things as true or false), and some people end up thinking the scientists are indecisive or inept, whereas they are actually the ones who should be trusted more. In our case, I think the benefits of being stronger with our language outweigh the negatives.

@pserwylo I think I agree that I even if I personally don't like it, it might be better to use stronger/clearer language here.

But I also think it's important to not annoy upstream devs with falsely flagged apps. It's annoying to be told by a random webapp you are trying to install that your setup is vulnerable because you are running an older version with backported security patches (aka debian). Or because they didn't bother to update their regex and you are actually using a version newer than they anticipated. I think I would be even more annoyed if such a warning would be shown to my users and not to me (the admin).

I looked at the code of the vulnerability scanner here but there are a few things I don't understand right now:

When does the scanner run? Only when building/publishing new apps? No, probably every day when repo updated are prepared, right? This means that at any point without warning (to upstream) your latest version could be flagged as unsafe. I feel this is not
Is there any way to automatically notify upstream that their latest version of an app was flagged as insecure? They might not follow the latest advisories for all libraries they use but still very much care if they knew.
When looking at the openssl check, what about apps linking against openssl 1.1.0? This is the newest version which has been released a year ago. Yet it would trigger the outdated version warning right now. (v1.1.0f is newest but 1.1.0e was the latest security update).

I guess what I'm trying to say that when you start tagging apps with a big red warning sign that says "This is unsafe to install" we better be damn sure they actually do something wrong.

Okay, one last thing. We should at least give the user the possibility to see the actual reason for the flag. (old openssl, whatever other checks there might be in the future). Otherwise they really can't do anything to find out more if it's actually dangerous (for them) to use the app. Also reporting this to upstream they can't provide any more detail other than F-Droid said this is bad. --> EDIT: This has been answered above I guess as not feasable right now. Mmh, I think there really should be a path from such a notification to finding out more about the specific problem. Can this specific antifeature just link to a wiki page for that app where further details (log of last vulnerability scan) is provided?

I think that the idea of communicating with upstream is very important. We had some discussions about this earlier in response to doing mass scans for vulnerabilities across all apks in the F-Droid repository. However, it is something we should probably revisit.

I suspect it isn't possible to automate this process. But at the very least a list in the wiki (e.g. such as the Repository Maintenance lists) would be quite helpful. Then we could have a manual process where we could notify upstream about such problems.

mentioned in merge request !558 (merged)

A big part of security is about hygiene. That means doing things because they are simple to do, and greatly improve your chances of avoiding problems. Hygiene is a good word here because its so similar to the concept in medical terms. People do not practice good hygiene because they can see the threat, or someone has proven that a particular spot in the kitchen has Anthrax. They do it because it is not hard to do, makes it more likely that they won't get sick, and helps the overall ecosystem. Most of the time, washing your hands before eating is a pointless exercise, if you measure it by provable illness on your hands.

These two checks are exactly that. Sure, there are still cases where using old OpenSSL versions or MD5 signatures is totally fine. But there have been lots of problems with those two, it is easy to detect their presence automatically, and it is not hard to avoid using them. So for the benefit of the whole ecosystem, developers should upgrade. So yes, we do want to annoy developers who are using old versions of OpenSSL and help users avoid them.

Google has decided the same with Google Play, and I support that decision.

There is definitely lots that can be improved here, and I hope that exposing it in the UI will raise people interest in working on this. FYI, there are currently no APKs tagged with KnownVuln in the main repo https://f-droid.org/repo, so we're doing OK in terms of false positives

The OpenSSL and MD5 scanner is run as part of fdroid update. That usually means whenever a new APK has been added, but someone running a repo can run fdroid update has often as they'd like. For f-droid.org its about once a day.

Automatic notification of upstream is a good idea, that's a contribution I'd love to see!

Oops, marking 1.1.0 as bad is a bug, I fixed that here: 4a15208b84d480ec3135b39c87b59234232e8d51

Here's the doc on how Google enforces this: https://support.google.com/faqs/answer/6376725?hl=en

Also, regarding the openssl thing, I'm very familiar with this issue since I've been maintaining projects that use openssl for non-TLS things (SQLCipher-for-Android, IOCipher, Orbot, etc).

mentioned in issue fdroiddata#810 (closed)

marked this issue as related to #40

mentioned in issue fdroiddata#869 (closed)

An easy and pragmatic way to inform the developper what is happening is to keep https://f-droid.org/wiki/page/Antifeature:KnownVuln up to date like this:

This APK has a known security vulnerability, found by one of the scanners in fdroidserver possible reasons can be

APKs with weak signatures: to fix the app developer has to release a new version
the app uses the vulnerable oppenssl lib xxx: to fix the app developer has to update the openssl-library reference to version yyyy or later

mentioned in merge request fdroiddata!2536 (closed)

I updated https://f-droid.org/wiki/page/Antifeature:KnownVuln and https://f-droid.org/wiki/page/Antifeature:DisabledAlgorithm.

Here's a screenshot of what this feature looks like:

closed via merge request !558 (merged)

mentioned in commit apparently/readonly/fdroidclient@8bececfa

mentioned in issue #1147 (closed)

"this has a known vuln", install in app details, uninstall/ignore/freeze in the Updates view

Child items ...

Activity

"this has a known vuln", install in app details, uninstall/ignore/freeze in the Updates view

Relates to

Activity