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, that same message was redelivered (crashing it again) for as far as the network was concerned, it was never received by the mobile. Until the time that message either expired in the SMSC in few days, or you switched you sim to a non-vulnerable mobile to receive the message. Good times.
Back in the day AOL parsed HTML for it's instant messages, a <font size=9999999999999999999999> would blue screen any client running windows. It was quite easy to empty chat room(s) using this.
Strange nostalgic memories of "AOHell" and "LuciferX" come to mind... If I remember, a lot of them were visual basic apps that would use SendKeys() to control AOL via keyboard shortcuts. A little like the wild west back then...
I remember Sub-7 and its modules, including those that forced the user to play (and win) a game of tic-tac-toe, could melt the screen, flip the screen upside down and misc destructive things.
I recall a few, FaTe, AoLazy, and others being shared in island55. Also memories of Master AOL & Internal/Overhead accounts that allowed infinite scrolling in chat.
Man, I wish I knew what I was doing back then. Major service providers allowing unsanitized inputs like that? Sounds like a lot of low hanging fruit! And this was before blogging was popular so communicating advanced techniques wasn't as easy back then either.
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.
my little secret to not getting punted on aol was to remove the aolrich.dll which was responsible for parsing all the html the client received. those were great days!
Not to beat my own drum but I did not agree with the ethics of booting, and while I was too lazy to code back then, I rooted for defensive apps that armored you against getting booted :D. Yahelite on Yahoo was the best.
Iirc the social engineering script was to “hold the alt key and repeatedly tap f4”. That has the two keys far enough from each other in prose to trick more people.
There's supposed to be a delay in the Hayes protocol to prevent this kind of thing, but many "Hayes compatible" implementations didn't implement that part (through ignorance? working around a patent?), so this trick would work pretty well . . .
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.
Yes, Sony Ericsson A200 had a bug in SMS picture decoding (old, monochorme, pre-MMS one) which was easily craftable into an exploit if carriers were allowing multipart SMS.
Guess what cell carriers did back then? Yes, they disabled multipart SMS
With what? Especially back then, I wouldn’t assume there is anything with a programmable CPU in the data path that can inspect and filter things at line rate.
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, people say Faraday cages target certain wavelengths, so if wifi and cell tower are sufficiently different, maybe you could have a selectively blocking Faraday cage. Would that have been workable? (non-EE here)
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.
Feature phones also didn't have OTA updates. I remember taking my phones to service centers to get the latest software flashed. Later on you could flash it yourself with a cable to your PC, browsing esato.com for new versions.
> 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.
By yesteryear do you mean the present and feature phones do you mean current android phones? Some models are still vulnerable to a text-of-death.
https://poetengineer.postach.io/post/deleting-the-text-of-de... not my blog, but the same problem happened with my mother in law's phone. The phone becomes unusable because of a stream of org.android.phone application has stopped messages and the only thing to do is use adb to delete all texts, until it comes in again. I was never able to pin down the exact problem.
Edit: Sorry, I didn't mean to come off as snarky, but I just wanted to 1) point out that there are still issues with decoding SMS and MMS messages, even in some modern phones and 2) provide a link to anyone who encounter the same issue as it was very frustrating for my MiL and very frustrating until I figured out I could just wipe all SMSes with adb.
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.
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)
I never understood this, why would anyone want to deal with ANOTHER app to do messaging? iMessage is built in, integrated, and has end to end encryption. What more functionality are people clamoring for?
People want to use one app to do all their messaging. iMessage is not that app unless 100% of the people you message use iPhones. For a lot of people Whatsapp or Telegram can be that app.
When you send as SMS, it's not encrypted, some of the group chat features don't work, the reactions come through as confusing "so and so liked an image" on Android, etc. It's a big hit to the feature set.
iMessage is a subset of features in the Messages app that are unavailable when communicating with someone on a non-Apple device or if one of the parties has iMessage turned off.
In the early days, iMessage had some availability issues - the only way you could get/send texts for a couple hours would be to switch it off so they'd send as SMS.
There was also a bug that allowed a malicious message to crash phones sometime last year where the recommended fix was turning off iMessage (similar to this one).
Some folks probably don't remember to turn it back on after these incidents.
It costs money to activate it (or so says the pop up that appears when you set up an iPhone).
Also if I switch to Android I don’t have to worry about disabling iMessage before. (Not that anybody in my country would ever send an iMessage or an SMS though...)
This shows up when you insert a sim that’s not activated with iMessage. Maybe it depends on your region. In my country you really have to pay because the activation process sends an sms message.
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.
What they should also do is block the malformed message from being sent too. Not sure how to do that, since iMessages are encrypted in transit, but I'm sure there's some way.
Apple controls the CA; it's pretty straight forward for them to check contents.
iMessage really could have been something great (despite apple controlling CA) if they had just opened it up for more devices. Instead WhatsApp wiped the floor with them.
What? No Apple cannot decrypt messages so cannot check the content.
Messages are not encrypted to
Apples keys they’re only encrypted to recipient device keys - there is no way for Apple to filter any content without removing the end to end encryption of iMessage, which Apple does not want to do - every bit of user content that Apple can decrypt increases the value in compromising Apple’s service infrastructure.
I've iPhone user I've ever met outside tech circles avoids installing OS updates. They end up updating soon anyway for a variety of reasons (some updated apps stop working, update occurs "on its own" overnight, to get rid of of the notification icon, and so on).
It does help that the process is pretty painless. And at least for me, a good excuse to do a reboot - which I really do as seldom as possible on my laptop and iphone.
The easiest thing that occurs to me would be a on-phone "message virus scanner" that self-updates and checks incoming messages against a threat database after decryption, but before passing them to the rest of the system.
Architecture-wise some thought should be given to keeping iOS from being DoS'd by the crash/respawn of any service.
Also, looking at the "assuming it's a string" line from the problem description, Apple needs to make an investment look through the codebase for this same error in other guises.
That's what occurs to me off the top of my head anyway.
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:
The degree of coupling in iOS has always puzzled me. In 2016 I was developing a WebGL program and I stumbled upon shaders which would cause iOS to reboot, on more than one occasion.
That's not really a coupling issue, but a matter of GPU drivers not generally being hardened against shader/usage bugs. Similar issues have existed on Windows, Linux, etc. browsers with WebGL support.
> 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.
But that's unrelated to how tightly coupled the app is with the OS, but rather how ungracefully the driver fails. No matter how "far away" the app is from the gpu, at some point in the pipeline whatever data is being received will have to interact with it in some way, via the driver.
Sure, you could patch the app to avoid sending what's known as bad data to the next layer but I'd argue that that's the wrong place to do it.
It might very well just be the OS's recovery procedure when the display server crashes, rather than an uncontrolled crash. It's not the phone is of much use without it, so might as well have a single booting procedure rather than trying to reboot subcomponents individually.
Wow, you could actually lose the data with this bug. Glad it was fixed in 12.3. I remember the last time something like this happened (4-5 years ago?) it would only crash the phone.
The problem isn’t that the bug itself will cause data loss - it’s that you have no way of using the phone because of the boot loop unless you wipe.
I’m not entirely sure how you’d go about updating the phone without booting into it, but I think it is possible, and that would be one way to avoid losing all your data due to the bug.
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).
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.
Genuinely curious: What’s the reasoning behind “unrestricting” this ahead of its 90 day window? (It’s tagged Deadline-90, Reported-2019-Apr-18 On Project Zero, so that’s July 18th?)
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.
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.
I think patching is firmly in your hands now, and this data may help you choose to upgrade if you were holding off for some reason. Imagine your favorite iOS game was broken by the release that fixes this, so you've been ignoring the update. Now that you know your phone can be bricked by a malicious text message, you may decide "I guess I won't be playing that game for a while" and upgrade. The point is, pretty much everyone that applies every update (which is automatic) has the update now. The last few stragglers are probably waiting for information exactly like this. Now they have it.
The patch itself reveals the vulnerability. Attackers analyze these things to see what they’ve fixed. If you release a patch but don’t announce the vulnerability that was patched, then you’re just hiding it from good guys who don’t have time to dig through the patch.
I wouldn't be terribly surprised if the vendor asked for it to be disclosed late in the afternoon before a long holiday weekend (in the US) with the hope that mainstream press outlets would not notice.
Your incentive line in no way matches reality. In the past every vendor that is given an unlimited open timeline on patching has not. This includes Microsoft, Apple, Oracle and most of the other large vendors. Most of them are better at patching, but this is mostly because of the risk at of someone zero daying the patch and destroying the userbase.
Security is not an ideal world, in fact I would say it is the opposite.
Microsoft (employees) has repeatedly argued that 90d can be unreasonable for Windows due to the development and testing cycle, which also has to align with “patch Tuesday”. I haven’t heard the complaints recently so maybe they’ve streamlined part of the process.
Windows 10 might be the largest enterprise codebase at over 50 million lines of code. It probably takes 30 days alone just to browse to the file that has the bug
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.
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.
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".
Reading (dis)assembly is a skill many in our profession are required to learn. It’s common in OS & security fields. Heck, when developing Windows on ARM we were told Friday that we’d come to work Monday with a mandatory “no source” debugging session where we had up to an hour to describe a hanged program’s intended behavior and why it was hanged. One of my colleagues also refused my symbols when I asked for help debugging a program. He was more comfortable in ASM than the latest C++
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.
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.
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?
This doesn't work with iMessage, because the carrier sees iMessage no differently from any other kind of data download. However, a friend of mine tried doing something similar using the <number>@txt.att.net (or equivalent for your carrier) email-to-SMS trick and wrote an Android app that parsed the messages. They promptly received a firmly worded email from AT&T and were forced to abandon the project.
It can be recovered so it's not actually a bricking, but this is very bad. If you aren't running 12.3 or later this will force you to turn iMessage off.
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 (this isn't the first time that iOS/macOS could be crashed by chat messages), and the empty root password debacle, or all the GateKeeper bypasses, make me wonder if their engineers take their own WWDC security-related talks seriously.
Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares walked the land.
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.
> 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.
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.
I'm not going to comment on Apple's software security standards (and Microsoft deserves more kudos for their focus on security after the bad old days of XP), I'm just pointing out that summing up CVEs is not a valid way to compare.
> Considering the fact that Microsoft has much bigger market share and therefore security research attention
The OS X bug numbers also include a bunch of bugs for open source projects that are bundled with OS X (Perl, Ruby, Python, SQLite, PHP etc) which increases the security research attention.
You mean MS historically has 100% more security issues. Also IE alone competes with entire OSes in that top 10.
That proves the other comment right, but surely you can spin it other ways. Anyone who has switched from old windows to Mac doesn’t need numbers to tell how wild it was.
> You mean MS historically has 100% more security issues.
For an OS used 1000% as often[0], yes.
I have no skin in this game, BTW, as I use neither. But given the number of security issues Apple has, I really bothers me that they still sell those products as somehow more secure.
Even now, I don't think any of macOS's recent failings are as bad as the Windows 10 update that deleted user documents [0], or all the official spyware and adware in the only operating system where you have to pay to even customize your wallpaper.
As for mobile, does anybody remember hearing of any iOS cross-app malware ("viruses") in the decade since it launched? I think that's pretty amazing.
> Haha, this is called moving the goal post. Fanboys do this all the time :)
Ignoring the jab, which has no place here, malware is a general term which includes viruses. From the Wikipedia page on computer viruses (https://en.wikipedia.org/wiki/Computer_virus):
> The term "virus" is also misused by extension to refer to other types of malware. "Malware" encompasses computer viruses along with many other forms of malicious software, such as computer "worms", ransomware, spyware, adware, trojan horses, keyloggers, rootkits, bootkits, malicious Browser Helper Object (BHOs), and other malicious software. The majority of active malware threats are actually trojan horse programs or computer worms rather than computer viruses. The term computer virus, coined by Fred Cohen in 1985, is a misnomer.[16] Viruses often perform some type of harmful activity on infected host computers, such as acquisition of hard disk space or central processing unit (CPU) time, accessing private information (e.g., credit card numbers), corrupting data, displaying political or humorous messages on the user's screen, spamming their e-mail contacts, logging their keystrokes, or even rendering the computer useless. However, not all viruses carry a destructive "payload" and attempt to hide themselves—the defining characteristic of viruses is that they are self-replicating computer programs which modify other software without user consent.
> Edit: Plenty of buffer overflow and momory corruptions are listed for iOS just in 2019.
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.
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 with Apple being dishonest?
Do Macs get viruses? In general, they don't. Certainly people have a variety of opinions on why that is, but the fact remains. I think someone finally may have made one, which was why Apple dropped that particular point out of their ad campaign.
His specific question has an answer, and you chose to obfuscate instead of answering.
You posted a link from 2012 [0] that you apparently didn't even read, saying that Apple claimed Macs didn't get viruses, whereas the link's headline is "Apple Drops 'We Don't Get Pc Viruses' Schtick."
You then went on to ignore that contradiction. Does that fall under "moving the goal post" too?
I also suspect you created a new account for the sole purpose of supporting yourself in this argument. [1]
Apple doesn't lock down iMessage sending. A long time ago I've used AppleScript to automating sending messages (SMS/iMessage) successfully. These days you can probably use JavaScript as well.
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 as useful as a brick" definition. Which a boot-looping iPhone absolutely fits. The fact there are ways to recover it is neither here nor there.
I generally call what you're describing a "Hard Brick." But even those are sometimes recoverable via as I said chip re-programming.
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.
A bricked device can be recovered - usually - by replacing hardware, that's the limit of the definition. The GP comment is right, bricked is bricked and there's no way to recover a bricked device with any software means. It means the hardware is fucked and it's usefulness is equivalent to a brick.
What if you can reprogram an eeprom to make it work, would you consider it bricked? You're not replacing any hardware and are fixing only software.
At the end of the day language is (for all pragmatic purposes) finite but possible states of the universe are not, so you can't have a perfect definition of that catches all possible states you want while excluding all others with perfect accuracy.
No, it's not as simple as that. People use brick to mean slightly different things - sometimes they say hard/soft bricked instead of bricked. And you'll even find some people who say what you say but admit that it was still the correct word to describe devices which can only be fixed by disassembling the hardware and using jtag, which "brick extremists" probably wouldn't allow.
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 eventually produce a working phone again.
There are some implicit limits to what "bricked" means and those limits vary by individual.
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 device working is not un-bricking it.
"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?
> 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?
Obviously not because you can always put Linux back on it. A bricked device, you have no way of doing this. It's useless.
I can't believe all of this discussion simply because people want reuse a word that already means something. It's like the FE devs hijacking "real time". Good grief already.
I can't help but imagine what would happen if you take a phone stuck like this to the apple store. Would they save your phone or tell you to reinstall?
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 fixed with a JTAG debugger. To a sufficiently good EE, it's not bricked until the whole thing is physically destroyed.
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.
Another consideration is there's a big difference to a user if the fix requires erasing all data, as the work required (after fixing) is then the same as getting a replacement. At the least, this is the effort of applying updates, restoring backups, then dealing with all the fiddly things that didn't update/reinstall/restore properly. At worst, it's irreplaceable data loss (and a hard lesson in why backups are important).
> 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.
I think data recovery is a big factor. From all of the discussion around it here, it seems like the key points are "data can't be recovered without physically modifying the hardware" and "hardware can't be made usable for less than the cost of replacement." For me, losing the ability to use my handset is a minor inconvenience but losing the data on it would be a real pain (speaking of which I should back up my contacts list right now...) I'd imagine I'm not alone in this.
Used to work on phones on the Android side. I remember blowing the Qfuse was widely known internally to brick devices, but there was a team that specifically could reverse the brick - except it was a secret because the company didn't want the fact that it could be reverted to be known.
And as my post illustrated, "unrecoverable" is entirely relative to the user's capabilities. There's no such thing as "entirely unrecoverable" to a suitably equipped and motivated person, although you get into a Ship-of-Theseus situation if enough hardware needs replacing.
There’s a fairly meaningful distinction between replace, repair, and recover.
In this case we can recover the phone without replacing any hardware at all, so bringing up repair or replacement is a bit of a red herring.
But as I recall, Theseus’ ship was repaired over so many battles, nothing of the original remained. That is distinctly different than botching a single repair so badly you would have been better off replacing from the onset.
There are plenty of ways to get plenty of hardware into an obviously FUBAR state. It’s simply false to say that there is no such thing as a definitively bricked state for any device whatsoever.
Simple rule of thumb; if the commonly accepted solution is “get a new device” then you’ve probably bricked it.
Absolutely no one will have to buy a new iPhone because of this bug.
I think a fair in-between value on the "sliding scale" is calling a device bricked if it can't be recovered by a sufficiently advanced end-user without special hardware. If there is no way that an end-user could fix it without purchasing something or returning it to the manufacturer, it is bricked.
We can use it like when a car is "totalled". If it would cost the user more to fix the device (because they are nontechnical or need special parts) than the device is worth, then it is bricked.
“Difficult [for someone] to recover” should not be a partially overlapping state as “bricked”.
I had a EdgeMax Lite router which has a propensity for the flash storage to get corrupted at which point it fails to boot. The fix is to buy a particular model of USB flash drive, and image it with a specific .img file. Open the case and replace the flash stick, then boot holding the reset button.
It was a somewhat difficult repair, but in the end just a matter of following step-by-step instructions with readily available tools. I would not consider the device to have been bricked. No more than your computer is bricked when your hard drive dies.
I did brick an Xbox once, trying to solder on an early gen mod chip that was well beyond my soldering abilities!
In this case it’s not even a question of hardware damage. The fix is to reset to factory, upgrade, and restore. This is the happy path recovery process which has done millions of times over on iPhones. I had to do it just a couple weeks ago when my son changed the PIN on an iPhone we use to play music on, and then promptly forgot the new PIN. (He’s 7)
With the proposed meaning, everything is a brick to the technologically illiterate. Better to admit the headline is simply sensationalizing / clickbait.
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 manufacturer won’t sell it to you, that would brick a device. If the device is cheaper to replace than to repair, then it is bricked (the Xbox).
A brick must be entirely non-functional and simply not worth repairing. It’s supposed to be a less vulgar version of FUBAR.
There are rare stories of extraordinary lengths that a maker will go to (such as fabbing your own custom parts, or standing up a private version of an API and DNS hijacking requests from the device in order to make it function again) in order to “un-brick” a device. The defining trait of these stories is that something new is invented in order to make the device function again.
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.
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.
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 computer a cpu.
The author didn't fail to read your words, you are in fact wrong and repeating yourself doesn't make you more correct.
They weren't my words, so I'm not repeating myself. Just agreeing with the point that the term "brick" is subjective. Requiring one to go to heroic measures to render their device useful would make me consider the device "bricked" for all intents and purposes. Folks more technically skilled than I might be able to recover my device, but if I can't get it back, it's all bricked to me. But this is a silly argument.
I agree with you. The title is misleading. I thought this was about frying the device. When people say the raspberry pi is design not to be bricked, they are referring to not fucking the circuitry beyond use without physical repair, not some user process stuck in an infinite loop.
Looks like the "curse of complexity" strikes again... every time I see bugs like this, I wonder if it's because of some code that tries to be a little "too smart" in trying to parse what could be arbitrary data, and forgetting some edge-case.
(If you have JS disabled, you can click "View in Old UI" and then view source to see the content. I find that a bit ironic in the context of this specfic bug...)
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...
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.
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.
Springboard itself doesn't, but it loads a framework into itself that does; commenters here have suggested this is because it needs to render notifications: https://news.ycombinator.com/item?id=20380588
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.
> 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.
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 error further, but in some function we'll write code to handle this case without crashing the system (or, at least, it will shutdown everything gently, without panicking).
Lazy developers also ignore errors by swallowing them. In this particular case, note that the error was detected many methods away because of Objective-C's weak typing, not because the developers "chose" to throw an exception.
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.
The halting problem's existence means that there's no input validation that is guaranteed to work absolutely 100% of the time though, for sufficiently large inputs.
1) Quite the contrary. And there is no "hope" - you either write code to recover or you throw an exception (and then there is a "hope" that some other code will catch it), it's just different approaches.
2) Yes, it's not so difficult. Writing tests, for example, also takes time - it's not a reason to don't write tests.
Seems like a pretty bad example - it only caused a boot loop. That's inconvenient, but fairly minor compared to the myriad of problems that could have arisen from buggy recovery code.
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.
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, that same message was redelivered (crashing it again) for as far as the network was concerned, it was never received by the mobile. Until the time that message either expired in the SMSC in few days, or you switched you sim to a non-vulnerable mobile to receive the message. Good times.