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

61–70 of 279 posts

Re: iMessage: Malformed Message Bricks iPhone

#61

Post by dang »

michaelmrose wrote: post #27
slyrus wrote: post #22

Earlier quoted context omitted.

It's almost like the author of the above comment (zaroth) didn't read the parent comment. Put another way, bricking is in the eye of the beholder.

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

Re: iMessage: Malformed Message Bricks iPhone

#62

Post by dang »

slyrus wrote: post #22
zaroth wrote: post #21

Earlier quoted context omitted.

The only purpose of the word’s existence is to define an entirely unrecoverable state. Crash loop or hung on startup describes the state. It is by definition not bricked if it can be recovered.

It's almost like the author of the above comment (zaroth) didn't read the parent comment. Put another way, bricking is in the eye of the beholder.

Please don't comment on whether someone read a comment. That's informationless point-scoring, and the site guidelines explicitly ask you not to do that.

https://news.ycombinator.com/newsguidelines.html

Re: iMessage: Malformed Message Bricks iPhone

#63

Post by davej »

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.

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.

Re: iMessage: Malformed Message Bricks iPhone

#64

Post by yreg »

michaelmrose wrote: post #29
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…

A device that crashed isn't bricked. We already have a term for that.

This is more than a crash though since you have to wipe the phone.

Re: iMessage: Malformed Message Bricks iPhone

#65

Post by davej »

the-rc wrote: post #46
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 fix has been available for almost two months. Don't iOS updates hit the 50% adoption mark within two weeks?

I’m not sure of the stats honestly but there’s still going to be a huge long tail of people on earlier versions for months afterwards. I was surprised that I was still on iOS 12.2.

Re: iMessage: Malformed Message Bricks iPhone

#66

Post by plorkyeran »

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…

You want to write explicit error handling for every possible case of runtime type errors in a dynamically typed language?

The "unrecognized selector sent to instance" exception is not thrown in the hope that someone will catch it. It's intended to be a fatal error reporting a precondition violation.

Re: iMessage: Malformed Message Bricks iPhone

#67

Post by stefan_ »

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.

The other side is that the moment a patch is released, people will diff it to the previous version making it much more likely this issue is found by a lot of independent people who might seek to exploit it.

Re: iMessage: Malformed Message Bricks iPhone

#68

Post by sudhirj »

Twisell wrote: post #40
ascorbic wrote: post #33

Earlier quoted context omitted.

Because it's now fixed. The window is to allow the vendor to issue a fix.

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.

And there isn't much point arguing over 30 vs 90 vs 120 vs 365 days. 90 is reasonable, enough for even the largest mainstream software companies to issue a patch release.

Re: iMessage: Malformed Message Bricks iPhone

#69

Post by saagarjha »

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?

Post reply on HN