How a single line of code could brick your iPhone(rambo.codes)
rambo.codes
How a single line of code could brick your iPhone
https://rambo.codes/posts/2025-04-24-how-a-single-line-of-code-could-brick-your-iphone
125 comments
> That is right in the wheelhouse of tracking a user across apps.
The design is old. It probably predates facebook, so it's not been intentional, as your comment might be interpreted. But it certainly seems ripe for abuse. I'm curious if it would actually be used for that, because any app that can access internet already has a better way to share information.
The design is old. It probably predates facebook, so it's not been intentional, as your comment might be interpreted. But it certainly seems ripe for abuse. I'm curious if it would actually be used for that, because any app that can access internet already has a better way to share information.
Facebook predates iPhones by 3 years.
NSNotificationCenter predates the iPhone by 13 years, though…
According to the docs, NSNotificationCenter already was present in Mac OS X 10.0. It seems to be present in NextSTEP 3.3, which was released in 1995 (http://www.cilinder.be/docs/next/NeXTStep/3.3/nd/Foundation/...).
I was interning at Facebook in '07 when the first iPhone was released. Can confirm! Someone was 3rd in line at the Palo Alto Apple store and brought it over to the office.
Though iOS definitely predates 3rd party apps and the ad based economy. Which is a bit of a tautology.
Though iOS definitely predates 3rd party apps and the ad based economy. Which is a bit of a tautology.
this is exactly where my mind went immediately - 64 bits is more than enough for easy (1 line!) unenforced cross-app tracking of a user for advertising purposes, basically a super cookie for iOS. If they now require an entitlement for this API it's a privacy win
Only sensitive notifications require an entitlement. Tracking wasn't mitigated.
The IDFV already supports tracking user across apps, as long as they are from the same vendor. It resets when apps from a vendor are removed from a device. Not sure if the user can reset it by themselves, but the vendor could then always tie things together using another self-generated identifier stored on the device, as long as any of its apps are on it, which boils down to the same.
I think the approach you describe allows roughly the same, except perhaps doing so without (or with different) permissions, and allowing to do this between vendors (that must agree upon this upfront).
I think the approach you describe allows roughly the same, except perhaps doing so without (or with different) permissions, and allowing to do this between vendors (that must agree upon this upfront).
I think it’s most interesting for 3rd party SDKs (analytics, advertising, others?), because they’re in a position to have their code running in apps from different vendors.
As per the DMA if it's available to Apple's own apps it has to be available to third party apps as well. Of course apple will fight this tooth and nail so they can maintain their walled garden, making them billions per year.
The exploit as described doesn't "brick" the device; that would require permanently disabling it. A tethered restore would be all that's required to recover in this case.
There's physically no way to permanently "brick" an iPhone.
DFU mode boots entirely from read-only ROM, and from there, you can just restore everything via USB cable.
Same applies to Apple Silicon Macs. You can damage the system, recovery and emergency recovery volumes, but even then, you can still boot into DFU from ROM and re-initialize everything via another Mac.
This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked. There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without
DFU mode boots entirely from read-only ROM, and from there, you can just restore everything via USB cable.
Same applies to Apple Silicon Macs. You can damage the system, recovery and emergency recovery volumes, but even then, you can still boot into DFU from ROM and re-initialize everything via another Mac.
This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked. There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without
> There's physically no way to permanently "brick" an iPhone.
There definitely are (If you count jailbroken iPhones). I've managed to brick one by removing all thermal throttling limits and subsequently damaging the motherboard with the world's shittiest watercooling setup.
Can't use DFU to restore if you've got damaged hardware
There definitely are (If you count jailbroken iPhones). I've managed to brick one by removing all thermal throttling limits and subsequently damaging the motherboard with the world's shittiest watercooling setup.
Can't use DFU to restore if you've got damaged hardware
"Bricking" is typically used to describe software failures specifically. Physical damage isn't "bricking" in the traditional sense, it's just broken.
Besides, physical damage is the obvious exception to GP's statement. Nobody is reading this and thinking that a ROM DFU will recover a phone that is physically destroyed.
Besides, physical damage is the obvious exception to GP's statement. Nobody is reading this and thinking that a ROM DFU will recover a phone that is physically destroyed.
im sure they meant "within reason."
no amount of monkeying around with the software will brick the iphone (botched updates, etc.). Once we get to hardware failures the vectors are innumerable. Lightning strikes. Device drops from height. Botched water cooling. Magnifying glass lasers. Children's vomit...
no amount of monkeying around with the software will brick the iphone (botched updates, etc.). Once we get to hardware failures the vectors are innumerable. Lightning strikes. Device drops from height. Botched water cooling. Magnifying glass lasers. Children's vomit...
> There have even been stories of peoples' computers being bricked via rm -rf /
I would expect that most systems should be recoverable from this state with a CMOS clear.
I would expect that most systems should be recoverable from this state with a CMOS clear.
"physically" is overstating it. Certainly during development it's possible, which means that -- conditioned on a bad enough bug -- it could hypothetically happen to customers too. Not that I think that's likely, of course, but it is physically possible.
Right now someone in Fort Meade is falling off their chair laughing...
I'm gonna walk through this because I have a bit of experience here on the computer side of things, but I'm not really making an excuse for the fact that the PC version of this is less user-friendly; from my perspective, I fully respect that Apple has done a good job with user experience where PC manufacturers have lagged. However, my main concern is devices turning to e-waste, so the important thing for that isn't UX, it's just how plausible it is to recover once you've bricked. With that out of the way...
> This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked.
I accidentally destroyed the firmware on a machine that did not have any recovery features, when flashing modified UEFI images, leaving it mostly inoperable. I wound up recovering it using flashrom and a Raspberry Pi. I think this counts as a hard brick, but the modular nature of PCs (e.g. most BIOS chips are on sockets so you can pull them out easily) it's not nearly as big of an issue if you hard-bricked a device that's more integrated and locked down. It's not instant e-waste because no bricks are permanent.
(It's a little harder for laptops, but I did also flashrom a laptop in a similar fashion, in-circuit using a SOIC8 clamp. This was not a brick recovery but rather messing with coreboot.)
Definitely not as much for the faint of heart, but a repair technician could do it for you. Alternatively, for PCs with socketed BIOS, you can buy a new EEPROM that's already flashed with the right firmware--they were readily available on eBay last I looked.
That was probably a decade ago or more by now. Many modern PC motherboards from many vendors have mitigations for this; it was a common enough pain point after all. For example, my desktop PC has an embedded controller that can boot and rewrite the flash chip for you, using a copy of BIOS from a USB stick. (Works even if the CPU isn't installed. Pretty cool.)
> There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without
EFI vars are stored in NVRAM, not the EEPROM. You can usually clear that a couple of ways:
- Use an integrated NVRAM reset system. Some machines have a way to do this listed in their manual. On desktop PC motherboards, it tends to be a jumper you set for a few seconds. Sometimes you will have an easier option, like a button somewhere, or even possibly a key combination at boot (Long time Macintosh fans probably have memorized the NVRAM reset key chord for Apple computers... I wonder if it still works on Apple Silicon.)
- Remove the battery for a few seconds. Usually easily accessible on a desktop. Usually a little less easy to get to on a laptop, but nothing absurd, usually just some screws.
Certainly it could be easier to recover from, I'd say it's actually not very easy to brick a typical desktop PC in a particularly permanent fashion. The only time I've ever done it was because I was modifying my UEFI image intentionally. Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.
--
Now... as for whether or not an Apple Silicon device can "physically" be bricked by software, the most obvious way to do that would be to wear the SSD down to the point where it can no longer be rewritten. I think the M4 Mac Mini finally no longer solders these and that the Mac Minis do have a way you can recover from this brick (using another Mac to restore to a new SSD) but there are many Macs where if the SSD is destroyed, it's pretty hard to fix since you need Apple tools that are hard to obtain if you want to pair a new SSD. This is unfortunate because Apple has often had dodgy hardware choices around the SSD (e.g. the notorious TPS62180 buck converter) and doesn't always use SSDs that have the best reliability (IIRC they use a lot of Kioxia in the newer Apple Silicon devices, which are not considered to be bad devices by any means, but are generally considered less durable than e.g. Samsung SSDs.)
Rather than have an Apple device become ewaste due to software issues, in recent years, it is much more likely that it will become ewaste due to hardware issues, as a result of parts pairing and having failure-prone components that are not modular even when they really can and should be (Good on them for rectifying this lately, e.g., with the Mac Mini SSD, but it's a bit sad that it took this long. And on the note of that SSD... Apple, you really could've used a standard electrical interface for that.)
This is somewhat a testament to Apple's software and system design, but it's simultaneously a condemnation of their recent track record with repair, too. Best we can hope is that they don't go backwards from this point forward, because they created a lot of devices that will become ewaste over time for almost no gain for anyone. (I strongly dislike but can understand the justification for something like parts pairing in iPhones and iPads, but much less so for similar sorts of mechanisms in computers.)
> This is in contrast to some PCs, where if you damage the BIOS (e.g. by suddenly losing power during a firmware update), your device may or may not be bricked.
I accidentally destroyed the firmware on a machine that did not have any recovery features, when flashing modified UEFI images, leaving it mostly inoperable. I wound up recovering it using flashrom and a Raspberry Pi. I think this counts as a hard brick, but the modular nature of PCs (e.g. most BIOS chips are on sockets so you can pull them out easily) it's not nearly as big of an issue if you hard-bricked a device that's more integrated and locked down. It's not instant e-waste because no bricks are permanent.
(It's a little harder for laptops, but I did also flashrom a laptop in a similar fashion, in-circuit using a SOIC8 clamp. This was not a brick recovery but rather messing with coreboot.)
Definitely not as much for the faint of heart, but a repair technician could do it for you. Alternatively, for PCs with socketed BIOS, you can buy a new EEPROM that's already flashed with the right firmware--they were readily available on eBay last I looked.
That was probably a decade ago or more by now. Many modern PC motherboards from many vendors have mitigations for this; it was a common enough pain point after all. For example, my desktop PC has an embedded controller that can boot and rewrite the flash chip for you, using a copy of BIOS from a USB stick. (Works even if the CPU isn't installed. Pretty cool.)
> There have even been stories of peoples' computers being bricked via rm -rf /, due to removing everything at /sys/firmware/efi/efivars/ (which is actually stored inside the motherboard), and sometimes contains things that the motherboard won't boot without
EFI vars are stored in NVRAM, not the EEPROM. You can usually clear that a couple of ways:
- Use an integrated NVRAM reset system. Some machines have a way to do this listed in their manual. On desktop PC motherboards, it tends to be a jumper you set for a few seconds. Sometimes you will have an easier option, like a button somewhere, or even possibly a key combination at boot (Long time Macintosh fans probably have memorized the NVRAM reset key chord for Apple computers... I wonder if it still works on Apple Silicon.)
- Remove the battery for a few seconds. Usually easily accessible on a desktop. Usually a little less easy to get to on a laptop, but nothing absurd, usually just some screws.
Certainly it could be easier to recover from, I'd say it's actually not very easy to brick a typical desktop PC in a particularly permanent fashion. The only time I've ever done it was because I was modifying my UEFI image intentionally. Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.
--
Now... as for whether or not an Apple Silicon device can "physically" be bricked by software, the most obvious way to do that would be to wear the SSD down to the point where it can no longer be rewritten. I think the M4 Mac Mini finally no longer solders these and that the Mac Minis do have a way you can recover from this brick (using another Mac to restore to a new SSD) but there are many Macs where if the SSD is destroyed, it's pretty hard to fix since you need Apple tools that are hard to obtain if you want to pair a new SSD. This is unfortunate because Apple has often had dodgy hardware choices around the SSD (e.g. the notorious TPS62180 buck converter) and doesn't always use SSDs that have the best reliability (IIRC they use a lot of Kioxia in the newer Apple Silicon devices, which are not considered to be bad devices by any means, but are generally considered less durable than e.g. Samsung SSDs.)
Rather than have an Apple device become ewaste due to software issues, in recent years, it is much more likely that it will become ewaste due to hardware issues, as a result of parts pairing and having failure-prone components that are not modular even when they really can and should be (Good on them for rectifying this lately, e.g., with the Mac Mini SSD, but it's a bit sad that it took this long. And on the note of that SSD... Apple, you really could've used a standard electrical interface for that.)
This is somewhat a testament to Apple's software and system design, but it's simultaneously a condemnation of their recent track record with repair, too. Best we can hope is that they don't go backwards from this point forward, because they created a lot of devices that will become ewaste over time for almost no gain for anyone. (I strongly dislike but can understand the justification for something like parts pairing in iPhones and iPads, but much less so for similar sorts of mechanisms in computers.)
> Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.
For what it's worth, I have a laptop here that can be irrevocably (short of having a flash memory dump on-hand that can be flashed back) bricked just by messing around with EFI variables through fully intentional operations (i.e. operations that would be available to any program with Administrator privileges on Windows, or the root user on Linux).
For what it's worth, I have a laptop here that can be irrevocably (short of having a flash memory dump on-hand that can be flashed back) bricked just by messing around with EFI variables through fully intentional operations (i.e. operations that would be available to any program with Administrator privileges on Windows, or the root user on Linux).
As far as I know virtually all of the EFI vars will be stored on battery-backed NVRAM, so the usual solution is to just clear that, by removing the CMOS battery. I am pretty sure the only solution are things you definitely can not read or write from the host OS (e.g. BIOS passwords.) Does require partially disassembling the laptop though, and I know there's at least a couple random models of laptop that actually stop working if you clear the NVRAM (lol)
*only solution = only exceptions
Not sure how that happened.
Not sure how that happened.
>Rather than have an Apple device become ewaste due to software issues, in recent years, it is much more likely that it will become ewaste due to hardware issue
Apple not supporting their hardware after a short time is a software issue causing e-waste. I have a big box full of non-viable Apple hardware that is working perfectly well, Apple just decided to stop supporting all those devices - a bunch of tablets, a couple apple tvs, an old apple watch, several laptops, etc.
Sure, other manufacturers do this too, but none as badly as Apple does IMHO.
Apple not supporting their hardware after a short time is a software issue causing e-waste. I have a big box full of non-viable Apple hardware that is working perfectly well, Apple just decided to stop supporting all those devices - a bunch of tablets, a couple apple tvs, an old apple watch, several laptops, etc.
Sure, other manufacturers do this too, but none as badly as Apple does IMHO.
rm -rf is nightmare, if used mistakenly. I myself have been victim of this.
https://news.ycombinator.com/item?id=43775027
https://news.ycombinator.com/item?id=43775027
If you had root access on your iPhone, to do that, you would see a recovery message on your phone at the next reboot. Then, plugging it into your macBook, you would get a popup asking if you would like to restore it. Bricks don't usually have software restore prompts.
From observation, "brick" has evolved, as things do in language. In practice, it rarely means the traditional definition you refer to, but the softer one used here.
And for that reason I wouldn't hassle laymen over it but among the HN crowd I expect a bit more care. An "anything goes" attitude makes communication more difficult.
"Soft brick" is the correct term that already exists.
"Soft brick" is the correct term that already exists.
> "Soft brick" is the correct term that already exists.
Which is the term that the article uses.
"The result is a device that’s soft-bricked, requiring a device erase and restore from backup."
Which is the term that the article uses.
"The result is a device that’s soft-bricked, requiring a device erase and restore from backup."
> Which is the term that the article uses.
...except in the headline.
...except in the headline.
Need to get you to click on it :-)
Also, although HN readers probably have many devices in their homes there are people out there who have only a phone and no computer. For them this would be pretty catastrophic. Hopefully they’d take their device to Apple or a third party technician
I'm quite convinced apple would just sell them a new one.
Almost like a "soft"-brick, if you would.
Thus, perhaps "loafed" as in something brick-like, but which may also be soft.
And a "loafed" device, being idle, would be loafing.
You could say the device was pillowed. :D Although given the typical behaviour of old phone batteries, I guess that’s a little ambiguous.
A soft brick would be a brick before being fired in an oven, no?
So maybe the term shouldn't be 'soft brick' but rather 'muddied'.
"That updated muddied my device, I had to clean it up with a restore"
So maybe the term shouldn't be 'soft brick' but rather 'muddied'.
"That updated muddied my device, I had to clean it up with a restore"
I appreciate the sentiment but I don't see that catching on. I think a variant of bricked makes sense as it basically means you can't use the device until you can figure out how to fix it. Which the "muddied" analogy doesn't really fit - it's usually possible to use muddy things if not necessarily pleasant.
"fix it" was the definition of the the old usage of brick though, with the "fix it" generally meant a hardware fix, like replaced components. if the fix is reinstalling software, then that means it's still a completely functional piece of hardware. there's nothing wrong with it. you don't say your car is broken because someone who can't drive sits in the driver seat! get off my lawn!
I remember this being referred to as "the OS needs to be reinstalled", a trivial thing that nobody bothered to give a name to, because it was frequent and non-consequential.
Ah yes, the Goebbels effect, also known as "A lie told a thousand times becomes the truth."
“Bricking” isn’t a rigorously defined term, it’s more like “realtime” in the sense that it comes with an implicit “(for this particular user in this particular scenario)”. For most users a device is bricked if it doesn’t turn on and work when you press the power button. For most readers here, using dev tools to re-flash a bootloader would be fairly easy but if USB stops working it might be game over. I’m sure there are a few around who could de-cap an ASIC and circuit bend it back to life.
Incorrect. Bricking means a device becomes a doorstop that cannot be resurrected or repaired by the user non-invasively. That's the whole point of the term.
When devices were a bit larger, we would customarily refer to “boat-anchors”
That was a pejorative for unwieldy and inconvenient devices like rugged government secure cell phones that lagged behind consumer tech.
Brick means entirely useless except as a doorstop, projectile, or building material.
Brick means entirely useless except as a doorstop, projectile, or building material.
I beg to differ. "Boat anchor" not only has the connotation of uselessness, but is also well-documented, such as in the official Jargon File by Eric S. Raymond:
http://www.catb.org/jargon/html/B/boat-anchor.html
1. Like doorstop but more severe; implies that the offending hardware is irreversibly dead or useless. “That was a working motherboard once. One lightning strike later, instant boat anchor!”
I contend that brick is a neologism based on this boat-anchor analogy. A brick is rather small, handheld, portable. No computer component was this way when the "boat-anchor" term was coined.
Indeed, many of my colleagues in the 90s based their trust and confidence in hardware on its volume and mass. If we could lift it, or throw it across the room, it was not worthy of respect. Those were the days of magnificent racks loaded with equipment that did comparatively very little!
http://www.catb.org/jargon/html/B/boat-anchor.html
1. Like doorstop but more severe; implies that the offending hardware is irreversibly dead or useless. “That was a working motherboard once. One lightning strike later, instant boat anchor!”
I contend that brick is a neologism based on this boat-anchor analogy. A brick is rather small, handheld, portable. No computer component was this way when the "boat-anchor" term was coined.
Indeed, many of my colleagues in the 90s based their trust and confidence in hardware on its volume and mass. If we could lift it, or throw it across the room, it was not worthy of respect. Those were the days of magnificent racks loaded with equipment that did comparatively very little!
This was the prevailing definition in California/Silicon Valley 20 years ago.
You're a different person with a different perspective obviously.
You're a different person with a different perspective obviously.
More importantly, the single line only forces a reboot; even if we consider needing external fixes to be a brick, the title is still incorrect.
It doesn't just force a reboot, it forces a never-ending loop of reboots, rebooting each time you reboot it.
> The result is a device that’s soft-bricked, requiring a device erase and restore from backup.
Requiring a device erase isn't a full brick, no, but it's still pretty serious.
> The result is a device that’s soft-bricked, requiring a device erase and restore from backup.
Requiring a device erase isn't a full brick, no, but it's still pretty serious.
No, the _single line_ part forces a single reboot. The never-ending loop requires setting up a widget, so that's more than one line.
The single line part also requires you first set up an app to execute that code as well.
I think you skimmed too fast. Widgets, allegedly, are eagerly evaluated when an app is opened, and the system keeps trying failed attempts:
> After restarting, as soon as SpringBoard was initialized, the extension would be woken up by the system, since it had failed to produce any widget entries before, which would then start the process all over again.
> After restarting, as soon as SpringBoard was initialized, the extension would be woken up by the system, since it had failed to produce any widget entries before, which would then start the process all over again.
The article claims that they had to manually cause the widget to crash so that the result doesn't get cached, right? So that's at least one line to trigger the reboot, one line (likely more) to register as a widget, and one to crash it.
> Requiring a device erase isn't a full brick, no, but it's still pretty serious.
He totally murdered that guy!
What? Why would you say murdered, he only gave him a black eye?
I know, but that's still pretty serious.
He totally murdered that guy!
What? Why would you say murdered, he only gave him a black eye?
I know, but that's still pretty serious.
A tethered restore is still devastating considering how few people backup their iPhone.
Correct. The terminology is wrong. It's an annoying, repeated DoS that doesn't ruin the device permanently but could lose user data if it must be erased.
Neat, $17,500 is pretty good, I’m so used to these blog posts being for peanuts, or where companies fix the vulnerability but don’t pay out at all. Apple’s gotten better about this since 2019.
I read a comment under the story about the recent YouTube vulnerability where one could unmask the related Google account and its owner using the standard YouTube API (something similar to that anyway), and they explained a lot of lesser-known nuances in establishing values for bounties like these, and it helped explain a lot (not all) of the reasons for what might seem like low-ball/high-ball valuations on the surface. If I can find their comment I’ll post back, it was really insightful. That said, there are also plenty of examples of people just getting shafted.
is this the one: https://news.ycombinator.com/item?id=43025038
[deleted]
That's it! Really informative, IMHO. Thanks for adding the other cheek to my half ass job there.
That’s definitely the one I thought of
Probably one of those https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
100% Thanks for the assist.
Maybe Zerodium would've paid $75k but that would be less ethical because Israel and America would weaponize it.
They wouldn’t, especially considering they aren’t operating anymore.
Which was Vupen too before that. One company name is unimportant because multiple shady groups and individuals are out there buying and selling 0daya. This is definitely the case because state actors don't develop 100% them themselves and must get them from somewhere. It's a small but nonzero market of expediency.
I'm sure there are companies that have stepped up to fill the void. But the market for "I DDoSed your phone" doesn't really exist.
Except that's not true because rendering a target's device unusable temporarily and/or effectively permanently is a useful payload regardless of what you think.
A useful payload for whom? Point me to someone who is willing to pay for such a bug and I'll believe you. Zerodium's old payout scale didn't even list denial of service, and to my knowledge no other serious vendor does either. If I can list a bunch of people who don't care about this surely you can find one who does.
That's not how vulnerability markets work. The idea that a broker would pay $75,000 for a phone DOS is very funny.
Great work! This is my favourite type of vulnerability, simple, effective and brutal. Reminds me of a time two decades ago when with a friend from uni we theorised about a perfect server vulnerability where you’d exploit a machine by pinging it. And of course, two years ago it was in fact discovered as CVE-2022-23093.
Ping of death was already a thing two decades ago.
https://web.archive.org/web/19981206105844/http://www.sophis...
https://web.archive.org/web/19981206105844/http://www.sophis...
It was actually almost 3 decades ago, making me feel extremely old - the period right at the end of '96 and into mid '97 when this was a popular way to cause mischief via IRC was truly a magical time
Hard to believe that during those times in IRC, you were used to automatically (and proudly) advertising your IP address, your exact client version, and the means for a direct connection to your client without any server in between (CTCP, literally “client-to-client protocol”). And all of that most often with no packet filter whatsoever, not even NAT, in between.
Everything was plaintext, including “authentication”, which was (at best) just asking the “ident server” on the same machine as your client who you claimed to be, which was considered sufficient because, after all, to run identd on its “privileged” low port meant you were an “administrator” (i.e. root of a unix machine).
Everything was plaintext, including “authentication”, which was (at best) just asking the “ident server” on the same machine as your client who you claimed to be, which was considered sufficient because, after all, to run identd on its “privileged” low port meant you were an “administrator” (i.e. root of a unix machine).
CTCP messages still go through the server. DCC (direct client connection) are the p2p connections you are thinking of, but they of course don’t work behind nat.
I was behind NAT when I first got on IRC in ‘98. I set it up with ipfwadm.
I was behind NAT when I first got on IRC in ‘98. I set it up with ipfwadm.
Ah you are right, I mixed CTCP and DCC up. The former was also used to set up the latter I think? (Among other things.)
I joined IRC in the early 90s, there was no NAT then, packet filtering was uncommon, and practically nothing on the Internet was encrypted. It was a very different time.
I joined IRC in the early 90s, there was no NAT then, packet filtering was uncommon, and practically nothing on the Internet was encrypted. It was a very different time.
Death on flaxxen wings
When I was in college circa 2001 we used to prank each other with the ping of death and other crash exploits. Also random IPs on the college network when we were bored. It was crazy how long it was around for and how easy it was to exploit.
DOS yes, but that freebsd cve I referenced is a theoretical RCE.
This link doesn’t show me anything useful.
Try scrolling down. On mobile (maybe because of ad blockers) Wayback pages have a full screen of white space above the page contents anymore for me. This happens on pretty much every Wayback page I've tried. It's also relatively recent and I'm not sure the exact cause.
Back in the dial-up days you could disconnect someone by adding ATH commands to a ping payload field.
Only if their modem didn’t implement the Hayes command set properly or you could otherwise control the per-character timing of the OS sending. It required a pause (1sec by default), “+++” with no pauses, another pause, _then_ the ATH command
I had an external USRobotics 56k modem, I was immune. But the many many "bulk" no-name modems were vulnerable. You could ping entire ranges of dial-up IPs and watch the results on big IRC channels. Uhmmm, allegedly :)
Which was fairly common, as Hayes had a patent on those pauses.
Huh, TIL. I guess they might have used TIES
https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequen...
https://en.wikipedia.org/wiki/Time_Independent_Escape_Sequen...
I’m too lazy to look it up but there was some string you could send over IRC that would make some routers drop the connection immediately - if you pasted that string in a big channel you would see dozens of people immediately disconnect.
An 0x01 control character (CTCP) followed by
This caused the DCC ALG helper in ancient Linux kernels to close the connection, as they failed to parse 0 as a valid IP address. Users connecting to IRC servers over TLS were immune, as the ALG helper in the router could not observe the traffic.
This is what breaks DCC in general -- to use DCC on IRC while connecting to the server over TLS and behind a NAT, you must instruct your client to use a specific range of ports for DCC and preforward those ports to your machine in your router, as the ALG helper cannot mark the incoming connection as RELATED (and forward it through to you) as it cannot see the outgoing command that caused the incoming connection to occur. You must also instruct your client to determine the correct external IP address to advertise, as the ALG helper will be unable to rewrite it when the router does masquerading.
DCC SEND whatever 0 0 0
This caused the DCC ALG helper in ancient Linux kernels to close the connection, as they failed to parse 0 as a valid IP address. Users connecting to IRC servers over TLS were immune, as the ALG helper in the router could not observe the traffic.
This is what breaks DCC in general -- to use DCC on IRC while connecting to the server over TLS and behind a NAT, you must instruct your client to use a specific range of ports for DCC and preforward those ports to your machine in your router, as the ALG helper cannot mark the incoming connection as RELATED (and forward it through to you) as it cannot see the outgoing command that caused the incoming connection to occur. You must also instruct your client to determine the correct external IP address to advertise, as the ALG helper will be unable to rewrite it when the router does masquerading.
On AOL in chatrooms you could play sounds, so if you sent S{/con/con
As the sound, you could crash anyone on windows that hadn't shut off user sounds.
My memory is a bit hazy and I don't want to look up the exact sequence, but that's close enough.
My memory is a bit hazy and I don't want to look up the exact sequence, but that's close enough.
https://mazur-archives.s3.amazonaws.com/aol-files/breaches/c...
it was `{S /con/con`; my memory transposed two characters. the {S was the "system message" that AOL chatrooms used to send sounds, so that sequence of characters after a newline made your computer look for that sound. It was cool if everyone was trusted to not do the /con/con, people would have email chains with the audio files on them, like a proto-napster.
it was `{S /con/con`; my memory transposed two characters. the {S was the "system message" that AOL chatrooms used to send sounds, so that sequence of characters after a newline made your computer look for that sound. It was cool if everyone was trusted to not do the /con/con, people would have email chains with the audio files on them, like a proto-napster.
I remember you could brute force passwords by brute forcing in sequence single characters to access anyone’s disk on a giant dialup network. Crazy times.
Hilariously, the PPP (Point-to-Point Protocol) is still used in modern IoT modules. It is actually the only way to run your own TCP/IP stack (and maintain control over TLS), as not all modules support QMI or MBIM.
Nice. I can only imagine what a crap day in the office it was when the iOS core team reviewed that one.
Seems like this should have been obvious to someone on the iOS team, no?
Like, "hey we need a way to trigger springboard UI events.." "ok let's just use this unauthenticated bus and have springboard subscribe to it"
Something like that? Only thing I can think of is that this line of code was written so long ago and it's way at the bottom of the abstraction stack, so no one had a look
Like, "hey we need a way to trigger springboard UI events.." "ok let's just use this unauthenticated bus and have springboard subscribe to it"
Something like that? Only thing I can think of is that this line of code was written so long ago and it's way at the bottom of the abstraction stack, so no one had a look
Anyone know how long ago that system would have been introduced?
It seems like such an obvious security concern. Maybe it was pre-AppStore? And more assumed trust in other apps?
It seems like such an obvious security concern. Maybe it was pre-AppStore? And more assumed trust in other apps?
The notification API is quite old (iOS 3). It's explicitly an untrusted API that you shouldn't use for something like showing the restore in progress UI, so I suspect that was something written quite a bit later. Widget extensions are iOS 14. There's older ways to run background tasks, but none of them would give the soft brick. Background fetch, for example, originally didn't run until after you launched an app for the first time after restarting.
This is an internal broadcast notification API (akin to dbus on Linux), distinct from the API used to display notifications to the user.
Yes, I am aware. I'm not sure what makes you think I was talking about UI notifications?
FWIW I also thought you meant UI notifications (the reason is: I’m dumb). But anyway, I found the point of clarification helpful even though it wasn’t strictly necessary.
Wasn’t it in OS X before that?
Documentation claims 10.6, which is the equivalent OS X version (both are the 2009 releases).
Darwin notifications are so old they don't have any availability annotations (block-based darwin notification APIs like notify_register_dispatch() were introduced in macOS 10.6 / iOS 3.2, but the rest of them are declared as always available). They absolutely predate any notion of an AppStore, of being able to install apps without implicitly putting a lot of trust in the app to not be malicious.
> That single line of code was enough to make the device enter “Restore in Progress”.
> as established before, any process could send the notification and trick the system into entering that mode.
Doesn't this imply that third-party apps with their own notification schemes could be impersonated similarly? They wouldn't be able to brick the phone, obviously, but they could potentially trigger other actions.
This reminds me of how there is zero authorization for `NOTIFY` in PostgreSQL. IMO there should at least be the option to `CREATE CHANNEL ...` and then use `GRANT` to indicate who can `NOTIFY`.
In practice this is not a big problem because usually one grants very few users direct access to a PG DB.
In practice this is not a big problem because usually one grants very few users direct access to a PG DB.
I get that it's potentially lower priority since a user needs to actively install a malicious app, but that timeline doesn't exactly feel me with confidence...
In general, the vulnerability of our computers is major national security concern as we enter in the era of AGI. This administration needs to setup a system hardening commission. In the era of AI... if we aren't using the leading AI to hack our own systems first, then when the capability to use the latest models to hack is widely available, we are going to have a bad time.
The sheer simplicity of this exploit is wild.
Ultimately, does this require installing a sketchy app in the first place?
Lots of credible apps use lots of dependencies. Find an abandoned one, get your code into it, …
Yes.
This was an epic read. That very old skool API was so powerful! Cool demo seeing it trigger all this low-level states for iOS. I wonder what happened to notify_post now..
> Looking into the binaries, SpringBoard was observing that notification to trigger the UI. The notification is triggered when the device is being restored from a local backup via a connected computer, but as established before, any process could send the notification and trick the system into entering that mode.
This should probably be reworked regardless if the patch described in the article was implemented.
This should probably be reworked regardless if the patch described in the article was implemented.
I wonder if this can be "ported" to dbus, udev, or devd.
I don’t specifically know the types of things that you’d want to share across apps, but there’s a long history of cross process information channels being removed or restricted.
If the system is storing values for you, and isn’t keeping track of which app they came from, now you’ve got persistent storage across app deletion & re-install, as long as there isn’t a reboot in between.
I think you could easily use it to work around IDFA or IDFV resets, as a simple example.