[bobshine]

You're right Bob, I don't understand your point. You are defending a device/company/software with the most vulnerabilities known to mankind. A system that has allowed immediate OTA access to any iPhone anywhere for years.
Spin and apologize for it all you want. I do not understand.

Defending what? You gotta learn how to read! I am just stating that discovered vulnerabilities isn't necessarily correlated to the safety of an OS.

For the sake of argument, lets pull out the number of discovered vulnerabilities in 2015 on Web OS, DOS 6.0 and make a comparison! Are you gonna say DOS 6.0 is much safer??? Let's pull out some numbers on Linux too while we are at it. Do I have to draw you a picture?

I have no doubt that BB10 is safer, and maybe safer than most OS out there... but... there is just as many people out there testing how secure BB10 is than Web OS or DOS...

[LazyEvul]

I have no doubt that BB10 is safer, and maybe safer than most OS out there... but... there is just as many people out there testing how secure BB10 is than Web OS or DOS...

That's the funny thing - there are valid arguments in favour of BlackBerry 10's security. It has plenty of good building blocks to work with. But the number of publicly known vulnerabilities has never been a valid argument. Anyone who's ever taken a science class should immediately recognize there's far too many uncontrolled variables at play there.

Heck, if your goal is to have 0 CVEs, there's a really simple remedy - threaten security researchers with restrictive EULAs, and don't submit CVEs for any bugs you've discovered on your own.

[Richard Buckley]

That's the funny thing - there are valid arguments in favour of BlackBerry 10's security. It has plenty of good building blocks to work with. But the number of publicly known vulnerabilities has never been a valid argument. Anyone who's ever taken a science class should immediately recognize there's far too many uncontrolled variables at play there.

Heck, if your goal is to have 0 CVEs, there's a really simple remedy - threaten security researchers with restrictive EULAs, and don't submit CVEs for any bugs you've discovered on your own.

Actually scientists are working at at the problem and known vulnerabilities does give reasonable results when property analysed. Here is just one paper I found:

https://www.google.ca/url?q=http://w...Vn50xtrBHlWgag

Computing Science is a science after all, with papers, journals, peer review and all. Before you discount an idea you should survey the body of prior work to see what the current state of knowledge is. Not as fast as reading a few news articles and repeating what you heard from someone else, but you usually get better information.

LeapSTR100-2/10.3.2.2876

[LazyEvul]

Actually scientists are working at at the problem and known vulnerabilities does give reasonable results when property analysed. Here is just one paper I found:

https://www.google.ca/url?q=http://w...Vn50xtrBHlWgag

Computing Science is a science after all, with papers, journals, peer review and all. Before you discount an idea you should survey the body of prior work to see what the current state of knowledge is. Not as fast as reading a few news articles and repeating what you heard from someone else, but you usually get better information.

LeapSTR100-2/10.3.2.2876

Did you even read that paper? It doesn't deal with the number of CVEs a product has at all - it deals with CVSS scores that assess the impact and exploitability of a vulnerability, as well as the lifecycle of a vulnerability (i.e. time from first-known discovery to time of patch).

I've spoken and listened to countless experts in the security field - not "what I heard from someone else," but people who research vulnerabilities or work a defensive role for a living. I have not met a single one that would consider the number of CVEs an acceptable method of gauging security. There isn't even a legal obligation for organizations to file CVEs to begin with, and it is common practice to not file them for certain types of vulnerabilities (among other issues).

If CVE count were treated as a serious measure of security, like I said, all it would take is increased secrecy and restrictive EULAs to bring those numbers right down - both of which would just be harmful to the security community at large. It's a laughable idea.

[Vistaus]

Defending what? You gotta learn how to read! I am just stating that discovered vulnerabilities isn't necessarily correlated to the safety of an OS.

For the sake of argument, lets pull out the number of discovered vulnerabilities in 2015 on Web OS, DOS 6.0 and make a comparison! Are you gonna say DOS 6.0 is much safer??? Let's pull out some numbers on Linux too while we are at it. Do I have to draw you a picture?

I have no doubt that BB10 is safer, and maybe safer than most OS out there... but... there is just as many people out there testing how secure BB10 is than Web OS or DOS...

Let's pull out some numbers for you as well then: the remaining user base of webOS and DOS 6.0 is next to none at this point so it's not worth any hacker's time to focus on finding flaws.
There's no doubt that BB10 has a small user base at this point as well, but unlike webOS (which, btw, is built on top of Linux) and DOS 6.0, BB10 still has 0.2% marketshare and that includes some governments (!) as well, making it worth any hacker's time to focus on finding flaws.

