Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iMessage: Malformed Message Bricks iPhone

bugs.chromium.org

Post reply on HN
Print view View original

81–90 of 279 posts

Re: iMessage: Malformed Message Bricks iPhone

#81

Post by oarsinsync »

gregmac wrote: post #37
taneq wrote: post #19

Earlier quoted context omitted.

It's a sliding scale which depends on the user's competence and not just the hardware. To a completely non-technical person, a hard lock-up is "bricked" even if it could be fixed by pressing buttons. To a normal user, a borked ROM is "bricked" even if it could be fixed by plugging into a computer and re-flashing. To a power user, a busted bootloader is "bricked" if it stops them flashing a ROM, even if it could be fi…

This is a good way to describe the reality of "bricked", and I think you could extend this to consider price, too. Even to the EE, the cost of parts and time to repair may exceed the cost of replacement, much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value. "Bricked" may still not be the right term, but the difference is irrelevant at that point. Anothe…

> much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value

I've never heard of a minor incident referred to as being "totalled", but rather a "write-off", since it's the insurance companies that are ultimately making that decision, not the repair service. Is that a regional thing?

Re: iMessage: Malformed Message Bricks iPhone

#82

Post by dragonwriter »

oarsinsync wrote: post #81
gregmac wrote: post #37

Earlier quoted context omitted.

This is a good way to describe the reality of "bricked", and I think you could extend this to consider price, too. Even to the EE, the cost of parts and time to repair may exceed the cost of replacement, much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value. "Bricked" may still not be the right term, but the difference is irrelevant at that point. Anothe…

> much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value I've never heard of a minor incident referred to as being "totalled", but rather a "write-off", since it's the insurance companies that are ultimately making that decision, not the repair service. Is that a regional thing?

I don't know if it is a regional thing, but “totalled” is what I've always heard, and refers specifically to (and the term derives from) the insurance company declaring the vehicle a “total loss” and applying replacement rather than repair compensation.

Re: iMessage: Malformed Message Bricks iPhone

#83

Post by Buge »

kennywinker wrote: post #58
EugeneOZ wrote: post #47

Lazy developers throw exceptions, good developers return errors. Exceptions should be exceptional. I'll use URL to this bug in my next comment-holywars to prove this point. Yes, it takes much less code to throw an exception in hope some code will catch it, but while compiler (not runtime) doesn't check it - this technique is not safe. So we should return errors, check them and handle - sometimes it means returning er…

This error is due to use of a un type checked language (objc). You can blame the coding style all you want but it’s like blaming bad drivers for accidents instead of fixing the system.

> blaming bad drivers for accidents instead of fixing the system.

I had to read that several times before I realized you weren't talking about computer device drivers and computer systems.

Re: iMessage: Malformed Message Bricks iPhone

#85

Post by kirb »

olliej wrote: post #20
viraptor wrote: post #15

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...

right? ignoring the issue of invalid assumptions in iMessage taking content from the network (though at least it's objective-c so it's a "DoS" rather than RCE). The problem here seems to be that the code handling the incoming message is inexplicably running inside springboard rather than a separate process. :-/

I’ve somewhat researched iMessage handling on iOS for a jailbreak tweak called TypeStatus, and I find this bug odd. In iOS 7, SpringBoard was restricted at the sandbox (kernel) level from any access to the Messages database. I had to adapt my code to instead run inside imagent, which is responsible for keeping a push socket open with iMessage among other Messages housekeeping things (this also exists on macOS).

There was a trend since iOS 6 to move backend/non-UI responsibilities away from SpringBoard. But in iOS 11 or 12 or so, more responsibilities started creeping back into SpringBoard. Maybe because of performance or memory consumption concerns, maybe it’s laziness avoiding having to set up a new daemon with appropriate dependencies and sandbox profile when the code can easily be plopped into SpringBoard, it’s not clear. As Natalie says in the report, on macOS this bug only causes DoS on a daemon. Worst case, iMessage stops working and your battery dies quicker. Being totally locked out of the device because SpringBoard is “boot looping” due to an existing fail-safe being excluded from the design seems awful.

