09-05-16 04:43 PM
100 1234
tools
  1. LazyEvul's Avatar
    For example even a cursory glance at the nuclear power plant article is enough to realise that the maleware was to ancillary Windows machines. Not a good thing to have happen but Windows is a example of software not written to be bug free.
    I'm well aware of what happened in that instance. I think I haven't articulated my point very well though. What I'm trying to say is that nobody was relying on the software to save them - they air gapped critical systems.

    The FAA is correct that having all four generators turn off at the same time is not a good thing to have happen. On the other hand leaving the control systems running for 248 days may not be a good thing either. To determine if this is a bug or an incorrect design decision one would have to look at the documentation for the system. Unfortunately to the press any time software is involved in what turns out to be the wrong thing to to do it must be a bug. However if the design called for the software to do that then it is not a software bug in the classic sense, but a system design flaw.
    The description in both the FAA directive and Boeing's Multi Operator Message suggests it's a bug, with a software counter overflowing after 248 days. It's possible whoever wrote it assumed that this would be enough, but it doesn't appear to have been a deliberate design decision on Boeing's part.

    And in any case, once again, Boeing did not rely on the integrity of their code. The pilot and co-pilot could restart the generators from the cockpit in the event that this issue occurred.

    Along these same lines the infamous kill the jeep on the highway is an example of mixing high reliability code with low, just like your nuclear reactor example. The jeep wasn't killed by hacking into the engine control software. It was killed by hacking into a poorly written layer product that had access to the command and control channels so the hackers were able to send instructions to the vehicle control systems. This is just evidence that if you build a secure, bug free system, but five control ti software not written to the same standards the security of the whole system is compromised.
    But that's my point - they made the mistake of trusting the infotainment software. You don't trust the software in security, because the software has bugs. Maybe the engine control software doesn't (though I doubt it), but you don't want to try your luck - you want to keep that software separated from the outside world.

    Just because you find examples of software that has flaws doesn't mean that all software must have flaws any more than finding a bridge that was badly designed means that all bridges must have design flaws.
    Sure, but the point is that a good design does not grant full trust to the code. In the cases I brought up, that can be done through physical overrides or air gaps.

    I'm sure (or at least I'd hope) a similar mindset is taken in the design of bridges and other structures - you build beyond the specifications you think you'll need, to account for potential errors, inconsistencies in construction materials, or other unforeseen circumstances.

    I've been working in high reliability software development for 30 years and my team has systems that have been running in high threat environments for decades without the need for patching due to bugs.
    Does that mean there are no bugs though, or does that mean no bugs have been found? You could conceivably run a piece of software with critical vulnerabilities in it and get away with it, provided that it has no connection to the outside world - because no one can even try to exploit it.

    That's the point I'm trying to make. No good security model exists on the assumption of bug-free code. Even if you have a high amount of confidence in the code, a good security model assumes that the adversary is smarter than you - especially when dealing with mission-critical systems.

    In smartphones, however, this is a challenging task. Not only is the software made up of millions of lines of code, you can't really build physical protection into it - a smartphone's basic functionality requires multiple connections to the outside world. So the best you can do is build software mitigations, like ASLR or sandboxing, to make exploitation difficult and expensive.

    Even if we assume some software can be bug-free (and I've not met a single security expert who would agree with that assertion once you get past a few thousand lines of code), when you're dealing with millions of lines of constantly evolving code, the kind of scrutiny that would be required to achieve that is completely unfeasible.
    JeepBB likes this.
    08-28-16 01:17 PM
  2. kvndoom's Avatar
    Price is not a factor at all. If it was, then Windows Phone would have way more marketshare by now with Microsoft's 49 phones (not to mention the familiarity given its desktop marketshare). But it hasn't, which proves that price isn't the only factor in play.

    Btw, more and more government officials and celebrities are walking around with iPhones now so there's a big catch if said hackers succeed.

    Posted via CB10 using my amazing BlackBerry Passport (OG Red)
    First point... windows phone was too little too late just like BlackBerry.

    Second point, I totally agree. The celebrities and politicians create incentive.

    Blackberry Poptart SE - Cricket Wireless
    08-28-16 03:21 PM
  3. Invictus0's Avatar
    First point... windows phone was too little too late just like BlackBerry.
    Windows Phone was first released in 2010 and it showed quite a bit of promise until recently. The issue is largely with Microsoft, they've gone back to the drawing board too many times with the platform.
    08-28-16 04:04 PM
  4. Akure4Life's Avatar
    The full article is hidden behind a paywall, and the headline is typical alarmist clickbait. I'm guessing the whole story boils down to not very much at all, and not even particularly specific to iOS.
    "Cyberthieves have a new way to hack into consumer bank accounts: mobile phones.

    Malicious software programs with names like Acecard and GM Bot are gaining popularity around the world as criminals look for new and lucrative ways to attack the financial-services industry. Cyberthieves are using such so-called malware to steal banking credentials from unsuspecting consumers when they log on to their bank accounts via their mobile phones, according to law-enforcement officials and cybersecurity specialists.

    It is difficult to quantify how much money has been stolen as a result of the mobile-phone malware, mostly because the thieves can access an account through any normal channel after they steal credentials through a phone. Still, the prevalence of the malware is significant enough that it has caught the attention of the Federal Bureau of Investigation and U.S. banking regulators.

    ADVERTISEMENT

    The FBI is seeing new types of malware specifically aimed at banking applications for the purpose of stealing account credentials, says Richard Jacobs, an assistant special agent in charge who handles cybercrimes. He has been warning the financial-services industry about the trend, which is typically aimed at large banks.

    Attacks have occurred on the two most common mobile operating systems Apple Inc. s iOS and Alphabet Inc. s Android. Phones typically come with built-in security protections, but the devices can still be vulnerable. On Thursday, Apple urged some iPhone users to update their software due to a security flaw that could allow a hacker to remotely take control of the operating system.

    The Federal Financial Institutions Examination Council, which brings together five banking regulatory bodies, in April updated its guidance for banks to include potential threats facing mobile financial services, including mobile-phone malware."

    Posted Via CB10 from Z30 OS 10.3.2.2836 
    08-28-16 04:38 PM
  5. bobshine's Avatar
    Listing of vulnerabilities:
    Apple 924
    Apple Iphone Os : CVE security vulnerabilities, versions and detailed reports

    Android 514
    Google Android : CVE security vulnerabilities, versions and detailed reports

    BlackBerry 21
    https://www.cvedetails.com/vendor/8356/Blackberry.html

    If you are foolish enough to believe that vulnerabilities don't matter to security overall...
    I agree that you're pretty much only as safe as what you do with your own device (for the most part), but I'm not going to start out with the Swiss cheese of security and vulnerabilities that is Apple. They are the worst by a long shot.
    But... it's your life, so whatever helps you sleep at night.
    This doesn't mean anything. Discovered vulnerability means nothing regarding the safety of an OS.

    For example, the OS on my DVD player that I bought 20 years ago has 0 discovered vulnerability this year... So I guess it means that it's the SAFEST OS out there???
    LazyEvul and Elephant_Canyon like this.
    08-28-16 06:00 PM
  6. kvndoom's Avatar
    Windows Phone was first released in 2010 and it showed quite a bit of promise until recently. The issue is largely with Microsoft, they've gone back to the drawing board too many times with the platform.
    That was still too late. Ballmer not taking the iphone seriously when it was announced cost MS probably tens of billions of dollars. They had a 3 year lead on Blackberry and in the end didn't fare much better.
    08-28-16 09:05 PM
  7. kvndoom's Avatar
    This doesn't mean anything. Discovered vulnerability means nothing regarding the safety of an OS.

    For example, the OS on my DVD player that I bought 20 years ago has 0 discovered vulnerability this year... So I guess it means that it's the SAFEST OS out there???
    If it's not connected to the internet, it probably is!
    08-28-16 09:06 PM
  8. Jerry A's Avatar
    There are many programming disciplines which require error free code. Each vulnerability usually starts with a crash. So, think about complex software systems that you don't want to crash, airplane flight management system, nuclear power stations, rocket control software, car breaking or steering control systems. Do you want to be flying on an airline which has software with as many bugs as smartphones? Vulnerability free software can be written, but not if you want changes every few months because you are getting bored with the current UI.

    LeapSTR100-2/10.3.2.2876
    You'd think.

    And yet, errors happen. Look at the spate of recent airline computer systems,

    Look at the security bulletins and warnings for industrial systems.

    Read up on the fear of critical infrastructure being hacked by foreign powers. Or hey, look at critical infrastructure that has already been hacked (Stuxnet).

    Cars have been shown to be remotely hackable with steering and braking compromised.

    Or just look at all the Y2K remediations that took place.

    There is no such thing as error free, super secure code. Attack vectors change. New exploits are found every day. The tools improve everyday (super secure cyphers of yesteryear can now be cracked with today's desktops).

    Believing anything else, especially for the sake of promoting one platform over another is security irresponsibility.
    08-28-16 09:11 PM
  9. anon(9721108)'s Avatar
    I think mine will be even safer then
    08-28-16 09:54 PM
  10. Richard Buckley's Avatar
    I'm well aware of what happened in that instance. I think I haven't articulated my point very well though. What I'm trying to say is that nobody was relying on the software to save them - they air gapped critical systems.



    The description in both the FAA directive and Boeing's Multi Operator Message suggests it's a bug, with a software counter overflowing after 248 days. It's possible whoever wrote it assumed that this would be enough, but it doesn't appear to have been a deliberate design decision on Boeing's part.

    And in any case, once again, Boeing did not rely on the integrity of their code. The pilot and co-pilot could restart the generators from the cockpit in the event that this issue occurred.



    But that's my point - they made the mistake of trusting the infotainment software. You don't trust the software in security, because the software has bugs. Maybe the engine control software doesn't (though I doubt it), but you don't want to try your luck - you want to keep that software separated from the outside world.



    Sure, but the point is that a good design does not grant full trust to the code. In the cases I brought up, that can be done through physical overrides or air gaps.

    I'm sure (or at least I'd hope) a similar mindset is taken in the design of bridges and other structures - you build beyond the specifications you think you'll need, to account for potential errors, inconsistencies in construction materials, or other unforeseen circumstances.



    Does that mean there are no bugs though, or does that mean no bugs have been found? You could conceivably run a piece of software with critical vulnerabilities in it and get away with it, provided that it has no connection to the outside world - because no one can even try to exploit it.

    That's the point I'm trying to make. No good security model exists on the assumption of bug-free code. Even if you have a high amount of confidence in the code, a good security model assumes that the adversary is smarter than you - especially when dealing with mission-critical systems.

    In smartphones, however, this is a challenging task. Not only is the software made up of millions of lines of code, you can't really build physical protection into it - a smartphone's basic functionality requires multiple connections to the outside world. So the best you can do is build software mitigations, like ASLR or sandboxing, to make exploitation difficult and expensive.

    Even if we assume some software can be bug-free (and I've not met a single security expert who would agree with that assertion once you get past a few thousand lines of code), when you're dealing with millions of lines of constantly evolving code, the kind of scrutiny that would be required to achieve that is completely unfeasible.
    Your entire viewpoint is based on the assumption that writing error free code is impossible. But there is a whole class of software development that has been created to do exactly this. It requires things like mathematical proofs that the software performs according to specifications. When you have such proofs you know that the code is error free. There are other methods.

    Yes, some of the first decisions you make, if the specifications include securing a car, plane or nuclear power plant from unauthorised control is that you don't give control over critical system to untrusted systems. But if the specifications don't include securing the system then providing such access is not really a bug. You might argue that programmers shouldn't write code they know is going to result in problems, but programmers get paid to do what they are told, just like everyone else. Chrysler never claimed that they directed their programmers to write code any other way except to fix the problem when it was revealed.

    But you can't use a few examples of people failing to do something as proof that no one can do that thing. If that was the case we wouldn't have to pay taxes since some people don't so obviously no one can. There are many cases of error free code, and many methods of producing it. It requires the knowledge of the right techniques, but it can be done. It is also not an all or nothing proposition. There are techniques that produce very reliable code without going as far as mathematical proofs. Those techniques are appropriate to something like a smart phone OS.

    Yes, I've seen the AD. And I agree that a counter overflow might sound like a bug. But if you want to write error free code you have to learn not to make assumptions or jump to conclusions. For this to be considered a bug the design specifications would have to state that the generator controller does something other than go into fail safe mode when the counter overflows; or that the counter should not overflow for any possible power on time. If there was a design decision taken that the generator controller should go to fail safe mode on a timer overflow, the software is performing as specified. It still needs to be fixed but the problem is in the overall design process. Clearly someone dropped the ball somewhere, but it is also a fact that Boeing discovered this problem in their lab over a year ago which indicates that they have a system in place to QC their design and implementation. So they will find out what went wrong and fix it.



    LeapSTR100-2/10.3.2.2876
    Vistaus likes this.
    08-28-16 10:34 PM
  11. canuckvoip's Avatar
    This doesn't mean anything. Discovered vulnerability means nothing regarding the safety of an OS.
    Are you kidding me? Seriously?
    If you are measuring your device security based on a DVD player then I don't know what to tell you at all.
    Your DVD player doesn't hold all your contacts, passwords, banking apps, personal photos, family information, sensitive documents, work information, and so much more.
    And you are actually insinuating that using a device that is demonstrably shown to be less secure and more vulnerable is OK?
    You are an Apple apologist extraordinaire! Bwahahahaha!!!!
    08-29-16 02:17 AM
  12. anon(9742832)'s Avatar
    Are you kidding me? Seriously?
    If you are measuring your device security based on a DVD player then I don't know what to tell you at all.
    Your DVD player doesn't hold all your contacts, passwords, banking apps, personal photos, family information, sensitive documents, work information, and so much more.
    And you are actually insinuating that using a device that is demonstrably shown to be less secure and more vulnerable is OK?
    You are an Apple apologist extraordinaire! Bwahahahaha!!!!

    First off lets be real about this, this was not a security breach the public needs to worry about. Unless you really think some government wants to spend a million bucks to look at your phone......NOT. Apple should get an "attaboy", with the quick response to a government directed single phone direct to the user attack.
    08-30-16 12:50 PM
  13. canuckvoip's Avatar
    First off lets be real about this, this was not a security breach the public needs to worry about. Unless you really think some government wants to spend a million bucks to look at your phone......NOT. Apple should get an "attaboy", with the quick response to a government directed single phone direct to the user attack.
    The gaping hole has been there for years. There are complicated softwares created specifically to use the vulneability.
    Do you realy think Apple didn't know about it?
    Apple gets an attaboy?
    Lol!
    08-30-16 02:52 PM
  14. anon(9721108)'s Avatar
    The hacker's encryption was supposedly so good, no one could see it, or notice it. I read it has been around since ios8, and they would steal company's data and then hold it for ransom.

    I heard a story that they held all the Canadian Health Care system patient's data for ransom, and the ransom had to be paid because the government needed our info back! But I have not verified that report yet.

    Sent from my BlackBerry 9900 using Tapatalk
    08-30-16 02:59 PM
  15. anon(9742832)'s Avatar
    The gaping hole has been there for years. There are complicated softwares created specifically to use the vulneability.
    Do you realy think Apple didn't know about it?
    Apple gets an attaboy?
    Lol!
    Yes Im ure Apple said.....lets leave this hole so latter on we can look like fools................sounds like a marketing plan to me......LOL
    LazyEvul and JeepBB like this.
    08-30-16 03:18 PM
  16. mrlahjr's Avatar
    The way to fix all this is to hide behind a really good vpn.

    Anyone know if there's a Tor browser for BlackBerry?


    TMO  PP SE,SQW100-4/10.3.2.2876
    08-30-16 03:32 PM
  17. Vistaus's Avatar
    Yes Im ure Apple said.....lets leave this hole so latter on we can look like fools................sounds like a marketing plan to me......LOL
    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
    08-30-16 04:35 PM
  18. bobshine's Avatar
    Are you kidding me? Seriously?
    If you are measuring your device security based on a DVD player then I don't know what to tell you at all.
    Your DVD player doesn't hold all your contacts, passwords, banking apps, personal photos, family information, sensitive documents, work information, and so much more.
    And you are actually insinuating that using a device that is demonstrably shown to be less secure and more vulnerable is OK?
    You are an Apple apologist extraordinaire! Bwahahahaha!!!!
    Wow... you take things really too literally! Everyone seems to understand my point except you! And BTW, DVD players today do hold contacts, pictures, Facebook accesses...
    08-30-16 05:21 PM
  19. LazyEvul's Avatar
    Your entire viewpoint is based on the assumption that writing error free code is impossible. But there is a whole class of software development that has been created to do exactly this. It requires things like mathematical proofs that the software performs according to specifications. When you have such proofs you know that the code is error free. There are other methods.
    I think I'm pushing the boundaries of what I'm qualified to speak to at this point - I'm relatively new to programming and the security world - so I think it's best that I assume I've been proven wrong on this one, unless I learn otherwise at some point. This just isn't a viewpoint I've heard before, but I usually dabble in consumer applications, which are quite different to mission-critical ones.

    If it was there in at least iOS 8, they should've fixed it back then, easy as pie.
    This isn't how any of this works.
    08-30-16 05:59 PM
  20. Richard Buckley's Avatar
    I think I'm pushing the boundaries of what I'm qualified to speak to at this point - I'm relatively new to programming and the security world - so I think it's best that I assume I've been proven wrong on this one, unless I learn otherwise at some point. This just isn't a viewpoint I've heard before, but I usually dabble in consumer applications, which are quite different to mission-critical ones.



    This isn't how any of this works.
    The problem with that is simple user convenience programmes can end up being the attack surface that allows penetration of mission critical systems. Like the Jeep. There is more to being a programmer than learning a few programming languages.

    LeapSTR100-2/10.3.2.2876
    Vistaus likes this.
    08-30-16 09:10 PM
  21. melander's Avatar
    In the hacked docs of the hackingteam you can read internal communication quoted

    "that only the smart ppl are useing a BlackBerry and that they should have a exploit for it"


    Hahhaha that part is very good pr stuff for BlackBerry.

    Posted via CB10
    Would that be bb10 or bbos? They are both very different. And we know that bb10 never became a fraction of bbos deployments.
    08-30-16 09:38 PM
  22. canuckvoip's Avatar
    Wow... you take things really too literally! Everyone seems to understand my point except you! And BTW, DVD players today do hold contacts, pictures, Facebook accesses...
    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.
    08-30-16 11:40 PM
  23. Elephant_Canyon's Avatar
    I do not understand.
    Seems like there is a huge volume of information about this topic that you don't understand.
    08-31-16 07:18 AM
  24. canuckvoip's Avatar
    OK, well have it your way. Lol!
    08-31-16 11:41 AM
  25. johnny_bravo72's Avatar
    OK, well have it your way. Lol!
    Burger King has spoken.

    *A3-A20
    08-31-16 12:29 PM
100 1234

Similar Threads

  1. iMessage for Android on BB10?
    By The_Passporter in forum BlackBerry 10 OS
    Replies: 15
    Last Post: 08-25-16, 08:52 PM
  2. Transferring MMS from BB10 to Android
    By Lapwolf in forum Android Apps
    Replies: 1
    Last Post: 08-25-16, 01:01 PM
  3. BB10 google account errror : cannot communicate with google servers
    By CrackBerry Question in forum Ask a Question
    Replies: 4
    Last Post: 08-25-16, 09:44 AM
  4. Clean Install BB10
    By CrackBerry Question in forum Ask a Question
    Replies: 2
    Last Post: 08-23-16, 01:16 PM
  5. BES 10.2 and iOS 10
    By dpeters11 in forum BES 10
    Replies: 0
    Last Post: 08-23-16, 10:10 AM
LINK TO POST COPIED TO CLIPBOARD