Posted via CB10 using my amazing BlackBerry Passport (OG Red)

[CharlieV]

Apple released an OS update yesterday that addresses this bug. ~10 days from the bug being discovered to world-wide release of an OS update.

Meanwhile BB10.3.3 (which is supposed to contain 'security fixes') is almost 5 months overdue from it's original 'scheduled' date.

BlackBerry didn't have the bug.

Ride or die:  PRIVelege-acy

[Richard Buckley]

Did you even read that paper? It doesn't deal with the number of CVEs a product has at all - it deals with CVSS scores that assess the impact and exploitability of a vulnerability, as well as the lifecycle of a vulnerability (i.e. time from first-known discovery to time of patch).

I've spoken and listened to countless experts in the security field - not "what I heard from someone else," but people who research vulnerabilities or work a defensive role for a living. I have not met a single one that would consider the number of CVEs an acceptable method of gauging security. There isn't even a legal obligation for organizations to file CVEs to begin with, and it is common practice to not file them for certain types of vulnerabilities (among other issues).

If CVE count were treated as a serious measure of security, like I said, all it would take is increased secrecy and restrictive EULAs to bring those numbers right down - both of which would just be harmful to the security community at large. It's a laughable idea.

Of course I read the paper, I didn't think I needed to draw the line for you but here goes.

The CVSS only works on known vulnerabilities. In fact we can really only work on known data. Different groups may have different lists off known vulnerabilities. The people who created the exploit that started this thread, for example, aren't limited to CVEs. So given what we know, even if that is only the CVE list, what can we do? We can bin them by product and compare the numbers, but as you say that has limited value. The paper describes one other thing we might do. Or we can throw our hands up because there are too many variables.

So what do all the people you know who work in defence do? I wager it starts from what they know, involves some critical analysis that leads to the synthesis of something they don't know upon which they can make a decision. For many people the starting point, what they know, is the CVE list. The point being that the CVE can be an important source of data, and there are scientific methods that can give insight into what you might expect to be absent from the list, particularly if you look at how vulnerabilities came to be listed, and how long they were known to someone before they were listed.

LeapSTR100-2/10.3.2.2876

[kvndoom]

Let's pull out some numbers for you as well then: the remaining user base of webOS and DOS 6.0 is next to none at this point so it's not worth any hacker's time to focus on finding flaws.
There's no doubt that BB10 has a small user base at this point as well, but unlike webOS (which, btw, is built on top of Linux) and DOS 6.0, BB10 still has 0.2% marketshare and that includes some governments (!) as well, making it worth any hacker's time to focus on finding flaws.

The hackers don't seem to agree with you.

Blackberry Poptart SE - Cricket Wireless

[mrlahjr]

The hackers don't seem to agree with you.

Blackberry Poptart SE - Cricket Wireless

+1
I would like a native Tor browser for BlackBerry 10.

TMO  PP SE,SQW100-4/10.3.2.2876

[bobshine]

Let's pull out some numbers for you as well then: the remaining user base of webOS and DOS 6.0 is next to none at this point so it's not worth any hacker's time to focus on finding flaws.
There's no doubt that BB10 has a small user base at this point as well, but unlike webOS (which, btw, is built on top of Linux) and DOS 6.0, BB10 still has 0.2% marketshare and that includes some governments (!) as well, making it worth any hacker's time to focus on finding flaws.

Posted via CB10 using my amazing BlackBerry Passport (OG Red)

0.2% is pretty close next to none! And that's my exact point. The closer you're to "next to none" the fewer discovered vulnerabilities there will be.

BTW, most hacker won't bother hacking an OS they don't know, they will just instead hack the laptop with Windows 10 at the CIA that they know... That doesn't mean that BB10 is more secure. Just that people aren't looking into it.

Again, my argument is that discovered vulnerabilities is by no mean a good indicator of how secure an OS is. I am not saying that one OS is more secure than another.

[LazyEvul]

Of course I read the paper, I didn't think I needed to draw the line for you but here goes.

The CVSS only works on known vulnerabilities. In fact we can really only work on known data. Different groups may have different lists off known vulnerabilities. The people who created the exploit that started this thread, for example, aren't limited to CVEs. So given what we know, even if that is only the CVE list, what can we do? We can bin them by product and compare the numbers, but as you say that has limited value. The paper describes one other thing we might do. Or we can throw our hands up because there are too many variables.

Or we can stop trying to use meaningless numbers and instead analyse qualitatively, which is by far the most common way I've seen of evaluating security. Here, for example, is a security audit of TextSecure (AKA the Signal Protocol): https://eprint.iacr.org/2014/904.pdf

