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

71–80 of 279 posts

Re: iMessage: Malformed Message Bricks iPhone

#71

Post by saurik »

saagarjha wrote: post #69
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…

> Can this be avoided by disabling iMessage notifications? Why do you think so?

From the code right after that quote, I would be confused if a the view fronting that IMBalloonPluginDataSource was rendered in SpringBoard if you had turned off notifications.

Re: iMessage: Malformed Message Bricks iPhone

#72

Post by Razengan »

saagarjha wrote: post #69
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…

> Can this be avoided by disabling iMessage notifications? Why do you think so?

I'm assuming it crashes when it first tries to display a preview for the message?

Or does it happen even if you never use iMessage and have its notifications disabled?

Re: iMessage: Malformed Message Bricks iPhone

#73

Post by michaelmrose »

dang wrote: post #61
michaelmrose wrote: post #27

Earlier quoted context omitted.

Technical terms have meaning defined by actual technical usage regardless of common misuse by the less informed. Your entire tower isn't a cpu, a user recoverable device isn't bricked and if tomorrow most people start calling kidneys livers they will still be kidneys. Reducing bricked to a subjective statement about the users ability to use their device robs the term of all utility in the same way as calling a comput…

Please edit acerbic swipes out of your comments here. https://news.ycombinator.com/newsguidelines.html

I don't think I CAN edit it at this point but I will revisit the guidelines. Do you feel that just the sentence that was problematic then?

Re: iMessage: Malformed Message Bricks iPhone

#74

Post by saagarjha »

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

> invalid assumptions in iMessage taking content from the network (though at least it's objective-c so it's a "DoS" rather than RCE)

In this case. In general, however, Objective-C can often fall victim to attacks where poorly validated attacker data ends up causing RCE: see the entire reason for the existence of NSSecureCoding.

Re: iMessage: Malformed Message Bricks iPhone

#75

Post by Twisell »

sudhirj wrote: post #68
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.

Security researchers have to assume that if they've found a vulnerability, it's only a matter of time before the evil people will find it as well - that is if they haven't found it already. That's why all disclosures come with window - if they don't, the companies aren't under any pressure to update their systems, the exploit start being used in the wild, etc. The window is not ideal, but it is better than no window.…

Still make no sense, I agree the window is a good policy to force lazy vendors to act as they should.

But what’s the point of reducing the window for nice vendors who quickly delivered a patch?

This is totally counter productive. In order to incentivize vendors to deliver patches more and more quickly, good actors should profits from that extra time to secure their user base. In a ideal world that might even permit to reduce the windows in the futur when everyone behave well.

This is just jerking around and sending bad signal unless of course that anticipated disclosure date was decided together with the vendor.

Re: iMessage: Malformed Message Bricks iPhone

#76

Post by drieddust »

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 am speaking rubbish can refer this link. https://www.cvedetails.com/top-50-products.php

Re: iMessage: Malformed Message Bricks iPhone

#77

Post by floatingatoll »

peterkelly wrote: post #41
floatingatoll wrote: post #17

Earlier quoted context omitted.

You only lose data if you’re not backing up your phone - it’s not a corruption bug that breaks the ability to restore backups (like one of the iOS iOS 11 developer betas did).

That's like saying that with a faulty hard drive you can only lose data if you're not backing it up.

Close, but imprecise. I’m saying two things:

You can lose data with a faulty hard drive if your backup is silently corrupted and you don’t realize it. That’s not a risk here, as long as before restoring from backup you upgrade the phone OS to patch the bug.

Also, you can lose data with a faulty hard drive if you have no backup.

Rooters especially will care about these points since they typically cannot restore from backups without upgrading the phone away from a rooted version, due to choices made by Apple in firmware.

Re: iMessage: Malformed Message Bricks iPhone

#80

Post by oarsinsync »

tjmc wrote: post #78

What about older 32 bit iOS devices that can't be updated past iOS 10? Will they issue an update for them or do you just have to turn off iMessage? Still have a perfectly functional Series 4 iPad

Given that jailbreaks exist and can be exploited by malicious actors, deploying them as the user and applying the jailbreak community supplied fix may be the best approach:

> For those with jailbroken iPhones, a community member has released the tweak BrickFix: https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...

(source: https://news.ycombinator.com/item?id=20379779)

Post reply on HN