- 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.
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...08-31-16 05:32 PMLike 0 -
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.08-31-16 06:01 PMLike 0 - 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.
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.287608-31-16 08:42 PMLike 0 - 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
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.Last edited by LazyEvul; 09-01-16 at 12:17 AM.
08-31-16 11:44 PMLike 3 - 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...
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)Jerry A likes this.08-31-16 11:51 PMLike 1 - 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.
Ride or die: PRIVelege-acy09-01-16 12:13 AMLike 0 - 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.
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.287609-01-16 04:45 AMLike 0 - 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.
Blackberry Poptart SE - Cricket Wireless09-01-16 05:21 AMLike 0 - 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)
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.09-01-16 09:35 AMLike 3 - 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.
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.Last edited by LazyEvul; 09-01-16 at 12:07 PM.
Elephant_Canyon likes this.09-01-16 11:57 AMLike 1 - 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.
LeapSTR100-2/10.3.2.287609-01-16 04:43 PMLike 0 - Yea that's news..............a defect manifests its self years latter.................................Im sure that never has happened before............LOL09-01-16 06:25 PMLike 0
- 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
So yeah, I don't agree with you.
Posted via CB10Vistaus likes this.09-01-16 09:19 PMLike 1 - 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.287609-01-16 10:31 PMLike 0 - 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.
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.2876Superdupont 2_0 and Vistaus like this.09-02-16 04:44 AMLike 2 - 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 CB1009-02-16 09:06 PMLike 0 - 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.09-03-16 05:43 PMLike 0
-
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 CB1009-03-16 06:02 PMLike 0 -
Posted via CB10 using my amazing Passport (OG Red) <309-03-16 11:58 PMLike 0 - 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 CB1009-04-16 11:43 AMLike 0 - 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
LeapSTR100-2/10.3.2.287609-04-16 04:11 PMLike 0 -
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 CB1009-05-16 04:23 PMLike 0 - 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
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.2876Last edited by Richard Buckley; 09-05-16 at 04:58 PM.
09-05-16 04:43 PMLike 0
- Forum
- BlackBerry 10 Phones & OS
- BlackBerry 10 OS
This proves bb10 vs ios security
Similar Threads
-
iMessage for Android on BB10?
By The_Passporter in forum BlackBerry 10 OSReplies: 15Last Post: 08-25-16, 08:52 PM -
Transferring MMS from BB10 to Android
By Lapwolf in forum Android AppsReplies: 1Last Post: 08-25-16, 01:01 PM -
BB10 google account errror : cannot communicate with google servers
By CrackBerry Question in forum Ask a QuestionReplies: 4Last Post: 08-25-16, 09:44 AM -
Clean Install BB10
By CrackBerry Question in forum Ask a QuestionReplies: 2Last Post: 08-23-16, 01:16 PM -
BES 10.2 and iOS 10
By dpeters11 in forum BlackBerry Secure UEM & Productivity SuitesReplies: 0Last Post: 08-23-16, 10:10 AM
LINK TO POST COPIED TO CLIPBOARD