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

251–260 of 279 posts

Re: iMessage: Malformed Message Bricks iPhone

#251

Post by Dylan16807 »

zaroth wrote: post #158
Dylan16807 wrote: post #59

Earlier quoted context omitted.

Not a brick if you have to replace a storage device. Is it a brick if you have to replace a motherboard? Would replacing a motherboard not have fixed your xbox? (Surely the commercial availability of a part isn't the deciding factor in whether something is a brick, right?)

Commercial availability of a part is absolutely a factor in deciding whether something is a brick! I.e. some large expensive machine is bricked because the manufacturer refuses to sell you a small proprietary part without which the machine is entirely non-functional. It’s a fairly frequent pattern where an IoT device becomes a brick because an API shuts down. Similarly, if you can’t replace a crucial part because the…

I guess we have fundamentally different definitions of "bricked", then. I'm always going to define brick by the type of damage. It's not like a car being totaled, where even cosmetic damage can total a car when its value is low enough.

Re: iMessage: Malformed Message Bricks iPhone

#252

Post by stcredzero »

rixrax wrote: 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…

This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear.

They were indeed hardened? Do tell.

I've suggested that the iPhone be hardened against rendering crashes, here on HN. The immediate reaction is to downvote me, then reply, "undefined behavior must crash the process." That's pretty glib and shortsighted, however. It took me just a few seconds to think of a solution.

Have one process write the messages in a log file. This process also supervises the second process. The 2nd process renders the messages. If the 2nd process keeps crashing on the same message, the 1st process marks that message as a problem, and the user can be prompted to send the hex dump of the message for diagnostic purposes. (So if it's spicy, they can say no.)

The fact that such a basic function of the iPhone can be remotely vanished, requiring a reboot, is a pretty glaring hole. What's even worse, is that highly paid SV programmers would shrug their shoulders so easily.

Re: iMessage: Malformed Message Bricks iPhone

#253

Post by applecrazy »

saagarjha wrote: post #248
swalsh wrote: post #242

Earlier quoted context omitted.

Would it not be possible to detect malformed messages, and prevent them from being sent to a phone in the first place?

No idea; it might be that Apple can't detect these because they're encrypted.

Yes, they're encrypted in transit.

Re: iMessage: Malformed Message Bricks iPhone

#254

Post by Natanael_L »

tambre wrote: post #213
askl wrote: post #100

Earlier quoted context omitted.

There was a nice talk about this a few years ago at the CCC congress. https://media.ccc.de/v/27c3-4060-en-attacking_mobile_phones http://www.ngolde.de/sms/smsodeath_mulliner_golde_cansecwest...

> [...] at the CCC congress Your "congress" is redundant because CCC=Chaos Communication Congress.

CCC = chaos computer club. They might also use it for other meanings, but referring to the actual original name makes absolute sense.

Re: iMessage: Malformed Message Bricks iPhone

#255

Post by iamnotacrook »

JustSomeNobody wrote: post #244
lagadu wrote: post #182

Earlier quoted context omitted.

Can you provide your definition of non-recoverable? An extreme example: someone could tear down the phone down to every single last nanometer-scale transistor and polymer, fix the problem and reassemble it; that would make it recoverable from even most scenarios of destruction, hell, with enough energy available one could in theory fuse/fusion it down into iron and reconstruct the very elements themselves in order to…

I'm curious, what component could you replace in this instance to recover the iPhone and not lose data? One could argue that every single component on a device could be replaced to bring it back from the dead, but I would argue it isn't the same device at that point. Bricked is a term that is, and always has been, defined as hardware that is rendered useless by bad software. Replacing hardware components to get a dev…

"One could argue that every single component on a device could be replaced to bring it back from the dead, but I would argue it isn't the same device at that point."

This is entering the realms of philosophy. If you get your screen replaced is it any longer your phone? If someone replaced every part of your phone one piece at a time, at teh pace of one piece a week did they suddenly steal it the moment the last piece was switched out? After all, they have "your" phone - if the concept of "your" phone ever made any sense in the first place.

Rendering useless by bad software - so if you take my linux device and install windows I now have something with objectively worse software than before, and where all my software no longer runs, and which is incapable of reading my ext4 formatting external hard drive. So...you've bricked it?

Re: iMessage: Malformed Message Bricks iPhone

#256

Post by marpstar »

andrew_ wrote: post #191
marpstar wrote: post #170

Earlier quoted context omitted.

On AOL we called it "punting", and the apps that facilitated it were the first reason I ever wanted to code.

Ditto. I got into VB because of this "exploit," and that kicked off my inadvertent career choice. Punters were all the rage. By the time AOL 3.0 rolled around, it wasn't bluescreening the machine, rather just ending the AOL process and disconnecting.

I downloaded VB4 from an AOL mail server when I was 11. I made the mistake of forwarding the email, which AOL considered making a pirated copy of the software. Came home from school the next day and our AOL account was terminated.

Re: iMessage: Malformed Message Bricks iPhone

#257

Post by Razengan »

drieddust wrote: post #167
Razengan wrote: post #160

Earlier quoted context omitted.

Not all malware is a "virus." Has iOS ever had anything where one app could "corrupt" other apps?

> Not all malware is a "virus." Haha, this is called moving the goal post. Fanboys do this all the time :) Edit: Plenty of buffer overflow and momory corruptions are listed for iOS just in 2019. https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

I've been saying virus since the start. There's a clear technical distinction, and unprecedented for a general-purpose platform to be free of those, until iOS.

If you want to use the broad, general definition of malware, then Microsoft literally bundles malware with Windows 10 in the form of their "telemetry" and Candy Crush advertisements.

Re: iMessage: Malformed Message Bricks iPhone

#258

Post by Razengan »

drieddust wrote: post #243
jki275 wrote: post #231

Earlier quoted context omitted.

buffer overflow and memory corruption is not a virus. He asked a specific question, and people answered different questions while ignoring the question he actually asked.

His specific question is just a diversion tactics. Parent comment was about Apple intentionally misleading gullible people for many years by claiming that MACs don't get virus. They didn't change until high profile attacks hit and it was no longer viable to make the claim. Instead of commenting on this, he just moved the goal post to iOS never getting a Virus. What does iOS never getting a Virus has anything to do wi…

Another thing, in technical communities, "MAC" in capitals has the implicit distinction of https://en.wikipedia.org/wiki/MAC_address

P.S. Look what just showed up: https://news.ycombinator.com/item?id=20383432

Re: iMessage: Malformed Message Bricks iPhone

#259

Post by microcolonel »

0x0 wrote: post #208
microcolonel wrote: post #150

Earlier quoted context omitted.

> That's not really a coupling issue, but a matter of GPU drivers not generally being hardened against shader/usage bugs. You shouldn't be able to crash the whole operating system (not just the display server, display driver, etc.) with an ordinary shader, even if it crashes the shader compiler or causes the GPU not to halt. It's not as though I wrote these shaders in an attempt to crash iOS.

That's not unique to iOS, though. It seems a lot of display drivers on a lot of platforms were developed without ever considering hostile shaders coming in over the network, in an era where mostly only game developers would catch crashes during development? For example https://chromium.googlesource.com/chromium/src/gpu/+/master/...

Most of the software rendering list in Chromium is about more general bad behaviour, lack of features, or redundant behaviour (i.e. a GL driver is available, but it's a software renderer anyway, so might as well use Skia's software renderer), not security/full system DoS.

For example, the one at id: 3 is for renderers with the lowercase word "software" in their name; id: 1 is a GPU which does not have enough features on its mac driver to run ANGLE for GLES 2.0 (and in turn WebGL 1); id: 5 is for very old versions of mesa, where the libGL would crash (which in practice means the application would crash, but not the display/windowing servers or the display driver, nor other applications).

This behaviour on iOS is especially bad, it is not like other systems. The piece of code which would cause an issue like that is dramatically smaller on most Linux and Windows graphics stacks.

Re: iMessage: Malformed Message Bricks iPhone

#260

Post by tardismechanic »

Comment 5 by a...@gmail.com on Thu, Jul 4, 2019, 5:33 PM PDT (3 days ago) I really hope that no one big covers this, because if they do... oh boy

Comment 6 by p...@gmail.com on Fri, Jul 5, 2019, 3:27 AM PDT (3 days ago) Too late, already out in big news website...

Post reply on HN