21–30 of 122 posts
This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we shouldn't be writing new code in C.
What Apple, and Microsoft before them, are discovering is the tools and processes we use to create software simply doesn't scale. We're simply reaching the limits of what these giant software teams are able to produce and keep running. We can discuss solutions, but currently not everybody even agrees we have a problem. That's the first step we need to take.
I've never done any fuzzing personally, but wouldn't this be discoverable internally during testing? I would think that they would attempt sending all possible characters, especially because they've had issues with this in the past.
it looks like the single character was made up of 4 utf8 code points. so might have been trickier to detect from fuzzing than it looks.
I've used AFL [1] to generate semantically valid, crashing multi-statement SQL queries when given ~50 CPU days and a simplistic SQL-like database. All from thin air, with an empty text file as the initial testcase. It can also come up with valid JPEGs [2] given enough time.
[1] - http://lcamtuf.coredump.cx/afl/
[2] - https://lcamtuf.blogspot.ie/2014/11/pulling-jpegs-out-of-thi...
What Apple, and Microsoft before them, are discovering is the tools and processes we use to create software simply doesn't scale. We're simply reaching the limits of what these giant software teams are able to produce and keep running. We can discuss solutions, but currently not everybody even agrees we have a problem. That's the first step we need to take.
I disagree that this is the product of scale. Looking at some of the bugs coming out of Apple lately and how they respond to them (assuming it's really a trend and not just a run of bad luck) it feels like they're slipping into a culture where individual feature teams are making emotional or schedule-based decisions about security without central guidance. A good example is the recent bug on MacOS where a low-privile…
This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we shouldn't be writing new code in C.
This isn't the first time a weird sequence of Unicode characters has caused the text renderer to crash and create problems for iOS users. This is why we shouldn't be writing new code in C.
More like "this is why we should use LLVM's libFuzzer or similar". Apple is just not doing basic code hygiene stuff here.
Here's a link to the character if someone wants to test it themselves https://pastebin.com/9Tr8ytTr
Wow, that even crashes Safari on my Mac.
$ sqlite3 ~/Library/Safari/History.db
SQLite version 3.19.3 2017-06-27 16:40:08
Enter ".help" for usage hints.
sqlite> delete from history_items where url = "https://pastebin.com/9Tr8ytTr";I've never done any fuzzing personally, but wouldn't this be discoverable internally during testing? I would think that they would attempt sending all possible characters, especially because they've had issues with this in the past.
I would hope that after all the character-crashing-everything bugs that have hit iOS there is a team dedicated to replacing the text rendering code with something more fault tolerant.
Here's a link to the character if someone wants to test it themselves https://pastebin.com/9Tr8ytTr