exceptionhandler

https://xkcd.com/1172/

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.

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.

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

Illusive said:

Yet… here you are… ¯\_(ツ)_/¯

due to the industry I am in, I have dealt with the technical side of this stuff, but I am not sure the  actual technical details are relevant… that is the how… Dont dev me wrong, their implementation is super cool, but…

Another more recent quote I like to use, because I see bad tech designs/decisions all the time is:

“Yeah, but your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.” - Dr. Ian Malcolm

I see. A quote from an old action movie is certainly of more relevance here  

You’re missing the point, which is:

There are times when we do things just because we can. We tend to live in the moment without considerating of the consequences of our actions. Sometimes, the consequences aren’t worth it.

Which, while it comes from an old sci fi movie, is still applicable, and is more succinct.