Not a single time do they use numbers to draw any meaningful conclusions. It's all about qualities the protocol has - how well does it defend against specific kinds of attacks? How can any potential vulnerabilities be addressed? And if you were giving consideration to using Signal, you'd also be interested in how seriously recommendations like this are taken by the vendor.

This is how the experts I have met analyse security. Numbers can only capture so much nuance. I've only ever seen CVSS used by some IT departments to judge how quickly they need to be patching - and even that's imperfect, given that a CVSS does nothing to account for an organization's threat model.

But at the very least, CVSS is less flawed than going off of nothing more than the number of CVEs. CVSS at least tries to communicate impact & exploitability. Just counting CVEs? That tells us nothing.

[Richard Buckley]

Or we can stop trying to use meaningless numbers and instead analyse qualitatively, which is by far the most common way I've seen of evaluating security. Here, for example, is a security audit of TextSecure (AKA the Signal Protocol): https://eprint.iacr.org/2014/904.pdf

Not a single time do they use numbers to draw any meaningful conclusions. It's all about qualities the protocol has - how well does it defend against specific kinds of attacks? How can any potential vulnerabilities be addressed? And if you were giving consideration to using Signal, you'd also be interested in how seriously recommendations like this are taken by the vendor.

This is how the experts I have met analyse security. Numbers can only capture so much nuance. I've only ever seen CVSS used by some IT departments to judge how quickly they need to be patching - and even that's imperfect, given that a CVSS does nothing to account for an organization's threat model.

But at the very least, CVSS is less flawed than going off of nothing more than the number of CVEs. CVSS at least tries to communicate impact & exploitability. Just counting CVEs? That tells us nothing.

Yes that is a good piece of work, and I am familiar with it. Work like that does form a important piece of the security picture. But this is an analysis of the protocol as designed, it does not address the quality of the implementation of the protocol by the various vendors who are now using it. After all this thread is discussing coding quality and flaws, not protocol design. I never claimed that the paper I linked was a complete solution, I hope you don't believe that even if we had this level of quality analysis for every protocol and product the problem os smartphone vulnerabilities would be gone. Nor did I suggest that just counting CVEs was a good metric, but an analysis of CVE numbers using a scoring method can be very instructive. For example what do you conclude from a 10+ year old library that has a handful of important vulnerabilities listed month after month? With a numerical data analysis model you can monitor many more products than you can by reading qualitative analysis even if such analysis is available for all products of interest. But if you believe numerical analysis tells you nothing, who am I to disagree.

LeapSTR100-2/10.3.2.2876

[anon(9742832)]

It has already been proven that this hole was there in at least iOS 8 so I'm not sure why you're defending them? If it was there in at least iOS 8, they should've fixed it back then, easy as pie.

Posted via CB10 using my amazing BlackBerry Passport (OG Red) <3

Yea that's news..............a defect manifests its self years latter.................................Im sure that never has happened before............LOL

[gariac]

This could have easily been done on a BlackBerry. Read the story in depth from some other news feeds.

This guy was targeted by either his government or another agency. They probably contracted this Israeli firm to create this exploit and tried to execute it on him. The target is a well known human rights activist in the UAE where human rights are non existent for many.

The ironic part is that the private equity firm that has a major interest in the Israeli company, NSO, is located just down the road from Apple in Cupertino.


If he was using a BlackBerry, NSO would have just created a hack for BlackBerry.

Posted via CB10

You can't even root a BlackBerry with physical access, and these hackers rooted the iPhone remotely using four year old zero days.

So yeah, I don't agree with you.

Posted via CB10

[LazyEvul]

Yes that is a good piece of work, and I am familiar with it. Work like that does form a important piece of the security picture. But this is an analysis of the protocol as designed, it does not address the quality of the implementation of the protocol by the various vendors who are now using it. After all this thread is discussing coding quality and flaws, not protocol design. I never claimed that the paper I linked was a complete solution, I hope you don't believe that even if we had this level of quality analysis for every protocol and product the problem os smartphone vulnerabilities would be gone. Nor did I suggest that just counting CVEs was a good metric, but an analysis of CVE numbers using a scoring method can be very instructive. For example what do you conclude from a 10+ year old library that has a handful of important vulnerabilities listed month after month? With a numerical data analysis model you can monitor many more products than you can by reading qualitative analysis even if such analysis is available for all products of interest. But if you believe numerical analysis tells you nothing, who am I to disagree.

LeapSTR100-2/10.3.2.2876

