Live data from Hacker News

Found a nice bug in IOS today, bricks your phone and kills the Simulator

pastie.org

21–30 of 35 posts

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#21
post #4

Im the original poster, that found the bug. Nah it doesnt brick it, it does however require (atleast on 4.1. for me) a factory reset. The problem seems to be that springboard locks up in an endless loop, restarting the device wont help it because its still loading the offending notification from the cache.

If you try hard enough you can always find a piece (or many) of code that will "brick" (using your definition...) your device (whatever that is). I don't consider this a bug, or not a serious one at least.

And in this case Apple's approval process could protect the consumer. They would never let something like this past the gates.

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#22
post #17

Earlier quoted context omitted.

Wait. Is it really an endless loop, or just a queue that is getting filled up faster than it empties resulting in a more DOS-style problem? Because it sounds much more like the second case, in which case not only does it not brick the phone, but it isn't even a bug...

OP:Nope, you didnt read the code. Try reading the other version I posted. Works without a loop as well.

errr, that's what I said...

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#23
post #8

Earlier quoted context omitted.

I'll accept "brick" when recovery requires flashing via JTAG. But not when you just have to press a few buttons.

This is the definition used by people that actually hack hardware, people who are used to performing brain surgery on set-top-boxes and such like. It's not bricked unless unbricking requires a soldering iron or similar, and some JTAG action. These days its getting harder and harder to brick devices, as bootloaders are becoming more and more advanced and more separate from the cores of the devices themselves. Once upo…

You say this because you haven't tinkered with wireless routers...

Just because it's harder to brick things doesn't mean the meaning of the word has changed. People are right to think this is a mis-statement.

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#24
post #11

I am not an iPhone developer, but the code doesn't seem unreasonable to me. Can anybody explain what is special about this code?

It creates 10 copies of an alarm on the same date with a setting to repeat twice. So I imagine 10 alarms firing at the same time is not a good idea. I don't see where it calls itself like other people are saying.

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#25
post #19
post #6

Also here is a nicer version that still triggers the bug http://www.pastie.org/private/8a48wgmcuuhjjwbupbk3g

So what's the bug then? If there's no loop here?

alarm.repeatInterval = NSEraCalendarUnit

Triggers the bug, its totally valid as well.

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#27
post #4

Im the original poster, that found the bug. Nah it doesnt brick it, it does however require (atleast on 4.1. for me) a factory reset. The problem seems to be that springboard locks up in an endless loop, restarting the device wont help it because its still loading the offending notification from the cache.

If you try hard enough you can always find a piece (or many) of code that will "brick" (using your definition...) your device (whatever that is). I don't consider this a bug, or not a serious one at least. And in this case Apple's approval process could protect the consumer. They would never let something like this past the gates.

If a sandboxed application can get the sandboxing environment into a state where the only way to get the sandboxing environment working again is by restoring it from a backup, that is a serious defect in that environment.

Also, since this issue is very trivial to trigger, it's not very difficult to hide the triggering mechanism in a malicious application in a way that even a reasonably thorough source code inspection would not necessarily spot it. See also: The Underhanded C Contest.

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#28

Earlier quoted context omitted.

If you try hard enough you can always find a piece (or many) of code that will "brick" (using your definition...) your device (whatever that is). I don't consider this a bug, or not a serious one at least. And in this case Apple's approval process could protect the consumer. They would never let something like this past the gates.

If a sandboxed application can get the sandboxing environment into a state where the only way to get the sandboxing environment working again is by restoring it from a backup, that is a serious defect in that environment. Also, since this issue is very trivial to trigger, it's not very difficult to hide the triggering mechanism in a malicious application in a way that even a reasonably thorough source code inspection…

[deleted]

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#29
post #26

Earlier quoted context omitted.

errr, that's what I said...

Which is why I wrote "OP" in front :)

In the post that I replied to, you said that Springboard is getting into an endless loop. Having looked at the code that you posted, I commented that it doesn't look like an endless loop but more like a denial of service type problem, to which you replied that I should read the code, and that it doesn't need a loop, which was just repeating my point about it not appearing to be a loop!

Ahhh, I give up. Just try reading what I wrote before replying, mkay?

Re: Found a nice bug in IOS today, bricks your phone and kills the Simulator

#30
post #25
post #19

Earlier quoted context omitted.

So what's the bug then? If there's no loop here?

alarm.repeatInterval = NSEraCalendarUnit Triggers the bug, its totally valid as well.

So basically the repeatInterval is expected to have one of the values of an enumeration assigned to it, where the enumerated values are calendar units (representing daily, weekly, monthly, etc.), and it somehow mishandles the value representing "once-per-era"?
Post reply on HN