Live data from Hacker News

iMessage: Malformed Message Bricks iPhone

bugs.chromium.org

131–140 of 279 posts

Re: iMessage: Malformed Message Bricks iPhone

#131

Earlier quoted context omitted.

Is this an issue of complexity or lack of isolation? More isolation means more complexity, but at the same time, this issue should crash the iMessage app itself, not the whole system. The fact that springboard even knows about iMessage structure is crazy...

Complexity. You don't really need isolation if the code is so simple as to obviously contain no bugs (instead of containing no obvious bugs.) Instead, we have a whole industry built upon encouraging the creation of things as complex as possible, and working around the problems caused by that by adding even more complexity, mainly because it means people have more to do. http://countercomplex.blogspot.com/2014/08/the-…

I think you could achieve low complexity at the time of early feature phones. If you get a web browser and loadable untrusted binaries in the system, you've lost this battle. There is no way to make those "obviously contain no bugs".

So you're kind of right, we wouldn't need isolation... if not for the fact modern mobiles exist.

But even then - people are creative. Software may be obviously bug free, hardware may be obviously bug free... then someone comes up with rowhammer and you're owned by pure physics. I'm not sure "obviously bug free" even exists.

Re: iMessage: Malformed Message Bricks iPhone

#132
post #7

This is fixed in iOS 12.3 [1] and macOS 10.14.5 [2], both released on May 13th. As Natalie noted on the ticket, turning off iMessage will also prevent the bug. [1]: https://support.apple.com/en-us/HT210118 [2]: https://support.apple.com/en-us/HT210119

Turning off iMessage to prevent the bug is like turning off a car to prevent to consume petrol.. what a solution

It's more like turning off air conditioning system (because it's broken) to stop excessive consumption of petrol... Since you can still use the phone, just not one part of it (until you fix the air contidioner)

Re: iMessage: Malformed Message Bricks iPhone

#133
post #114
post #46

Earlier quoted context omitted.

The fix has been available for almost two months. Don't iOS updates hit the 50% adoption mark within two weeks?

http://gs.statcounter.com/ios-version-market-share/mobile-ta... shows 12.3 at around 50%, so the question for me would be what percentage of that long tail would upgrade within any reasonable extension period. Public news might actually accelerate that since it gives people a reason not to procrastinate hitting that button.

The numbers at the top are misleading. Are they the average over the graph's time interval? Average over June? Not clear, but I suspect the latter.

If you switch the graph to daily, you see that it passed 51% on June 10th, i.e. in four weeks, and it's at 66% now.

http://gs.statcounter.com/ios-version-market-share/mobile-ta...

But yeah, the big question is how stubborn that long tail is, in the face of news reports about serious bugs or not.

Re: iMessage: Malformed Message Bricks iPhone

#135
Speaking as an ex-Apple employee, I'll just point out that a really malicious actor could have used this to harm some significant percentage of the installed iOS infrastructure, and done critical damage to Apple as a company with it. In fact, I don't know the percentage of users still on <12.3, but maybe they still could. A band-aid fix for this one bug should not be where they stop here.

Re: iMessage: Malformed Message Bricks iPhone

#136
post #34

This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear. There it wasn’t entirely uncommon that when you sent a malformed sms-deliver PDU (e.g. text message) to the phone and crashed parser that tried to decode it, it took also the phone down before it could ack the message back to SMSC. Which of course meant that as soon as phone was turned on and it registered to network, t…

Back in the day AOL parsed HTML for it's instant messages, a would blue screen any client running windows. It was quite easy to empty chat room(s) using this.

Hahaha on Yahoo we called it booting.

Re: iMessage: Malformed Message Bricks iPhone

#137
I see a free data hack: Load a version of iMessage that never acknowledges the message, but saves the data (and doesn't brick the phone). Send lots of data, acknowledge via other means (checksum sent over email etc). How much data could be sent this way? GBs?

Re: iMessage: Malformed Message Bricks iPhone

#138
post #34

This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear. There it wasn’t entirely uncommon that when you sent a malformed sms-deliver PDU (e.g. text message) to the phone and crashed parser that tried to decode it, it took also the phone down before it could ack the message back to SMSC. Which of course meant that as soon as phone was turned on and it registered to network, t…

Fascinating problem. Since I have Faraday cages on the mind today (not that I know much more than ~10 minutes of reading)... simply isolating the phone from all signals would block both the message and any software update, so that doesn't work. But what if you attached it to wifi but not to the cell network? Either have the wifi router (itself having a wired connection) and the phone in the same shield; or, I guess,…

To answer your question about selectively blocking, just put the wifi router inside the cage. To the point though, feature phones didn't have WiFi generally. I'm also not sure how doing so would fix the issue, unless you could block the number perhaps.

Re: iMessage: Malformed Message Bricks iPhone

#139
post #136

Earlier quoted context omitted.

Back in the day AOL parsed HTML for it's instant messages, a would blue screen any client running windows. It was quite easy to empty chat room(s) using this.

Hahaha on Yahoo we called it booting.

Doesn't that date back to IRC?

Re: iMessage: Malformed Message Bricks iPhone

#140

Yet another wrong use of the word bricked. Bricked means bricked and you can’t ever come back from that.

This definition never holds up to scrutiny. For example, if I pull out my EPROM writer, de-solder the chips, and update them almost no device is truly "bricked" by this definition. The only exceptions would be burned update fuses or similar physical damage. Making the definition itself extremely niche, to the point of being synonymous with "physically damaged/destroyed." I myself stick to the broader "technologically…

I stand by words mean things. If you can recover in any way, it's not a brick. In this case it is a boot loop and there's no reason they should not have used boot loop to describe the condition.
Post reply on HN