I don't think we're on the same page, seeing as my original point was precisely that merely counting CVEs, or as I put it, the "number of publicly known vulnerabilities," was a terrible metric. I acknowledge that CVSS scores have some value, but it's inevitably going to be imperfect for a whole host of reasons (vendors have been known to deviate from the standards, for instance), so we need to be cautious not to lean too much on it. Nor am I insinuating that numerical analysis is completely useless. What I am saying is that merely counting CVEs is a useless metric (one which I've seen used around these forums far too often), and security work, in my experience, hinges on qualitative analysis much more often.

[Richard Buckley]

I don't think we're on the same page, seeing as my original point was precisely that merely counting CVEs, or as I put it, the "number of publicly known vulnerabilities," was a terrible metric. I acknowledge that CVSS scores have some value, but it's inevitably going to be imperfect for a whole host of reasons (vendors have been known to deviate from the standards, for instance), so we need to be cautious not to lean too much on it. Nor am I insinuating that numerical analysis is completely useless. What I am saying is that merely counting CVEs is a useless metric (one which I've seen used around these forums far too often), and security work, in my experience, hinges on qualitative analysis much more often.

Counting occurrences is the most basic numerical analysis. It is not perfect, but it is the basis of a great deal of good that has come out of many scientific disciplines. An entire branch of mathematics called statistics has grown up to tell us if what we are counting, and the way we are counting them are meaningful. In many cases it will tell you where you need to put the effort of qualitative analysis.

A simple case of counting applied to security is failed login attempts. A small number is probably user error, a large number in a short period is a malicious act and counter measures are needed. If you take my CVE example from my last post, a single body of code has been the subject of a handful of important vulnerabilities each month for a significant period. This is a clear indication of the need for qualitative analysis of the whole body of code. And that is happening piece meal since researchers are finding more vulnerabilities each month. But as we know not all those researchers are disclosing what they find. Some of them are selling them to people who make exploits. So by simply counting CVEs we can be reasonably sure that this body of code could be the attack surface being exploited now. To me, and maybe to others who read this site that is valuable information. But you say it means nothing. That's fine, I haven't been writing to convince you for several posts, I've been writing to give the other readers an alternative to consider.

LeapSTR100-2/10.3.2.2876

[gariac]

While fixing a vulnerability, any decent organization will review relevant code for further bugs. This prevents multiple CVEs for basically the same problem.

Take the classic Apple goto fail fubar. I, being a novice coder, always use the curly brackets. The wizard at Apple though they knew when the curly bracket wasn't required. My point here is any competent organization would review all that code that clown wrote and look for similar bugs.

Posted via CB10

[melander]

You can't even root a BlackBerry with physical access, and these hackers rooted the iPhone remotely using four year old zero days.

So yeah, I don't agree with you.

Posted via CB10

For the record, the vulnerability requires a user to open a link to install a Trojan. It's bad, but not like they get a targets ip address and are able to exploit a remote hole.

[gariac]

For the record, the vulnerability requires a user to open a link to install a Trojan. It's bad, but not like they get a targets ip address and are able to exploit a remote hole.

Yes, they spearphished the target. However the target wasn't some fool that clicks on everything. He brought it to the attention of researchers. This was not a drive-by.

http://mobile.nytimes.com/2016/09/03...?_r=0&referer=

The same group claims they have hacks for BlackBerry, but unknown which OS and under what circumstances.

Posted via CB10

[Vistaus]

For the record, the vulnerability requires a user to open a link to install a Trojan. It's bad, but not like they get a targets ip address and are able to exploit a remote hole.

But still, were this to happen on BlackBerry, it wouldn't work because there's no way to give said Trojan root access.

Posted via CB10 using my amazing  Passport (OG Red) <3

[rthonpm]

Let's all take a step back from the hyperbole and entrenched positions and look at the larger picutre:

No software is ever 100 per cent secure: it's created by people and all of the potential variables can never be accounted for.

In the NSO Group, we essentially have a criminal organisation researching flaws and vulnerabilities in multiple operating systems and building exploit kits to leverage them, which they then make available for sale. What makes them any different than any other malware provider in the world? With the type of funding their exploits fetch, there's not much chance for legitimate researchers to keep up since they're dealing with a much smaller funding source.

The chances that a well funded organisation can find flaws is very high since they have the resources to do as much digging as possible. The risk for the average person is if these same exploits were to be discovered by an individual or organisation that doesn't seek to target individuals, but packages a mass exploit for all users of a platform.

Posted via CB10

[Richard Buckley]

Let's all take a step back from the hyperbole and entrenched positions and look at the larger picutre:

No software is ever 100 per cent secure: it's created by people and all of the potential variables can never be accounted for.

