iOS 14.8, iPadOS 14.8 tighten security, close off 'Blastdoor' attacks

AppleInsiderAppleInsider
Posted:
in iOS edited September 2021
Apple's update to iOS 14.8 and iPadOS 14.8 introduce fixes to two vulnerabilities, including one that enabled attacks that worked around Apple's Blastdoor protective system.




Monday's release of iOS 14.8 and iPadOS 14.8 to the public was unexpected and lacked any betas ahead of being issued. Apple described the patches as providing "important security updates and is recommended for all users."

Shortly after the release, Apple published the security content changes included in iOS 14.8 and iPadOS 14.8. The two fixes related to the CoreGraphics and WebKit sections of both operating systems.

Both updates state the impact of the vulnerabilities was that the processing of a "maliciously crafted" PDF file or web content "may lead to arbitrary code execution." Apple "is aware of a report that this issue may have been actively exploited."

The CoreGraphics patch is listed as issue CVE-2021-30860, reported by The Citizen Lab, while "an anonymous researcher" reported CVE-2021-30858, affecting WebKit.

The updates fix issues that allowed an attacker to bypass Apple's BlastDoor security sandbox, a system used to stop malicious code execution in Messages.

Following initial reporting on the Pegasus hacking tool in July, a second report by Citizen Lab in August revealed the vulnerability in iMessage, which allowed Pegasus to be installed on a target iPhone. The hack and the use of Pegasus is believed to have been performed on devices owned by journalists and human rights activists.

Update: After the iOS 14.8 update went live, Citizen Lab published a report about a zero-click exploit leveraging the CVE-2021-30860 vulnerability. According to Citizen Lab, the exploit appears to have been developed by NSO Group and was discovered when it actively targeted the smartphone of at least one Saudi activist. The exploit, which targeted Apple's image rendering library, was used to distribute the Pegasus spyware on affected devices.

Read on AppleInsider

