[jd smithers]

German srlabs has published an update to their IMSI catcher app called snoopsnitch, which can be used to verify the patch level regarding the official patch errata.

Article on wired:
https://www.wired.com/story/android-...ates-from-you/

App itself:
https://play.google.com/store/apps/d...bs.snoopsnitch

Motion is reporting:
Patched: 142
Not patched: 2 (cve-2017-0784 & cve-2017-5056)
After claimed patched level: 0
Test inconclusive: 53
Not affected: 0

[thurask]

BlackBerry powered by Android Security Bulletin – September 2017 -- BB specifically mentioned patching CVE-2017-0784 in September, hmm...

[conite]

German srlabs has published an update to their IMSI catcher app called snoopsnitch, which can be used to verify the patch level regarding the official patch errata.

Article on wired:
https://www.wired.com/story/android-...ates-from-you/

App itself:
https://play.google.com/store/apps/d...bs.snoopsnitch

Motion is reporting:
Patched: 142
Not patched: 2 (cve-2017-0784 & cve-2017-5056)
After claimed patched level: 0
Test inconclusive: 53
Not affected: 0

Already a discussion:

https://r.tapatalk.com/shareLink?url...2&share_type=t

[conite]

BlackBerry powered by Android Security Bulletin – September 2017 -- BB specifically mentioned patching CVE-2017-0784 in September, hmm...

They may not have been vulnerable. Or it may be a false negative in the app. We'll likely never know.

[jd smithers]

BlackBerry powered by Android Security Bulletin – September 2017 -- BB specifically mentioned patching CVE-2017-0784 in September, hmm...

Exactly... And cve-2017-5056 should have been in june 2017 patch. Maybe false positive?


Sorry for double post

[falcotec]

KEYone BBB100-2 is reporting:
Patched: 142
Not patched: 2 (cve-2017-0784 & cve-2017-5056)
After claimed patched level: 0
Test inconclusive: 53
Not affected: 0

[maurs]

Android Priv STV100-4 reports
Patch Level 5 october 2017 - Build AAQ280
Patched: 146
Patch Missing: 4 (CVE-2016-3917, CVE-2016-5348, CVE-2017-0382, CVE-2017-0478)
After claimed patched level: 13
Test inconclusive: 49
Not affected: 0

[EskeRahn]

Android Priv STV100-4 reports
Patch Level 5 october 2017 - Build AAQ280
Patched: 146
Patch Missing: 4 (CVE-2016-3917, CVE-2016-5348, CVE-2017-0382, CVE-2017-0478)
After claimed patched level: 13
Test inconclusive: 49
Not affected: 0

Same on unlocked debloated AT&T branded STV100-1 with the 'mystery' AAW068 build.

One of the 'missing' is for fingerprint, and this should DEFINITELY have been under "Not affected" - so take the output with a pinch of salt...

[gizmo21]

All in all this is really disapointing, that manufacturers are even allowed to claim a device fully patched even if it isn't.
What is the delaying on monthly security-patches, if they can just pretent to patch to the correct level

Hey @Bla1ze how about getting some inside information if TCL is really "Blackberry powered by Android" or only Alcatel and getting an article on main-page about it?

[EskeRahn]

All in all this is really disapointing, that manufacturers are even allowed to claim a device fully patched even if it isn't.
What is the delaying on monthly security-patches, if they can just pretent to patch to the correct level

Hey @Bla1ze how about getting some inside information if TCL is really "Blackberry powered by Android" or only Alcatel and getting an article on main-page about it?

Before blaming someone for foul play, I think we should make sure that the evidences are credible. Could you please explain to me why you believe that this software is flawless?

I found an easy to spot bug in the output in seconds, so why should the rest be flawless?

[gizmo21]

Before blaming someone for foul play, I think we should make sure that the evidences are credible. Could you please explain to me why you believe that this software is flawless?

I found an easy to spot bug in the output in seconds, so why should the rest be flawless?

Well that is why some infos from the source (TCL or BlackBerry) would be welcome. Perhaps they left some out on purpose, but without any verifiable statement I always believe independent security researchers that put in 2 years for that:
https://conference.hitb.org/hitbsecc...evel-analysis/

[conite]

Well that is why some infos from the source (TCL or BlackBerry) would be welcome. Perhaps they left some out on purpose, but without any verifiable statement I always believe independent security researchers that put in 2 years for that:
https://conference.hitb.org/hitbsecc...evel-analysis/

https://m.androidcentral.com/mobile-...-you-something

[thurask]

https://m.androidcentral.com/mobile-...-you-something

From the comments:

"I feel like Jerry's piece doesn't address this issue. That original article was about OEMs falsify the accuracy of the current security level, not whether the device was still reasonably secure. It's the lying about what the security patch level is currently installed on the device that's the issue."