In the NSO Group, we essentially have a criminal organisation researching flaws and vulnerabilities in multiple operating systems and building exploit kits to leverage them, which they then make available for sale. What makes them any different than any other malware provider in the world? With the type of funding their exploits fetch, there's not much chance for legitimate researchers to keep up since they're dealing with a much smaller funding source.

The chances that a well funded organisation can find flaws is very high since they have the resources to do as much digging as possible. The risk for the average person is if these same exploits were to be discovered by an individual or organisation that doesn't seek to target individuals, but packages a mass exploit for all users of a platform.

Posted via CB10

So the developers at Apple (in this specific instance), Google, Microsoft, BlackBerry et al are going to make mistakes, it is only human nature and their corporations don't have the funding to find those mistakes even though they have access to documented source code even when it isn't open source. Maybe BlackBerry and smaller companies don't have the funding that the NSO Group has, but the rest do if they wanted to spend it on improving their code. NSO has been offered for sale at $1 billion (Bloomberg), Apple alone is worth almost 600 times that amount, Google almost 800 times. No, I can't accept lack of money as the reason there are bugs, though it is definitely a reason more of them are probably found by black hats.

LeapSTR100-2/10.3.2.2876

[CharlieV]

Can't delete my post. How embarrassing.

[rthonpm]

No, I can't accept lack of money as the reason there are bugs, though it is definitely a reason more of them are probably found by black hats.

LeapSTR100-2/10.3.2.2876

You misinterpreted my statement. The lack of money comment was in regards to third party security researchers. Corporate programmers often seem to have an attitude of 'the code works so why mess with it', especially when dealing with the conflicting tasks of meeting production deadlines and vetting code for all possible breaking points.

Look at the number of long standing vulnerabilities found in everything from Microsoft's NT kernel to open source projects like OpenSSL. Neither Microsoft nor the development team for OpenSSL found the issues that outside researchers did even with their daily involvement in the source code. These types of issues aren't just one exploit, but a series of smaller ones built into a sequence that allows for a much larger one. Building those takes time, money, and sometimes tools not available when the original code was written. Apple may have vetter the code against tools available at the time, or against vulnerabilities known to exist in protocols or applications supported by the code, but add in another variable that they don't know about and it just proves the cat and mouse game that security is.

Independent researchers offer a chance to look at code without the preconceptions of its authors, but to do any kind of work they need funding, which means that a chunk of this kind of research will have the opportunity to be done by an NSO Group, or someone else that can spend the time and money that it takes to break any system.


Posted via CB10

[Richard Buckley]

You misinterpreted my statement. The lack of money comment was in regards to third party security researchers. Corporate programmers often seem to have an attitude of 'the code works so why mess with it', especially when dealing with the conflicting tasks of meeting production deadlines and vetting code for all possible breaking points.

Look at the number of long standing vulnerabilities found in everything from Microsoft's NT kernel to open source projects like OpenSSL. Neither Microsoft nor the development team for OpenSSL found the issues that outside researchers did even with their daily involvement in the source code. These types of issues aren't just one exploit, but a series of smaller ones built into a sequence that allows for a much larger one. Building those takes time, money, and sometimes tools not available when the original code was written. Apple may have vetter the code against tools available at the time, or against vulnerabilities known to exist in protocols or applications supported by the code, but add in another variable that they don't know about and it just proves the cat and mouse game that security is.

Independent researchers offer a chance to look at code without the preconceptions of its authors, but to do any kind of work they need funding, which means that a chunk of this kind of research will have the opportunity to be done by an NSO Group, or someone else that can spend the time and money that it takes to break any system.


Posted via CB10

Corporate programmers are no different than independent researchers. They want to do good work, generally know when enough attention is being paid to qualify and when not. But just like everyone else in the workplace they have bills to pay and families to feed. They do that by following the direction of their bosses. If Apple, Google and Microsoft wanted to ship better code they just have to make that a priority for their work force. But there is no competitive advantage in shipping better code because everyone has bought into the myth that it is hard, there are few good metrics ti judge code and the black hats are better funded anyway. And when companies do ship better code people just say that the code doesn't have vulnerabilities because nobody is interested in looking at it.

Maybe if everyone stopped listening to the echo chamber that claims we can't do any better than we are, and starts to look for way we can do better without preconceptions things will actually improve. But I'm confident that this won't happen, and people who know things could be different will end up working for commercial hacking groups which is where the next growth spurt will come from as the mobile device market matures and becomes a commodity market.

At least it will be fun to watch.

Edit:

If you remember the "Goto Fail" bug here is a good article that demonstrates a number of very simple techiniques that every coding shop should use to make very simple bugs, that may have significant concequences, very easy to find in code review.

LeapSTR100-2/10.3.2.2876