Comments

  • Reply 1 of 15
    elijahgelijahg Posts: 2,759member
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    dope_ahmine
  • Reply 2 of 15
    blastdoorblastdoor Posts: 3,281member
    Nobody gets by Blastdoor! 
  • Reply 3 of 15
    lkrupplkrupp Posts: 10,557member
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Nothing burger from the peanut gallery. You can’t spell and apparently can’t turn on a spell checker but you claim to be some software coding expert? 
  • Reply 4 of 15
    JFC_PAJFC_PA Posts: 932member
    Fast and easy update. Thanks. 

    Though I’m unlikely to be a state agency target. 
    edited September 2021 watto_cobra
  • Reply 5 of 15
    dope_ahminedope_ahmine Posts: 253member
    lkrupp said:
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Nothing burger from the peanut gallery. You can’t spell and apparently can’t turn on a spell checker but you claim to be some software coding expert? 
    Actually, developers often switch off all text fiddling features.
    minicoffeeelijahgbuttesilver
  • Reply 6 of 15
    MorkMork Posts: 22member
    Here,

    Cyber arms dealer exploits new iPhone software vulnerability, affecting most versions, say researchers
    https://reut.rs/3tDEWTj


    watto_cobra
  • Reply 7 of 15
    fastasleepfastasleep Posts: 6,417member
    elijahg said:
    lkrupp said:
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Nothing burger from the peanut gallery. You can’t spell and apparently can’t turn on a spell checker but you claim to be some software coding expert? 
    Considering your usual ignorance, I am not at all surprised that you're unaware that different dialects of English exist. Almost every time you post you reinforce the fact that you are AI's resident dunce.
    The funny thing is, in non-American English "practise" is a verb and "practice" is a noun, so your use of "shoddy code practises" is incorrect given 'practises' is a noun in that context. Not that lkrupp knows this, but still.
    skippingrockelijahgexceptionhandlerappleinsideruserwatto_cobra
  • Reply 8 of 15
    elijahgelijahg Posts: 2,759member
    fastasleep said:
    elijahg said:
    lkrupp said:
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Nothing burger from the peanut gallery. You can’t spell and apparently can’t turn on a spell checker but you claim to be some software coding expert? 
    Considering your usual ignorance, I am not at all surprised that you're unaware that different dialects of English exist. Almost every time you post you reinforce the fact that you are AI's resident dunce.
    The funny thing is, in non-American English "practise" is a verb and "practice" is a noun, so your use of "shoddy code practises" is incorrect given 'practises' is a noun in that context. Not that lkrupp knows this, but still.
    Interesting, that I didn't know. Thanks!
    skippingrock
  • Reply 9 of 15
    sevenfeetsevenfeet Posts: 465member
    Strange....I have an old iPhone 6s I use for testing and it still says 14.7 is the version for it.  Everything else is updating.
    watto_cobra
  • Reply 10 of 15
    skippingrockskippingrock Posts: 187member
    sevenfeet said:
    Strange....I have an old iPhone 6s I use for testing and it still says 14.7 is the version for it.  Everything else is updating.
    My iPhone 8 was stuck on iOS 14.7 for a long while even though iOS 14.7.1 was out. I had to connect my iPhone to my computer to update it to iOS 14.7.1. Try waiting to see if it still hasn’t propagated to the server near you. If it’s still not there tomorrow then try connecting it to your computer to see if you can force the update to iOS 14.8. 
    watto_cobra
  • Reply 11 of 15
    exceptionhandlerexceptionhandler Posts: 369member
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Having been apart of many dev teams, no amount of due diligence and policy can catch everything, no matter how good you are.  Fact is, dev teams are made up of people, and each person can make mistakes.  That’s why we have checks and balances like code reviews, unit tests, QA, and the like.  No system is perfect, human or digital (which is built by humans).  Always expecting perfection is only setting yourself up to be disappointed.

    Apple researched it and found a fix to a problem that does not appear to be easily found and issued the fix.  What more could you ask for?

    http://www.stilldrinking.org/programming-sucks
    linkmanwatto_cobra
  • Reply 12 of 15
    elijahgelijahg Posts: 2,759member
    exceptionhandler said:
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Having been apart of many dev teams, no amount of due diligence and policy can catch everything, no matter how good you are.  Fact is, dev teams are made up of people, and each person can make mistakes.  That’s why we have checks and balances like code reviews, unit tests, QA, and the like.  No system is perfect, human or digital (which is built by humans).  Always expecting perfection is only setting yourself up to be disappointed.

    Apple researched it and found a fix to a problem that does not appear to be easily found and issued the fix.  What more could you ask for?

    http://www.stilldrinking.org/programming-sucks
    Of course not, but this isn't the first nor the second time this has happened to iMessage. Having a hole in iMessage and then a second hole in the sandbox that's supposed to stop holes in iMessage from becoming a problem isn't good. Means their unit tests aren't thorough enough and the sandbox isn't doing enough bounds checking.
  • Reply 13 of 15
    exceptionhandlerexceptionhandler Posts: 369member
    elijahg said:
    exceptionhandler said:
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Having been apart of many dev teams, no amount of due diligence and policy can catch everything, no matter how good you are.  Fact is, dev teams are made up of people, and each person can make mistakes.  That’s why we have checks and balances like code reviews, unit tests, QA, and the like.  No system is perfect, human or digital (which is built by humans).  Always expecting perfection is only setting yourself up to be disappointed.

    Apple researched it and found a fix to a problem that does not appear to be easily found and issued the fix.  What more could you ask for?

    http://www.stilldrinking.org/programming-sucks
    Of course not, but this isn't the first nor the second time this has happened to iMessage. Having a hole in iMessage and then a second hole in the sandbox that's supposed to stop holes in iMessage from becoming a problem isn't good. Means their unit tests aren't thorough enough and the sandbox isn't doing enough bounds checking.
    But that’s assuming they know what they don’t know… now that they know it they can put in the appropriate fixes and tests.  Only someone that is omniscient can cover all the bases.

    This may not be the first, or second, or even the last (similar but not exact cases), because until Messages bites the dust, there will be issues with it.  And as new features get added, it may again break in similar ways because, well, it’s a new interaction that has to be accounted for, and as each feature gets added, the surface area that needs testing grows exponentially.  If it were to be perfectly tested, the software would never get released…

    ¯\_(ツ)_/¯
    watto_cobra
  • Reply 14 of 15
    elijahgelijahg Posts: 2,759member
    elijahg said:
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Having been apart of many dev teams, no amount of due diligence and policy can catch everything, no matter how good you are.  Fact is, dev teams are made up of people, and each person can make mistakes.  That’s why we have checks and balances like code reviews, unit tests, QA, and the like.  No system is perfect, human or digital (which is built by humans).  Always expecting perfection is only setting yourself up to be disappointed.

    Apple researched it and found a fix to a problem that does not appear to be easily found and issued the fix.  What more could you ask for?

    http://www.stilldrinking.org/programming-sucks
    Of course not, but this isn't the first nor the second time this has happened to iMessage. Having a hole in iMessage and then a second hole in the sandbox that's supposed to stop holes in iMessage from becoming a problem isn't good. Means their unit tests aren't thorough enough and the sandbox isn't doing enough bounds checking.
    But that’s assuming they know what they don’t know… now that they know it they can put in the appropriate fixes and tests.  Only someone that is omniscient can cover all the bases.

    This may not be the first, or second, or even the last (similar but not exact cases), because until Messages bites the dust, there will be issues with it.  And as new features get added, it may again break in similar ways because, well, it’s a new interaction that has to be accounted for, and as each feature gets added, the surface area that needs testing grows exponentially.  If it were to be perfectly tested, the software would never get released…

    ¯\_(ツ)_/¯
    Unit tests are used to find out what they don't know. A well designed software design process doesn't just test software by a human or computer entering data into the user-facing aspects of the program, i.e. entering random data into a text box or by loading a file. It tests extensively and without human input private functions within the program itself. You write a program to fire every conceivable argument into a function, be they incorrect data types, data too big for their type, strings that exceed memory length, arrays too big to fit in allocated memory, extreme negative numbers, positive numbers, invalid and null pointers. The function should never crash or write outside its allocated memory space. If it does, it should fail the unit test. I don't doubt this is done for the kernel, as it seems to have very few bugs. Other Apple software though, not so much.
  • Reply 15 of 15
    exceptionhandlerexceptionhandler Posts: 369member
    elijahg said:
    elijahg said:
    elijahg said:
    Come on Apple. If there is a hole in an app that's bad enough, but having an exploitable hole in an app that allows a further exploit in that app's sandbox, enabling an attacker to escape the sandbox points to some very shoddy code practises. Someone needs to take a good hard look at their unit tests and make them much more robust. Sanitising input is a solved problem, to have repeated issues as a result of specially crafted data is really quite atrocious.
    Having been apart of many dev teams, no amount of due diligence and policy can catch everything, no matter how good you are.  Fact is, dev teams are made up of people, and each person can make mistakes.  That’s why we have checks and balances like code reviews, unit tests, QA, and the like.  No system is perfect, human or digital (which is built by humans).  Always expecting perfection is only setting yourself up to be disappointed.

    Apple researched it and found a fix to a problem that does not appear to be easily found and issued the fix.  What more could you ask for?

    http://www.stilldrinking.org/programming-sucks
    Of course not, but this isn't the first nor the second time this has happened to iMessage. Having a hole in iMessage and then a second hole in the sandbox that's supposed to stop holes in iMessage from becoming a problem isn't good. Means their unit tests aren't thorough enough and the sandbox isn't doing enough bounds checking.
    But that’s assuming they know what they don’t know… now that they know it they can put in the appropriate fixes and tests.  Only someone that is omniscient can cover all the bases.

    This may not be the first, or second, or even the last (similar but not exact cases), because until Messages bites the dust, there will be issues with it.  And as new features get added, it may again break in similar ways because, well, it’s a new interaction that has to be accounted for, and as each feature gets added, the surface area that needs testing grows exponentially.  If it were to be perfectly tested, the software would never get released…

    ¯\_(ツ)_/¯
    Unit tests are used to find out what they don't know. A well designed software design process doesn't just test software by a human or computer entering data into the user-facing aspects of the program, i.e. entering random data into a text box or by loading a file. It tests extensively and without human input private functions within the program itself. You write a program to fire every conceivable argument into a function, be they incorrect data types, data too big for their type, strings that exceed memory length, arrays too big to fit in allocated memory, extreme negative numbers, positive numbers, invalid and null pointers. The function should never crash or write outside its allocated memory space. If it does, it should fail the unit test. I don't doubt this is done for the kernel, as it seems to have very few bugs. Other Apple software though, not so much.
    Unit tests are used to make sure a component works as expected.  They are to be fine grained, testing only one thing.  Integration tests test how the pieces work together.

    it’s easier to test how something is defined to work.  You have to know to write the test to begin with.  Date ranges are an example.  If a date is supposed to fall within a small range (lets say a week), testing the positive space is not too bad (7 days), but testing the complete negative space is impossible.  An assumption can be made here, and that is to check just a few at the bounds, but how do you KNOW it will work for all cases if they aren’t all tested?

    Integration tests are harder, because you can’t always tell how 1 or likely many many more components may fail in every way they work together.  Again, its easier to check the defined paths, but each time you add a new component into the mix, there’s an exponential risk of some behavior not working as expected.
    watto_cobra
Sign In or Register to comment.