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

AppleInsider

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

elijahg

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.

blastdoor

Nobody gets by Blastdoor! 

lkrupp

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? 

jfc_pa

Fast and easy update. Thanks. 

Though I’m unlikely to be a state agency target. 

edited September 2021

dope_ahmine

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.

mork

Here,

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

fastasleep

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.

elijahg

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!

sevenfeet

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.

skippingrock

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. 

exceptionhandler

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

elijahg

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.

exceptionhandler

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…

¯\_(ツ)_/¯

elijahg

exceptionhandler said:

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…

¯\_(ツ)_/¯

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.

exceptionhandler

elijahg said:

exceptionhandler said:

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…

¯\_(ツ)_/¯

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.