As much as the true impact of OEMs leaving updates out is unknown, since the fix is in the OS, applying some snake oil like Lookout or Norton or DTEK won't address the issue, even if SRLabs were in the business of selling it. OEMs must either pull up the slack with regards to updates (Chinese OEMs especially) or clarify false positive/negative results.

[conite]

From the comments:

"I feel like Jerry's piece doesn't address this issue. That original article was about OEMs falsify the accuracy of the current security level, not whether the device was still reasonably secure. It's the lying about what the security patch level is currently installed on the device that's the issue."

As much as the true impact of OEMs leaving updates out is unknown, since the fix is in the OS, applying some snake oil like Lookout or Norton or DTEK won't address the issue, even if SRLabs were in the business of selling it. OEMs must either pull up the slack with regards to updates (Chinese OEMs especially) or clarify false positive/negative results.

...argues "DMP89145". ¯\_(ツ)_/¯

I still don't know if the tests are 100% accurate, or whether it was an actual vulnerability that had already been addressed on BlackBerry Android, or whether they were actually patched in a non-expected way. This speaks to methodology and the need for corroboration of the technique.

But I do agree that it doesn't really speak to whether or not the missing 2 of 200 patches is meaningful from an overall security standpoint.

And, even if confirmed, do those 2 "missing" patches imply an oversight, an error, or an outright deception.

[EskeRahn]

...argues "DMP89145". ¯\_(ツ)_/¯

I still don't know if the tests are 100% accurate, or whether it was an actual vulnerability that had already been addressed on BlackBerry Android, or whether they were actually patched in a non-expected way. This speaks to methodology and the need for corroboration of the technique.

But I do agree that it doesn't really speak to whether or not the missing 2 of 200 patches is meaningful from an overall security standpoint.

And, even if confirmed, do those 2 "missing" patches imply an oversight, an error, or an outright deception.

Exactly.
And if we should look very strict on their output we do know that the tests are NOT 100% accurate, since it claims that the Priv ought to have a Fingerprint patch. So their credibility is dubious. And someone with suitable knowledge would need to check what the other claimed 'missing' patches is actually all about, and as you said whether they could be part of later patches. (or also are NA)

I'm NOT saying that I know if they are right or wrong, but we need credible evidences before claiming that BB or any other companies are cheating based on this. For all we know SnoopSnitch could just be flawed test-software.

[gizmo21]

First of all I can't see them selling something to the enduser so far, dispite that free app.

Secondly they don't claim to be perfectly analysing that level as they can only do a binary analysis by comparing instead of having sourcecode. That's the whole point of their analysis:
"Apply binary-only patch heuristics"

Thridly they also clearly state that having not found patch signature doesn't mean it is not mitigated otherwise or it is a false positive:
"* Vendor created alternative patch
* Vulnerability requires a specific configuration
* Bug is simply not exploitable
* Errors in our heuristic (it happens!) "


Then they clearly state that a missing patch doesn't mean your vulnarable:
"– A missing patch does not automatically indicate that a related vulnerability can be exploited"
"Owing to this complexity, a few missing patches are usually not enough for a hacker to remotely compromise an Android device. Instead, multiple bugs need to be chained together for a successful hack."
"§ Also found Android exploitation to be unexpectedly difficult"

And at last they updated their table from the presentation slide on their website and https://srlabs.de/bites/android_patch_gap/ now list devices from BlackBerry separately from TCL and they seem not to be that bad as TCL:


But it is still unclear wether e.g. KEYᵒⁿᵉ is a BlackBerry or TCL in their report.

All in all a statement from BlackBerry / TCL would still be welcome.



---
Can't link image inline with mobile browser atm and CB-App crashes

[EskeRahn]

First of all I can't see them selling something to the enduser so far, dispite that free app.

Secondly they don't claim to be perfectly analysing that level as they can only do a binary analysis by comparing instead of having sourcecode. That's the whole point of their analysis:
"Apply binary-only patch heuristics"

Thridly they also clearly state that having not found patch signature doesn't mean it is not mitigated otherwise or it is a false positive:
"* Vendor created alternative patch
* Vulnerability requires a specific configuration
* Bug is simply not exploitable
* Errors in our heuristic (it happens!) "
.
.

Nice with some facts on the app, thanks.

The problem is that people might draw too hasty conclusions from the number of 'missing' patches. Maybe they would cause less confusion if they called the category "Not found" rather than "Missing"
We should also remember that they for a very large part (over 25%) does not say anything either way, so these could be either patched or not.

[tubularbell]

I feel that it would make a difference TCL / BlackBerry Mobile and BlackBerry are willing to clarify the results with a statement. When you use security as one your main USP's you should act when that security is in doubt or being questioned.

[EskeRahn]

I feel that it would make a difference TCL / BlackBerry Mobile and BlackBerry are willing to clarify the results with a statement. When you use security as one your main USP's you should act when that security is in doubt or being questioned.

