Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.2
Impact: An attacker with a privileged network position may capture
data or change the operations performed in sessions protected by SSL
Description: In a 'triple handshake' attack, it was possible for an
attacker to establish two connections which had the same encryption
keys and handshake, insert the attacker's data in one connection, and
renegotiate so that the connections may be forwarded to each other.
To prevent attacks based on this scenario, Secure Transport was
changed so that, by default, a renegotiation must present the same
server certificate as was presented in the original connection. This
issue does not affect Mac OS X 10.7 systems and earlier.
CVE-ID
CVE-2014-1295 : Antoine Delignat-Lavaud, Karthikeyan Bhargavan and
Alfredo Pironti of Prosecco at Inria Paris
The 7.0.2 update came at the same time as OSX 10.9.2 which had the fix for the "gotofail" bug (CVE-2014-1266). So that's a bit weird. Could it be a typo and they meant 7.0.3? But 7.0.3 was released on april 2nd, while today's update "Security Update 2014-002" claims to fix CVE-2014-1295 ("triple handshake attack"). So maybe nothing was fixed in safari until today?
Apple bundles updates to core applications all at once as a single install. So it's all within the security update. Of course the iOS update is separate.
> We have confirmed that our attacks can be mounted on popular web browsers and HTTPS libraries, when they are used to perform certificate-based authentication at servers that enable both resumption and renegotiation.
What is support like for the terrible line-folding (and comments) part of the specification?
In SIP land, which copied HTTP then messed it up even further, there is no correct handling of such messages. Some SIP stacks will error, some will ignore, some will do it correctly. Thus you can't trust your proxy and server to come to the same conclusions and perform the same operations or apply the same security policy.
There's no good reason for line folding or comments. Protocols need only be human readable not human easily-composed-for-formatting. This isn't the 60s or early 70s where you're writing all emails and headers by hand.
This "convenience" (of which I highly doubt, having crafted plenty of messages by hand) comes at a major cost to implementors, both in performance and complexity and hence security.
HTTP isn't a programming language. It does not benefit from crazy syntax.
The protocol has to be designed in a way that facilitates (or, at least, does not actively prevents) manual input. When you mention your performance concern, I have to suggest you profile the code. If your protocol handler is limited by the performance of its message parser, you must be doing something wrong.
As for complexity... No. If your parser is non-trivial when compared to the rest of your stack, again, you are doing something very wrong.
I am not saying to implement full line editing or anything close that. I'd just like to point out that being able to sometimes manually interact with a server is very convenient.
Line folding doesn't really help manually interact or craft messages. Nor do comments. There's no real value in being able to do:
Foo: ValueBegin (this is a comment)
ValueEnds
Versus requiring Foo: ValueBegin ValueEnds
As far as performance, I must say you're incorrect. Review the nginx HTTP parser and you'll see all sorts of bitwise hacks in order to improve performance. This aligns with my own experience writing a packet capture system for a similar protocol.
Having open syntax, comments and line folding being part of the problem, incredibly complicates the parser. Other moronic things are the completely arbitrary handling of header fields. Some header fields allow their value to be split over multiple lines but must treat it as if it was one line. Others use multiple headers to provide some multi-line value. There's no simple parsing, it all must be sensitive to the context. This is just stupid, yet free-text protocol authors revel in it. SIP even publishes a "torture test" RFC where they're just oh-so-pleased with the edge cases their moronic spec allows. They even suggest a parser should guess as to the message sender's intent.
I'd also note that in some cases the parser is most of the stack (simple proxy scenarios, frontend security). Regardless, the fact that the rest of the stack may be complicated is not in any way an excuse for making the parser worse. This is not a programming language.
> you'll see all sorts of bitwise hacks in order to improve performance.
How much time does nginx spend parsing HTTP requests compared to waiting for network or disk IO?
> SIP even publishes a "torture test" RFC
This is actually very clever. I wish other protocols had something like it to help weed out partial and buggy implementations.
> They even suggest a parser should guess as to the message sender's intent.
This may be a little bit too much
> This is not a programming language.
A lot of incredibly powerful uses for technology come precisely from the unintended scenarios - the clever ways to abuse technology and force it to do something it was never intended to. Remember HTTP itself was conceived to do a tiny subset of what it does now.
>How much time does nginx spend parsing HTTP requests compared to waiting for network or disk IO?
Enough that they choose to use much more obtuse code? Not to mention network/IO scale independently so it's not a relevant comparison. I wrote a packet capture system that spent about 70% of its capture/index CPU budget on parsing.
A torture test is only clever if it's not absurd because of a thousand edge cases. Then it just reflects the stupidity in the protocol design.
Do you have any possible use of terrible parsing rules that encourage security holes? HTTP is commonly used outside browsers because it's a simple wrapper for a TCP-RPC model. Request something, get a response. And none of the features depend on the stupid parsing rules - absolutely no one and nothing benefits from that. Except perhaps contractors billing hourly.
AirPort base stations seems to be affected too, I got at least an update for a relatively new AirPort Extreme (running now 7.7.3), however, not for older base stations (running 7.6.4).
I don't think Apple ever officially announces when they drop support for an OSX version. I suspect it's part of the Apple approach to marketing to never say anything negative about the brand in any way & that that includes not announcing EOL on old OSX versions.
>That your computer is so old that you no longer look hip in Starbucks. Plastic MacBooks are so noughties!
I was actually thinking more in terms of security and support.
PPC architectures are not very well supported nowadays, and haven't been for over 5 years. Perhaps longer. Sure, you can still run your machine on 10.5 and it might run really well still. That's no reason to trust it for mission critical tasks. God forbid if someone was using a OS X Server 10.5 and users trusted it with their credentials.
Vanity was pretty low on my list, but I understand everyone's priorities are different.
I was mocking the consumer perspective but obviously HN is too sensitive...
Not sure I trust Apple with longevity. Windows XP from 2002 just hit the dust and I've got a decade out of RHEL. For something from 2007 to be a write off is not good IMHO. I thoroughly regret my MBP purchase for theae reasons.
By the time Apple drops support for your hardware you have a decent chance of being able to install a current Linux distribution with no hiccups and full hardware support, so all is not completely lost.
Possibly right but I don't see how a piece of hardware that is pretty much glued together (as of recent MBA and MBPs) is going to survive that long to be honest.
Turns out if you missed the 10.5 -> 10.6 or 10.7 upgrades, you appear to be hosed unless you can find some physical media for those releases, you can't go 10.5 -> 10.8 (never tried ->10.9, would not expect it to work).
Apple still sells 10.6 (the physical DVD) online (at it's original price, $20) for anyone still stuck on 10.5.
Once you're at 10.6.8, the Mac App Store is available for further upgrades
That's true. The latest OSX releases won't install on some of the early Intel Macs. I've heard it's possible, with a certain amount of hacking, to get an early Intel MacPro for example to run 10.8 or maybe even 10.9 but it's unsupported.
It's time I made sure my family's 2007 iMacs are up to date, I guess. At least one of them is probably still on 10.6 because they send me things in Word for Mac 2004 format and that definitely won't run on anything newer because it's PPC-only code.
Security - Secure Transport
Available for: OS X Mountain Lion v10.8.5, OS X Mavericks v10.9.2
Impact: An attacker with a privileged network position may capture
data or change the operations performed in sessions protected by SSL
Description: In a 'triple handshake' attack, it was possible for an attacker to establish two connections which had the same encryption keys and handshake, insert the attacker's data in one connection, and renegotiate so that the connections may be forwarded to each other.
To prevent attacks based on this scenario, Secure Transport was changed so that, by default, a renegotiation must present the same server certificate as was presented in the original connection. This issue does not affect Mac OS X 10.7 systems and earlier.
CVE-ID CVE-2014-1295 : Antoine Delignat-Lavaud, Karthikeyan Bhargavan and Alfredo Pironti of Prosecco at Inria Paris
That doesn't sound good…