On the subject, my Android phone stopped even presenting a keyboard on the lock screen or anywhere else, because the default keyboard is Gboard, and Gboard relies on Play Services, which was crashing inside Gboard. Like this iOS bug, the only known solution is to wipe the device and start over. At least I was still able to get into the device by connecting a USB keyboard. Sucks to know most would have no idea how to diagnose such an issue though, needlessly wiping their photos and all.

Re: iMessage: Malformed Message Bricks iPhone

#86

Post by ptaipale »

davej wrote: post #63
ehsankia wrote: post #49

Earlier quoted context omitted.

The reasoning is that once a fix is out, by making it public then users can know about it and intentionally update their devices if they haven't yet.

Sounds good in theory. In reality, the vast majority of iPhone users are not aware that this bug exists and never will be. The best action for user safety is to wait until the period has elapsed or the exploit has been seen in the wild already. Alternatively, they could publish the gist of the exploit without providing enough detail to actually perform the exploit.

Publishing it like this will make them more likely to be aware of it. They may not read Hacker News but it spreads to Facebook user groups etc.

The bad guys (many enough of them) will anyway figure it out right away after the patches have been published, because with every patch, people will (and should) ask "why".

Re: iMessage: Malformed Message Bricks iPhone

#87

Post by kalleboo »

drieddust wrote: post #76
Razengan wrote: post #54

Can this be avoided by disabling iMessage notifications? > The calling method then calls -[IMBalloonPluginDataSource _replaceHandleWithContactNameInString:] which calls im_handleIdentifiers on the 'NSString' which is really an NSNumber, which throws an exception as the selector does not exist in that class. Looks like they need to move more of their stuff to Swift to reduce snarfles like this. Stories like these (thi…

> Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares walked the land. You are speaking like an Apple fanboy. Days of XP are in the past and even Windows 7/Windows 2008 fairs better than Apple OSX and iOS. This is especially bad as apple sells a false sense of security when they fail to build even the basics correctly. Their walled garden is paved with expensive ibricks. Edit: Those who think I…

> Edit: Those who think I am speaking rubbish can refer this link. https://www.cvedetails.com/top-50-products.php

That listing groups together all OS X bugs back to 2002 under one heading, but splits up each Windows version into its own entity. So the numbers aren't really comparable.

Re: iMessage: Malformed Message Bricks iPhone

#88

Post by jug »

ehsankia wrote: post #49
Twisell wrote: post #40

Earlier quoted context omitted.

Yeah but maybe it would be nice for users to keep that extra time in order to maximize the probability that they have actually updated software at disclosure time. Disclosing in advance is a bad policy, it will just incentive good behaving vendors that update fast to delay full description of their changelog for security reasons because you put their users at unnecessary risks.

The reasoning is that once a fix is out, by making it public then users can know about it and intentionally update their devices if they haven't yet.

That sounds like a logic flaw because iPhones and most other devices like it will normally auto update after a short while. I think more people will rely on that feature than browse, uh, bugs.chromium.org...

This view of it will assist hackers in getting a head start before the auto update cycle gets to your device and you're notified. And if you're hit but something like this before that, your iPhone will no longer be able to update and apply the fix.

Of course, there's no way to find an objectively "correct" time frame since update cycles vary, but a month or two ought to give plenty of time for the updates to roll out and users to be made aware.

Re: iMessage: Malformed Message Bricks iPhone

#89

Post by bildung »

kalleboo wrote: post #87
drieddust wrote: post #76

Earlier quoted context omitted.

> Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares walked the land. You are speaking like an Apple fanboy. Days of XP are in the past and even Windows 7/Windows 2008 fairs better than Apple OSX and iOS. This is especially bad as apple sells a false sense of security when they fail to build even the basics correctly. Their walled garden is paved with expensive ibricks. Edit: Those who think I…

> Edit: Those who think I am speaking rubbish can refer this link. https://www.cvedetails.com/top-50-products.php That listing groups together all OS X bugs back to 2002 under one heading, but splits up each Windows version into its own entity. So the numbers aren't really comparable.

But the bottom of that page has a cumulative count by vendor which shows Apple having the second most security issues, only topped by Microsoft. Considering the fact that Microsoft has much bigger market share and therefore security research attention, that's quite an achievement.
Post reply on HN