Indeed, that could be a good idea. BUT the big question is would those that distrust them in the first place believe a statement?

Think of e.g. sex scandals of current and earlier US presidents "I did not have sexual relations with that woman"... or

[tubularbell]

Indeed, that could be a good idea. BUT the big question is would those that distrust them in the first place believe a statement?

Think of e.g. sex scandals of current and earlier US presidents "I did not have sexual relations with that woman"... or

Well, I guess that this is not very difficult to prove with some backup files. So the statement could be that the missing patches were solved otherwise, and that testing the patch files should prove that, or whatever way they can think of.

[EskeRahn]

Well, I guess that this is not very difficult to prove with some backup files. So the statement could be that the missing patches were solved otherwise, and that testing the patch files should prove that, or whatever way they can think of.

The problem is that it is often relatively easy to plant a doubt on honesty.
On the other hand it is almost impossible to prove that anyone is always honest.

...That is what fuels any conspiracy theory.

It is a similar to a circular argument. We need to believe the proof they put forward, or believe who ever tests what they do put forward for testing....

But sure they could go open source, but I doubt they will be willing to do that - even for a retired product like the Priv, as it may still have elements in common with current models and/or use software technology they sell in other products..

[EskeRahn]

Maybe we should turn this thing up side down!

What about a competition with a prize for each claimed patch for the first person that was able to exploit the vulnerability in question?
(The competition could be limited to devices freshly applied with newest Autoloader)

Maybe Crackberry, Blackberry or TCL would be willing to potentially donate current BB devices of the winners choice? If they have patched as they say, they would run no risk!
OR we could all chip in to a crowdfunded prize-pool for this purpose. I would gladly give $10 to that.

A good place to start for any hacker would be those that SnoopSnitch claims are not patched, or those where they are inconclusive.

[anon(10218918)]

First of all I can't see them selling something to the enduser so far, dispite that free app.

Secondly they don't claim to be perfectly analysing that level as they can only do a binary analysis by comparing instead of having sourcecode. That's the whole point of their analysis:
"Apply binary-only patch heuristics"

Thridly they also clearly state that having not found patch signature doesn't mean it is not mitigated otherwise or it is a false positive:
"* Vendor created alternative patch
* Vulnerability requires a specific configuration
* Bug is simply not exploitable
* Errors in our heuristic (it happens!) "


Then they clearly state that a missing patch doesn't mean your vulnarable:
"– A missing patch does not automatically indicate that a related vulnerability can be exploited"
"Owing to this complexity, a few missing patches are usually not enough for a hacker to remotely compromise an Android device. Instead, multiple bugs need to be chained together for a successful hack."
"§ Also found Android exploitation to be unexpectedly difficult"

And at last they updated their table from the presentation slide on their website andhttps://srlabs.de/bites/android_patch_gap/ now list devices from BlackBerry separately from TCL and they seem not to be that bad as TCL:
https://forums.crackberry.com/attach...y_vendor-1.png

But it is still unclear wether e.g. KEYᵒⁿᵉ is a BlackBerry or TCL in their report.

All in all a statement from BlackBerry / TCL would still be welcome.



---
Can't link image inline with mobile browser atm and CB-App crashes

For a manufacturer building "the most secure android devices" it should be important to comment on this. Or do they play silly funny games with the people?

[anon(10268214)]

Everyone here should already know that BlackBerry Android phones don't need updates anyway.

Thurber: "...we believe our phones are inherently more secure..."

http://blogs.blackberry.com/2017/12/...nthly-updates/

Why all this distrust? Lol.

[anon(2695703)]

I will liken device security to living in glass houses, but the glass should be bulletproof. (From the OS perspective... not from the user data, obviously)

I think there would be more trust in security patching if distribution of said patches was less fragmented.

Not a fan of Apple in general and certainly not claiming that the iOS ecosystem is without fault, but Apple does do some things that help us trust what they've done. For example:

• clearly spelling out what CVE patches are included on their security content page.
• not creating fragmented operating system versions.

Some may argue regarding fragmented OS's, but my point is that iOS 11.1 looks and functions the same, regardless of hardware model and carrier. Meanwhile, we have seemingly a nonsensical mishmash of AAT123 ASQ298 etc etc etc. Having a numbering system where bigger (theoretically) means better security is simple and easy to follow. (Let's avoid batterygate, and POWERD implications for now...)

The treatment of PRIV has not helped build credibility. Yes, there is a recent patch. Supposedly, it mitigates Meltdown/Spectre. Or does it? We honestly don't know. The powers that be haven't told us. We're guessing, because those are the only recent publicly announced vulnerabilities that could prompt BB/TCL to get its OS dev team to work on a device they stopped committing resources to.

Without looking at source code, what can we do to ensure our devices are up to date and secure? In the end, I agree that BlackBerry Mobile needs to be more transparent.