CoreGraphics Memory Corruption | Hacker News Reader

CoreGraphics Memory Corruption

blog.binamuse.com

67 pointsssclafani19 comments

No security fix for "arbitrary code execution" on iOS7. Why must users accept new functionality (and bugs) in iOS8 when this and other security bugs could have been fixed in iOS7? How long ago was Apple aware of this vulnerability - was release of the fix delayed until iOS8 in order to force everyone to upgrade?

Is the bug fixed in iOS 8? I didn't see where the page said that...

The author has a reliable exploit for iOS 7.1.x, but that doesn't mean the bug was fixed (maybe other things moved around so the shellcode doesn't work?).

I am genuinely curious though -- I haven't upgraded and don't intend to until a couple of point releases are out, but something like this could prompt me to act sooner.

Apple's iOS8 fix announcement is listed on the page under "Advisory", http://support.apple.com/kb/HT6441

There are 50+ security fixes bundled into iOS8, http://www.zdnet.com/ios-8-fixes-dozens-of-security-flaws-70...

And a long list of new bugs introduced in iOS8: http://www.ibtimes.co.uk/ios-8-bugs-roundup-top-reasons-why-...

So I guess my iphone 4 isn't safe to use anymore

I have no doubt it will be patched, but in the meantime the sandbox MobileSafari occupies will significantly limit what the exploit can actually do.

it's already patched in iOS 8. The question is whether iOS 7 will be patched. Together with the other security holes it should be possible to break out of the sandbox

http://support.apple.com/kb/HT6441?viewlocale=en_US&locale=e...

Because the world moves on.

Let me quickly check if Microsoft still releases security fixes for DOS 1.0 ...

Microsoft supported XP with security fixes for 10 years.

Apple can't support iOS7 for one year? Good luck to IBM selling iPads into the enterprise market. Enterprise customers need time to validate corporate applications with a new OS version.

Let's see if Apple's enterprise customers are happy to risk corporate IP to an arbitrary code execution vulnerability, or impact corporate productivity by "upgrading" to the bugs in iOS8, http://www.ibtimes.co.uk/ios-8-bugs-roundup-top-reasons-why-...

IBM doesn't need luck in the Enterprise market, the Enterprise is asking for it (maybe not IT leaders, but they're losing the battle to other divisions). Besides, the idea that upgrading to iOS 8 as part of the bug fix cycle is a remnant of the days when OS upgrades were big, expensive and hard. If the lifecycle of the iPad in an Enterprise is three years (a guess), there's a documented trend that Apple will release OS updates for three year old hardware. Instead of patching 7 forever, push the latest OS update. End users are happier, which makes leadership happier.

That's kind of silly.

XP was at least as buggy as iOS, probably more so, and that didn't stop very many enterprise customers from buying it. And then they upgraded to Vista and Windows 7, which were just as buggy.

"Upgrade to the next version to get bug fixes" will work for Apple just as well as it worked for Microsoft.

Where do you draw the line? 1 year? 10 years? 100 years? Some argue that MS was too soon to stop XP support, as it is still being widely used. Even MSDOS is still being used by some companies.

> Enterprise customers need time to validate corporate applications with a new OS version.

Isn't it strange that most of the apps I have installed had a new version at the iOS8 launch date or a day later, but 'enterprise' developers need years to 'validate' a new OS version?

I'd say take the 90th percentile lifetime of the hardware, double it, that's how long an operating system should be supported. The doubling to account for people that aren't buying on day one.

So around the 10 year number. Depends on the kind of computer.

Embedded, low-power, passively cooled i386 (or compatible) have a pretty long lifetime, 30 years at least. So MSDOS, which is an operating system which can run on those should be supported for 60 years?

If it's embedded you look at the lifetime of the entire unit. If the machine lasts 30 years then yes, you should be supporting the whole thing. Maybe not 2x, maybe closer to (lifetime + years between OS releases + 2 year margin).

And when I say 'support' in the context of embedded code I don't mean much. It doesn't need new features. It should generally not be on a public network and doesn't need much in the way of bugfixes. Just keep it running. After a few years it's likely you won't need to patch it again ever. But if it needs a patch, make one.

When I picture someone installing a new operating system on the lathe they've had for 20 years my eyes are wide in horror.

Are you seriously comparing IOS 7 to MSDOS?

Oh look a buffer overrun exploit! In C, who would guess?

Static analyzers for C exist since 1979, but why use them...

"Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions. " -- Dennis Ritche on history of C.

For what it's worth, Apple do use a static analyser - they even wrote their own, and it's actually pretty good. If I remember correctly, it's even activated by default for new projects in XCode these days.

But static analysers are not perfect, and theirs is apparently not clever enough to catch this bug. Maybe they will patch the analyser in response to this bug, or maybe not - there is a trade off between speed and thouroughness with static analysers.

It is one thing to have a static analyzer in the compiler, which is quite good. Clang almost makes C feel like Pascal.

And another very distinct one, is having the respective coder use it

You have not demonstrated that the clang static analyser was able to detect this. You are going to have to do that before you start firing off accusations that the developers at Apple ignored the warnings.

Reply on news.ycombinator.com